Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make behaviour of repeated import configurable #5613

Merged
merged 24 commits into from
Jul 13, 2023

Conversation

matthias-ronge
Copy link
Collaborator

@matthias-ronge matthias-ronge commented Mar 30, 2023

Adds a new control in the <settings> in the ruleset, which determines how metadata behaves in the "additional import" function. There are three settings, reimport="replace" will overwrite the existing metadata with the new ones (this is already the default case), reimport="add" will add the new metadata to the older ones, and reimport="keep" will keep the old existing metadata without replacing them.

Resolves #5410

@solth solth requested review from henning-gerhardt and markusweigelt and removed request for henning-gerhardt March 31, 2023 13:42
Copy link
Collaborator

@henning-gerhardt henning-gerhardt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only a code review. I did not check any added nor changed functionality.

If someone get this message as he use a non valid entry it would be very
difficult to find the right place and the causing issue. Maybe something
like that "Used not supported reimport case {}" where{} is replaced by
the wrong value can make it easier for him.
@@ -347,6 +363,7 @@
<xs:attribute type="xs:boolean" name="editable" default="true"/>
<xs:attribute type="xs:boolean" name="excluded" default="false"/>
<xs:attribute type="xs:boolean" name="multiline" default="false"/>
<xs:attribute type="ruleset:Reimport" name="reimport" default="replace"/>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we take keep as default value here. Cause overwriting the metadata always leads to the loss of customized content.

Copy link
Collaborator Author

@matthias-ronge matthias-ronge Apr 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far it has been common that we always use the default which reflects the previous functionality. This is, so that after an update, the administrators have to make as few adjustments as possible to keep the system working as before. And the previous behavior was, that the metadata was replaced. And, I'd vote for add as the default behavior, by the way.

Copy link
Collaborator

@IkramMaalej IkramMaalej May 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default value can not be somehow configurable and not hard-coded?
Some suggestions :

  • via kitodo-config-properties : new config line reimport.default=replace
  • or a better way via the GUI Mask : a new selectOneMenu input field with all the Reimport Enum entries in Edit ruleset and create new ruleset pages.
Capture d’écran 2023-05-26 à 10 46 24

Copy link
Collaborator

@BartChris BartChris May 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one question would be, wether this setting should be configurable

  • ruleset-wide?
  • project-wide?
  • client-wide?
  • system-wide?

I would probably also prefer to define it in the ruleset (or project) because it is a user decision and not an administrator decision in my opinion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your suggestions are worth considering, but that is beyond the scope of this issue, and also deviates from what the bar camp group agreed on at the practice meeting in last November. If you want this function, I would like to ask you to open a separate issue for it.

<setting key="metadataToAdd" reimport="add" />
<setting key="metadataToReplaceExplicitly" reimport="replace" />
<setting key="metadataToKeep" reimport="keep" />

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting with default without reimport attribute is missing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentional. <key id="metadataToReplaceByDefault"> has no <setting>, so the default is used.

currentMetadata.addAll(currentEntries);
break;
case REPLACE:
currentMetadata.addAll(updateEntries.isEmpty() ? currentEntries : updateEntries);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a conditional replacement. If updateEntry value is empty it will not replaced. I think this should be at least in the description of the ruleset.xsd.

Maybe it makes sense to make two replace variants out of this. e.g. like it is the case with git-reset https://git-scm.com/docs/git-reset. So REPLACE_HARD will be to replace independent of updateEntries value and REPLACE_SOFT checks the updateEntries value before.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. currentEntries is the metadata (for that one key) that is in the user interface. It may be manually entered, or it may have come from the previous import, if that import returned different fields, like first importing a manuscript record from the library catalog, and then importing the record for that manuscript from a secondary database, that holds different information. Without the check, any other metadata, that doesn’t come with the second import, would be deleted during the repeated import, which should not be what the user expects.

Copy link
Collaborator

@markusweigelt markusweigelt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Thx that you have implemented a reimport option that works even better and is simply more thought out.

Copy link
Collaborator

@IkramMaalej IkramMaalej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When a metadata is configured as reimport="add" in the settings section, and this metadata is also configured with maxOccurs="1" for example in the restrictions section on a structural element, after an additional import, this metadata will be displayed twice and not once, which should be the correct behavior.

Therefore, the maximum number of occurrences is unchecked for the case of reimport="add"

@matthias-ronge
Copy link
Collaborator Author

I've modified the code to take this into account. It was a major change and I've now extracted the function into its own class. I've added cases to the test to test this new behaviour as well.

@matthias-ronge
Copy link
Collaborator Author

@solth I tested locally, MetadataST finished without errors. I cannot say why it failed here.

@solth
Copy link
Member

solth commented Jun 1, 2023

@solth I tested locally, MetadataST finished without errors. I cannot say why it failed here.

6th build was successful 😅

@solth solth added the feature label Jul 8, 2023
@solth
Copy link
Member

solth commented Jul 10, 2023

@BartChris do you have any further change requests or would you approve this pull request?

@BartChris
Copy link
Collaborator

@solth I just had a note on the configurability of the reimport of metadata, but this is beyond the scope of this pull request. So i am fine with the pull request as it is right now.

Copy link
Member

@solth solth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matthias-ronge thanks a lot for this valuable contribution. I have no objections, just some tiny suggestions to optimize code style in a few places.

matthias-ronge and others added 5 commits July 13, 2023 09:34
…ReimportMetadata.java

Co-authored-by: Arved Solth <solth@effective-webwork.de>
…ReimportMetadata.java

Co-authored-by: Arved Solth <solth@effective-webwork.de>
…xml/Reimport.java

Co-authored-by: Arved Solth <solth@effective-webwork.de>
…/ProcessFieldedMetadata.java

Co-authored-by: Arved Solth <solth@effective-webwork.de>
@solth solth merged commit 4fa4310 into kitodo:master Jul 13, 2023
2 checks passed
@andre-hohmann
Copy link
Collaborator

@matthias-ronge : Thanks a lot for the additional functionality. We talked about that in the Community Board and want to ask, if you could describe the settings reimport="replace", reimport="add" and reimport="keep" in Regelsatz 3.x, as for example Schlüssel mit besonderer Verwendung.

We asked ourselves, if a delete-function is realized by reimport="replace":

  • If metadata in the source is deleted and an additional import executed, the metadata in Kitodo.Production is deleted (or replaced by "null").

Is this assumption correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make behaviour of repeated import configurable
7 participants