1. 01 Sep, 2017 8 commits
    • Sylvain Thénault's avatar
    • Sylvain Thénault's avatar
      [pkg] 0.10.7 · f0c27820cdaf
      Sylvain Thénault authored
      f0c27820cdaf
    • Sylvain Thénault's avatar
      [test] Cleanup · efbecdc4fc5b
      Sylvain Thénault authored
      efbecdc4fc5b
    • Sylvain Thénault's avatar
      [i18] Accord de service -> accord de versement · b247060eadc2
      Sylvain Thénault authored
      Closes #17098388
      b247060eadc2
    • Sylvain Thénault's avatar
      [profile gen] Ensure same name children are ordered accorded to their cardinality · 4941eab6a289
      Sylvain Thénault authored
      As explained in the previous commit, we want items with cardinality = 1 first
      then the one with cardinality != 1 if any. See previous commit for detailed
      explanation.
      
      Closes #17098404
      4941eab6a289
    • Sylvain Thénault's avatar
      [hooks] Ensure we don't have several children with cardinality != 1 · 39d1d971e058
      Sylvain Thénault authored
      By trying to validate several profiles using Jing (in Asalae), it appears that
      it isn't possible to validate a profile where there are several elements with
      the same name with optional or/and multiple cardinality, e.g. with a profile
      telling we expect  1..n Document followed by 1 Document, a transfer with two
      documents won't be accepted, telling a required document is missing. This is
      much probably because the validator "eats" the two documents for the first rule,
      then it misses one to satisfy the second rule.
      
      In order to avoid generating such insatisfyable profiles, while not changing
      much the UI for now, we decided to add hook preventing usage of several sibling
      children with a cardinality != 1 during edition, and then at RNG profile
      generation time to put the one with cardinality != 1 as last children. That way
      profiles should always be validable.
      
      This patch introduces the hooks preventing insatisfyable profiles to be created.
      The next one will ensure the order of RNG export.
      
      Two hooks are added to check for unhandled case one for new watched relations
      and the other for update cardinalities.
      
      Added test cases for the 3 most prominent cases: archive unit, document and
      keywords, with more coverage in the first one and only simple check for the two
      others. Also, some test have to be updated to follow this change. Notice diff of
      exported RNG isn't nice to read but is actually only removal of a surrounding
      "oneOrMore" element.
      
      Related to #17098404
      39d1d971e058
    • Sylvain Thénault's avatar
      [code gen] Generate new structures that will ease check for unhandled cardinalities · fcf239b4e613
      Sylvain Thénault authored
      Those structures will be used as bases for hooks necessary to check for
      unhandled cardinalities, that will be introduced by the following change set.
      
      We have to watch composite relation that may lead to several children, and for
      the entity types that are possible as children.
      
      Related to #17098404
      fcf239b4e613
    • Sylvain Thénault's avatar
      [doc] Add some basic information in README · a671735e9217
      Sylvain Thénault authored
      a671735e9217
  2. 31 Aug, 2017 3 commits
  3. 29 Aug, 2017 1 commit
    • Sylvain Thénault's avatar
      [profile gen] Ensure data-objects are exported before sub-units in SEDA 0.2 · 68c5f87f8677
      Sylvain Thénault authored
      else this won't be conform to the SEDA 0.2schema. But notice this is the
      opposite in SEDA 1.0. In this case, test cases were fine but the problem was
      actually the same: data-objects and sub-units order was random, and it's not
      anymore.
      
      As we are here, add eid so we get a total ordering, which is an expected
      property so that exported profiles are consistent during time. This should be
      enough until we want to control ordering from the UI.
      
      Closes extranet #33070904
      68c5f87f8677
  4. 24 Aug, 2017 3 commits
  5. 16 Aug, 2017 1 commit
  6. 20 Jul, 2017 5 commits
  7. 19 Jul, 2017 2 commits
  8. 22 Jun, 2017 1 commit
  9. 13 Jun, 2017 4 commits
  10. 06 Jun, 2017 2 commits
  11. 01 Jun, 2017 2 commits
  12. 18 May, 2017 1 commit
  13. 10 May, 2017 2 commits
  14. 27 Apr, 2017 2 commits
  15. 21 Apr, 2017 3 commits