kitodo / kitodo-production

Kitodo.Production is a workflow management tool for mass digitization and is part of the Kitodo Digital Library Suite.
http://www.kitodo.org/software/kitodoproduction/
GNU General Public License v3.0
64 stars 63 forks source link

Automatic recognition of multivolume works #3407

Closed andre-hohmann closed 2 years ago

andre-hohmann commented 4 years ago

Problem

If a process for a volume of a multivolume work is created, the user has to set the “import depth” to 2.

importVolume

If this is forgotten, the process for the volume will be created without the parent process. Then, the process for the volumes has to be deleted and a new process has to be created.

Solution

It would be helpful, if a volume of a multivolume work is recognised automatically, by the creation of the process. Then, the application of the “import depth” is not necessary anymore or at least optional. For example, the attribute use="higherlevelIdentifier" or the doctype in the ruleset could be used to identify a multivolume work.

solth commented 4 years ago

This seems like a duplicate of #3257 and should have been fixed by #3287 some time ago.

andre-hohmann commented 4 years ago

Can i like your comment in GitHub? That would be great!

Kathrin-Huber commented 4 years ago

So this can be closed?

matthias-ronge commented 4 years ago

No, it's not the same as #3257. There, it is the matter about creating a link to the parent at import depth 1 for an existing parent document. This ticket deals with the fact that by default not yet existing parents are to be imported, unless the user actively wants it differently, but not that the user actively has to take action for that parents are also imported.

My proposed solution would be that in OPAC XML can be set whether an OPAC has the “import depth” option and with which default, or whether it is hidden, and then all parents are checked and imported if necessary.

andre-hohmann commented 4 years ago

I support that solution.

solth commented 2 years ago

importDepth is now already set to default value "2" if not actively configured differently by the user/admin. So in the default case, the system will always try to import the parent process, without the user manually activating this feature. I think that means the issue is resolved, isn't it?

andre-hohmann commented 2 years ago

Yes, think so, too. I will close the issue. If problems occur, we can re-open the issue.