GitLab

This is especially important for the JS file.

See also 1dd2faa2de16.

This is to fix SEDA exports tests on python3.

We first dump XML documents as unicode using the _encoding argument
introduced in previous changeset. Accordingly, expected files are
changed to remove the XML declaration because dumped values will not
contain them.

Then we open files in text mode (using io.open() for consistency between
python2 and python3) and do string formatting using unicode values.
(Especially, six.binary_type(<some integer>) produces different values
in python2 and python3, and we actually want to stringify the integer --
the eid value.)

This is useful in tests because the doctest comparison engine from lxml
works better with text objects. The new _encoding argument is
essentially used a "encoding" argument of lxml's etree.tostring() which
will hence serialize to a unicode string. When doing so, we must also
avoid any XML declaration (otherwise, lxml messes up when loading the
content, not sure why), so we insert the "standalone" flag only when
dumping to bytes.

We use io.open() to consistently open files in text mode in both python2
and python3 (we use text mode because we need to .format() the read
string, which is only possible with text on python3). Accordingly, we
set encoding=text_type when dumping XML to string, in order to produce a
unicode string.

Apparently, this is what python2 does.

`max(maxc, maxvalue)` would evaluate to `max("Infinity", <some
integer>)` when maxc is graph_nodes.INFINITY. While this works on
python2 (by chance, since strings and integers can be compared), this
does not on python3.

We thus move the "if" that checks for graph_nodes.INFINITY inside the
"for" loop.

In python3, lxml.etree.tostring returns bytes but we expect text in
tests. By passing six.text_type as encoding parameter to this function,
it returns a unicode string.

* Use io.BytesIO instead of StringIO.StringIO.
* Explicitly encode strings before writing to stream.
* Decode results before string comparisons in tests.

Still avoid 0.9.0 version of cubicweb-eac which contains breaking
changes.

We change the translation of this field for archive transfer, archive
unit and binary data object entity types. Indeed, this actually
corresponds to the entity label not a description of expected value in
generated profile.

[profile gen] Account for bdo's user cardinality or its parent's in "Integrity" element (CONSEJIRA-663)

See also https://jira.mtpl.bs.fr.atos.net/browse/CONSEJIRA-663

For more details, quoting verbatim the customer request for future reference:

| Sur les documents multi occurrences (0-n ou 1-n) ou même si l’archive
| est multi occurrence (0-n ou 1-n), il y a une balise integrity qui est
| liée au document dans le bordereau de versement que l’on génère.
| Or, dans le XSD du profil, la balise integrity du document ne possède
| pas l'attribut : maxOccurs="unbounded"
| Donc lors de l'envoi à Asalae du versement, Asalae fait une vérification
| par rapport au profil et affiche une erreur a cause de la balise
| integrity qui est présente plusieurs fois.
|
| Pour moi le correctif à faire doit porter sur le XSD et le RNG sur la
| balise integrity pour qu'elle soit multi-occurrence possible dans les cas
| suivants :
|
|   *   Si le document (Document) est en multi occurrence (0-n ou 1-n)
|       donc avec un attribut maxOccurs="unbounded"
|   *   Si une UA (Contains) supérieure au document est en multi
|       occurrence (0-n ou 1-n) donc avec un attribut
|       maxOccurs="unbounded"

| si une UA supérieur est en cardinalité max unbounded, alors
| l'integrity sur les documents en dessous doit forcément être en
| unbounded également

| il faut que l'integrity soit en facultative ou multi occurrence si une
| UA supérieure est facultative ou en multi occurrence.

This is essentially achieved by looking for the upper parent archive
units of a data object then their cardinality to produce the Integrity element.

Adding tests for new integrity_cardinality() function based on customer
examples.

In the next changeset, binary data object's user_cardinality will be
accounted for when inserting the "Integrity" element in profile whereas
it is currently hard-coded to "0..1" (see xsd_integrity() method of
SEDA1XSDExport and SEDA02XSDExport classes). In order to prevent changes
to generated profile with respect to the "seda_02_bordereau_ref.xml"
file, we set the value of user_cardinality created bdo in this test.

Still log the information, just in case...