GitLab

Still log the information, just in case...

We only update the file, that will be used in SAEM upon instance
creation. We do not handle migration of existing instance.

We extend the logic of "seda.doref.del" hook so that it not only handles
the case of "simplified profile" but also the case of archive unit not
related to a profile. In the later case, we check that the container of
"SEDABinaryDataObject" is really a "SEDAArchiveUnit" (not sure what else
it could be) and trigger the operation deleting the binary data-object
when its parent object reference (SEDADataObjectReference entity) is
deleted.

Accordingly, we rename hook and operation classes and update their
docstring.

This resolves CONSEJIRA-643 but making deletion of an archive unit
containing a binary data object but not related to profile. New test
goes into test_schema.py below other tests related to the hook we
modified.

This is a preparatory refactoring to ease introduction of a functional
change in the next changeset.

This follows-up on changeset 0b663b4c509f which made
ProfileTreeComponent class abstract and introduced a regression in that
the component was then only selectable for SEDAArchiveTransfer entities,
hence making the tree component disappear when navigating to leafs of
the tree.

A concrete class of this component must exist for all possible entity
types under a SEDAArchiveTransfer entity. We thus extend the selector of
TransferTreeComponent (renamed as ProfileTreeComponent) to list all
entity types. Accordingly, we make it clearer that the base class is
abstract by renameing it.

This is known to produce non-reproductible tests. Furthermore we deploy using
pip and virtualenv on Centos 7 but we are testing on Debian stretch, so testing
global site package on jenkins has no advantage.

Thus we can disable some whitelist_externals which are no longer required.

- Container machinery got introduced in 143ae7a4a964, at that time the
  "container" relation was mandatory (on subject) for all entity types.
- Integrity of this relation relied on the assumption that the relation
  was mandatory. (I.e. all entities mush have a link to their container
  and the only way to remove this link is to remove the container entity
  itself).
- In a88deb387b2b, this assumption got broken as "container" relation
  was made optional for SEDAArchiveUnit as a subject. From there, when
  an archive unit got unlinked from a profile (through deletion of the
  "seda_archive_unit" relation), a "container" relation remained set.
- This is problem since permission (especially on "delete" action)
  relies on the presence or absence of this relation. For instance,
  one would get an error when trying to delete an archive unit they just
  unlinked from a profile because they have no rights to delete the
  profile.

So we fix this by dropping the "container" relation when a
"seda_archive_unit" relation is deleted through a new hook.

Additional test goes in test_entities.py as other container-related
tests live there.

In migration, we drop spurious "container" relation (not sure there are
some).

When both cubes.skos and cubicweb_skos are used to import the same
module, appobjects are registered using the wrong objid.

This is particularly problematic in register_and_replace function of
registries which relies on the objid of appobjects to find which object
to replace.

We make ProfileTreeComponent abstract to avoid selecting it for any
entity that can be adapted to ITreeBase. Indeed, we don't want Concepts
to be rendered as contextual components in cube saem.

We then create a TransferTreeComponent extending ProfileTreeComponent
the same way we made the UnitTreeComponent.

In the component_unit predicate, we handle the case where
_seda_container_from_context returns None by returning 0.
This can be the case when the predicate is called with a non seda
entity.

The idea is to have the generation of xml:id attribute configurable
based on entity context. So we create an entity adapter IXmlId that
default to the current implementation. This will be extended in
cubicweb-saem_ref where we'd want to use the ARK identifier to produce
this xml:id attribute.

In profile_generation module, we rename eid2xmlid function as xmlid and
make it accept an entity.

We drop monkeypatches and hacks introduced in 49d118aa8254 in 2016 which
were supposed to be transient waiting for a cubicweb-skos release which
came a long time ago now.

Now we build the extid2eid dict before importing LCSV concept schemes
and pass it to store_skos_extentities() so that it will be re-used for
all files instead of re-built. Both lcsv_import and lcsv_check functions
are updated, as the latter is used in test_dataimport.py as a kind of
"mock" but must respect the former's interface. Also note that we now
have to update 'extid2eid' dict after creating a new concept scheme
(with init_seda_scheme()): while this sounds perfectly reasonable, I
don't completely understand how this works without this before...

We update requirement on cubicweb-skos so that the latest release is
used (though some previous release would probably work as well, but I'm
not sure which and it's not so easy to test).

Avoids FutureWarning: The behavior of this method will change in future
versions. Use specific 'len(elem)' or 'elem is not None' test instead.

I.e. instead of having two (clickable) buttons, one with the action text
(e.g. "add") and one with the caret and only the latter with the effect
of toggling the menu, we now only produce one button with both the
action text and the caret as content. This way, the user won't get
confused when clicking on the text as the menu will toggle.

This makes the module syntactically valid with Python 3. Flake8 does not
complain accordingly.

And drop monkeypatch now in this version.

There may be cases where several concepts use the same label, mostly in the case
of format identifier but do the same thing for mime types as a safety belt.

because they don't need the heavy setup of the former class.