GitLab

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.

- 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).

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.

this is so annoying.

Since the operation may be triggered by deletion of the relation, it may be
unadvertanly called by cascade when the data-object is being deleted.

introduced by c463fd270e81.

This should be specially handled even when the cloning starts from the archive
transfer.

Requires a yet unreleased fix in the compound cube.

e.g. while debugging an instance I attempted to display result of 'Any X, C
WHERE X container C' with unexpectedly to container for the entity, but I wasn't
able to display it because rset.one() raised an error since len(rset) was 2.

Even if the caller may be wrong, it seems ok to not call rset.one() if function
is called in an erroneous context and simply return None in such case.

And call the ajax API accordingly. We now allow on top of the earlier
"maybeParentOf" mecanism:

* to reorder binary / physical data object
* to reorder archive units.

To do so, we:

* turn 'inside' position while moving a node which is already a children node
  into 'before' + first children as target node,

* check if the position is correct, provided that we don't want to mix types:
  binary objects should be before physical objects which should be before
  archival units,

* call the ajax API by giving it the relative index above mentionned (i.e. index
  of the node within nodes of the same type).

by implementing ajax entry point and API on the jqtree adapter.

by implementing it on the JQTree adapter, but with only hard-coded position in
the js for now.

since this will soon become even more SEDA dependant.

because we have to keep this property in the targeted ordering implementation.

this is only unit-tested for now, it will be actually used by later commits.

so all implementation details of this ordering management is at the same place.

and move it to the itree module since this is entity logic, not view.

this is not used (left-over of some debugging session?)

based on reference's ordering attribute. Use the reference and not the data
object's ordering because it's the one used on the data objects tab for
simplified profiles.

rather use ORM controlled order, consistently with the UI. Let the doctor
diagnose ambiguities (done in previous commit).

This backout most parts of 4941eab6a289.

so it's importable at code generation time where the cubicweb_seda package isn't
available.

it's an implementation specific attribute, we don't want to see it in the UI.