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

ImportService statically sets parent process type to MultiVolumeWork #6182

Open
solth opened this issue Aug 12, 2024 · 0 comments
Open

ImportService statically sets parent process type to MultiVolumeWork #6182

solth opened this issue Aug 12, 2024 · 0 comments
Labels
bug import Import mappings and configurations

Comments

@solth
Copy link
Member

solth commented Aug 12, 2024

Describe the bug
During hierarchical metadata import, if a parent process is classified as document type Monograph, the document type is statically overwritten and replaced with MultiVolumeWork if the imported child records are classified as Volume, even if the current ruleset does not actually define a division with the name MultiVolumeWork. Additionally, the document type of all child processes is set to Volume, without regard to the actual classification result:

// Workaround for classifying MultiVolumeWorks with insufficient information
if (!allProcesses.isEmpty()) {
String childDocType = allProcesses.getLast().getWorkpiece().getLogicalStructure().getType();
Workpiece workpiece = tempProcess.getWorkpiece();
if (Objects.nonNull(workpiece) && Objects.nonNull(workpiece.getLogicalStructure())) {
String docType = workpiece.getLogicalStructure().getType();
if ((MONOGRAPH.equals(childDocType) || VOLUME.equals(childDocType)) && MONOGRAPH.equals(docType)) {
tempProcess.getWorkpiece().getLogicalStructure().setType(MULTI_VOLUME_WORK);
allProcesses.getFirst().getWorkpiece().getLogicalStructure().setType(VOLUME);
}
}
}

This is an old workaround that was indroduced during the development of hierarchical metadata import of Kitodo.Production 3. This was only intended as a temporary solution but still exists in the code to the present day.

To Reproduce
Steps to reproduce the behavior:

  1. Configure a ruleset that allows hierarchical import but does not define the division MultiVolumeWork
  2. Create a corresponding mapping file that classifies the imported parent process as Monograph, as defined in the ruleset, but not as MultivolumeWork, and the child processes as Volume
  3. Add a project and an import configuration that uses the ruleset and import mapping created above
  4. Create a parent process with child processes from a search interface that supports hierarchical import using this configuration
  5. Open the newly created parent process in metadata editor and see that it's type is set to MultiVolumeWork, which is not defined in the ruleset and therefore should be marked with a yellow background.

Expected behavior
The hierarchical import should not statically and incorrectly set the document type of processes to MultiVolumeWork. If a correct classification is not possible using the imported data and the classification rules in the import mapping file, or two document types are determined for child and parent process that are not allowed in a hierarchical relation according to the rules in the ruleset, a corresponding warning/error message should be displayed.

@solth solth added bug import Import mappings and configurations labels Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug import Import mappings and configurations
Projects
None yet
Development

No branches or pull requests

1 participant