Assign mappings to concordances

[nichtich]

Selection of mappings for catalog enrichment (coli-rich) can be done based on mapping status (approved, voted) and/or creator accounts. First use-cases showed that selection of mappings based on concordances would be useful as well. By now Cocoda does not allow to assign mappings to concordances.

Requires https://github.com/gbv/jskos-server/issues/98 - see details in the discussion.

[stefandesu]

Some notes:

• Cocoda needs to use the same logic as jskos-server when determining whether a user can perform certain actions. Not sure if there's an elegant way to not duplicate the code though. 🤔
• We need an interface to create/edit concordances. fromScheme and toScheme can only be set when creating and not be changed afterwards (or only if there are no mappings assigned to it yet). What can be changed after the fact are scopeNote (a description of the concordance), creator (including the order because the top creator is shown in the concordances list), and contributor (can add mappings to the concordance, but not edit concordance metadata).
• We need an interface to specify a concordance for a mapping. Maybe that could be simply a button in MappingEditor that opens a popover, and suggested concordances should be smart, i.e. only show those that a) the user can write into, and b) has the same from/toScheme as the mapping.
• We should provide an interface to bulk-add mappings to a concordance. For example, it could be possible to perform a search (show me all mappings I created between schemes X and Y), and then add all those mappings to a concordance or create a new concordance from those mappings.

Definitely not an easy task in regards to UI/UX, but in my mind it is more or less clear how it could look like. Please add any suggestions to this. I would like to start the implementation soon. (Although we still need to implement the server side first.)

[nichtich]

These are multiple issues. Priority is extension of MappingEditor to assign/remove/change which concordance an individual mapping belongs to (see newly created issue #652). An interface to manage concordances could be next. I don't think we need or want bulk-editing.

Open question: when are newly created mappings automatically assigned to a concordance and to which?

[stefandesu]

Open question: when are newly created mappings automatically assigned to a concordance and to which?

I think this should definitely be possible if we consider the use case of creating many mappings in a row for the same concordance. How about remembering the last used concordance and select that automatically if fromScheme/toScheme match?

[nichtich]

How about remembering the last used concordance and select that automatically if fromScheme/toScheme match?

This is good enough to start with. The last used concordance should also be shown and selectable in the settings.

[stefandesu]

We have a first implementation available in https://coli-conc.gbv.de/cocoda/test/. 🥳 However, only certain people are allowed to create concordances and it only works in "Concordance Registry (dev)", i.e. it is only for testing.

What works:

• After selecting a source and target scheme, it is now possible to create a new concordance under "Concordances" in the top right. New concordances require a notation that will be used as an URI postfix.
• Concordance descriptions can be updated after creating a concordance.
• Concordances without mappings can be deleted.
• Own mappings can be added to a concordance or removed from a concordance via a dropdown in Mapping Detail (small info icon in list of mappings). Only applicable concordances (i.e. source/target scheme match and user can write into concordance) are shown.

What doesn't work:

• [x] Deleting mappings will not refresh a concordance's extent. Needs to be fixed here AND in jskos-server.
• [x] If you can't edit a mapping, the concordance will not be shown correctly in Mapping Detail.
• [x] It is possible to change a mapping's source/target scheme even though it belongs to a concordance. That should not be possible.
• [x] It is currently not possible to restore a deleted mapping if it belonged to a concordance.

Also, the interface is very basic and functionality is fairly hidden. Right now, this is more about testing the technical infrastructure. After making sure that it works technically, we can improve the interface.

[stefandesu]

• [x] Assign concordance to mapping via MappingEditor (#652)
  • This is easy for existing mappings, but it needs to be extended so it works for new mappings as well. The issue is that in that case, we first need to save the mapping (POST), then add it to the concordance (PATCH). The same thing already happens when restoring a mapping from trash, so implementation shouldn't be a big problem. Ideally, this is included in the postMapping method so that it's as easy as possible.
• [x] ConcordanceDetails modal
• [x] Option to add additional contributors to concordance
  • Only via user URI for now because there is no user search at the moment.
• [x] Allow selecting fromScheme/toScheme from Add Concordance modal
• [x] Allow editing of mappings inside concordance even if creator differs
• [x] Consolidate VueX "mapping" module into cdk mixin and use that in MappingEditor (fixes certain issues) Adjust how Vuex mapping module determines whether mapping can be created/updated/deleted
• [x] Don't allow deleting mapping that is part of concordance if user is either not creator of mapping or not contributor of the concordance

[stefandesu]

Now merged into dev. 👍 As far as I can see, everything's working well now, even if some parts of the interface are not perfect. We can improve over time. For further suggestions and bug reports, please open separate issues.