-
Notifications
You must be signed in to change notification settings - Fork 64
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
Conversation
There was a problem hiding this 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.
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/Settings.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/Settings.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/RulesetManagement.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/RulesetManagement.java
Outdated
Show resolved
Hide resolved
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.
f20b293
to
b83c520
Compare
@@ -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"/> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 theReimport
Enum entries inEdit ruleset
andcreate new ruleset
pages.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" /> | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/RulesetManagement.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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"
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. |
@solth I tested locally, MetadataST finished without errors. I cannot say why it failed here. |
6th build was successful 😅 |
@BartChris do you have any further change requests or would you approve this pull request? |
@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. |
There was a problem hiding this 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.
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/ReimportMetadata.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/ReimportMetadata.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/RulesetManagement.java
Outdated
Show resolved
Hide resolved
Kitodo-DataEditor/src/main/java/org/kitodo/dataeditor/ruleset/xml/Reimport.java
Outdated
Show resolved
Hide resolved
Kitodo/src/main/java/org/kitodo/production/forms/createprocess/ProcessFieldedMetadata.java
Outdated
Show resolved
Hide resolved
…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>
@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 We asked ourselves, if a delete-function is realized by
Is this assumption correct? |
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, andreimport="keep"
will keep the old existing metadata without replacing them.Resolves #5410