GitLab

At some point, we'll probably have to:

* ensure action doesn't appear in case it shouldn't (eg reference archive units)

* move it to the archive unit tab rather than in the actions box

But this is a almost direct backport, enhancements will come later.

because I feel good that way. For better argumentation, see
http://stackoverflow.com/questions/32543608/deque-popleft-and-list-pop0-is-there-performance-difference#32543726

Before one had to pick a value...

Else it's built for each imported file, and this is very costly since when the
massive store is in use, table indexes have been dropped.

This will be done properly in next skos release which will accept extid2eid map
as optional argument.

For instance in SAEM, we need a store with custom metadata generator that will
generate ark for imported concepts.

This prepare the 'seda components' functionality from SAEM. For now, we don't
support data object as component, since most metadata moved to its related
archive unit with SEDA2.

We also have to change data object parent relation's cardinality since in case
of an archive unit as  component, we can't have this relation to the transfer
entity.

A test backported from saem cube put the light on this problem.

This will ease usage of the export view programmatically (for interaction with e.g.
oaipmh).

only order should be modified. Unclear why this occurs now even with python
hashseed to 0.

When the seda cube is used from saem_ref, an Agent type is already provided by
the prov cube. We should probably to that differently at some point, but that is
enough to move on for now.

by e.g. saem_ref which want to assign ark to created schemes.

when the instance's backend is postgres.

It doesn't make sense since there may be no parent rule. This is probably a bug
in the SEDA 2 specification.

Closes #15045330

Monkey-patch autoform to add an hidden input on the main form (we can't use
'formtype' since it's not appropriate (may be either 'main' or 'inlined'),
rather check if 'peid' is in kwargs to detect if this is the root form or a sub
form.

Then, propagate value found there as a form param when calling the ajax function
to render an inline creation form. Overriding is not necessary for edition form,
since in that case we already have the information.

Doing so allows to simplify the parent_and_container implementation, and some
place are we can now expect the container to be always detectable.

It seems that in test mode, monkey patch is done after cubicweb.web.views.forms
has been loaded, which hence references the original guess_field (monkey-patched
by cube'site_cubicweb).

Using the proper module fixes the problem.

We may hide the ignore all rules / ignore one rule complexity since there may be
only one inherited rule.

Do several tweaks to make it nice.

Note it doesn't work yet until the parent rule entity isn't created, because we
are not able to detect the parent transfer...

A simplified profile hides most of the complexity of a full seda profile. The
diagnosis tool indicates if a profile is using some construct which shouldn't
occur in a simplified profile.

This patch introduce a hook that will forbid to set 'simplified_profile=True' on
a profile which isn't compatible, or that we don't do incompatible change on a
simplified profile (though this should not occur from the UI).

Introduce a new 'simplified' fake format, indicating wether a profile may be
simplified or not. Profiles where are/may not be simplified are not expected to
be exportable to SEDA 1 / SEDA 0.2.

elements should be treaten FIFO.

Else we may end up in bad element ordering when some sequence is not generated,
eg when iterating on children, if first element is a skipped sequence, its
sibling elements will occur before its children, while they should not.

This will ease later error handling, i.e. to easily link to the tab when some
error is detected on a management rule, independantly of the rule's parent
(transfer or unit).

Considering we want one and only one rule and associated start date.

We need yet to consider this rule to allow or not to mark an existing profile as
simplified, and may still enhance rule inheriting management at some point.

Related to #15524229

For those entities, user cardinality will be hidden for simplified profile
because it's expected to be '1'. Changing the default in the schema will
ensure that entities created on a simplified profile will have the proper
cardinality, and that default values displayed on a full profile will be
compatible.