GitLab

introducing special display of its attributes.

Including a new view to display alternatives.

so handle this by a custom vocabulary function.

Deactivating it for all relations.

On our demo where this cube is in a CW_CUBES_PATH directory, I had to add a
__init__.py file in this directory and to put it in PYTHONPATH to avoid a crash
on start, because of the attempt to find __module__ of registrable instances.

This problem hasn't been reported to cubicweb nor lgc because the proper fix
would be to have cubes as standard python packages. Until then we'll live with
those monkey-patches.

algorithm is now directly attached to the binary data object. It's less
intuitive from a data model POV but enhance the UI.

This triggered a bug in profile XSD generation which is also fixed by this
commit.

* introduce a dedicated class (to be styled later)
* print 'no value specified' even for no value elements

Those configure the ORM (pre-retrieved attribute and sort order) and provide a
'value_attr' attribute, to be used in the UI  to determine if the entity has
some business attribute or only some cardinality.

and use it for uicfg generation.

so they use a simple TextInput rather than a TextArea.

It's a non-sense to specify a value at profile creation time.

rather then adding them and skipping them later. That made later use of the same
data structure easier.

Related to #11447483

Since this element is optional, it needs special handling at XSD generation time
to compute its cardinality: if one of its subelement has mandatory card, its
cardinality should be 1, else 0..1 is fine.

Extract a (rtype, role) iterator on the XSD mapping out of
rtags_from_xsd_element function, to be reused by XSD generation.

Related to #11447483

we should replace '_from' by '_to' in the retrieved relation type else we
display the entity being shown, not the target value.

initialized with views from archivetransfer module for now.

for later usage from other modules

It's structural only.

to hide them from the primary view

None of them can be specified at profile creation time.

only keep them for now on "top-level" element (ArchiveTransfer, Binary and
Physical DataObject, ArchiveUnit), since it clutters the UI for low-benefit (who
will care to set all  those description in real-life?).

If there is a consensus on this (only keep a few annotated elements), we could
reimplement it more explicitly, but don't move until this is validated.

The former is an alternative of OpenType elements, the later is an OpenType
element, while we currently don't support such elements with still-to-be-defined
content.

This is needed to properly handle e.g. scheme constraints.

Depends on to-be-release refactoring in relationwidget cube.

Related to #11447483

Reorganize and simplify the existing test along the way.