-
Notifications
You must be signed in to change notification settings - Fork 63
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
Subordinate processes cannot be linked to superordinate process in another project #5626
Comments
I am wondering wether processes of the two projects must have the same ruleset in order for that to work. @matthias-ronge made a comment on that here: #4941 (comment). Or more precise: The two processes probably still have to share the same process template (which defines the ruleset), even if relations to processes in other projects are allowed. So your issue is about being less strict on the project association, but still keep the ruleset check in place, right? |
Yes, the ruleset must be the same, but relations between processes of different projects with the same ruleset should be possible. In my examples, the projects have even the same process template "Standard". I can find migrated processes of volumes, which belong to different projects (with the same ruleset), but are linked to the same superordinate process. |
This would effect two constellations, as far as i can see.
kitodo-production/Kitodo/src/main/java/org/kitodo/production/services/data/ProcessService.java Line 800 in 766c5eb
the comment there does not describe the current implementation because only processes in the same project can be linked: "Searches for linkable processes based on user input. A process can be linked if it has the same rule set, belongs to the same client, and the topmost element of the logical outline below the selected parent element is an allowed child. For the latter, the data file must be read at the moment. This will be aborted after a timeout so that the user gets an answer (which may be incomplete) in finite time" What is described in the comment is already implemented when searching for children of a parent process. When searching for child processes the project is not taken into account: kitodo-production/Kitodo/src/main/java/org/kitodo/production/services/data/ProcessService.java Line 763 in 766c5eb
kitodo-production/Kitodo/src/main/java/org/kitodo/production/services/data/ImportService.java Line 938 in 9923493
We could also get rid of the project filter there, too. The question is: what happens, if there a multiple parent processes (with the same identifier in the source metadata system) in different projects. Given the way the automatic linking system during import is implemented right now, there is no way to control, which of those parent processes the child processes would be linked to, when the same-project criteria is removed. Maybe that is also the reason for the current behavior. Maybe we can implement a mechanism which follows this rule: a match in the current project is given preference. So if there is already a parent process in the current project, the child process is linked to that. If not it can also be linked to one parent process in another project. What do you think? |
@BartChris : Thanks a lot for your investigation! The behavior should generally be discussed in a larger group. Otherwise, I expect constant adjustments, each of which causes irritation. In my opinion, it is not necessary to create several parent processes (with the same identifier of the source metadata system) in different projects. On the contrary, it is usually desired to "merge" the respective volumes in the presentation. Furthermore: In our presentation, the processes with the same id would be overwritten, if the URL, prefixes, ... are not adjusted. I also want to point out that migrated processes from multiple projects are linked to one parent process. From my point of view a uniform procedure should be applied. |
@BartChris : Thanks again for your feedback. i have created a discussion for this issue and asked via the mailing list for feedback: Unfortunately, there is no discussion and i ask myself, if the issue is relevant for the users of Kitodo.Production.
In my opinion, it would be possible to search in the tab "Title record link" via "Search process title" for all parent processes with the same process title/identifier - if there are several ones.
As discussed in #5635 i think, this could be resolved by the organisation of workflows and project management/admissions.
That might be difficult in detail. What happens, if only one parent process is available? Should it be offered to create a new one? I am afraid, that this becomes quite complicated once you start to create the concept - and i am still not sure, if this is really needed. @solth : Would you accept the change if the filter for project-id (#5626 (comment)) is removed? |
@andre-hohmann Thanks a lot for your thoughts on that. I agree with your assessments. I have two further additions to make. The constellation described by @matthias-ronge in the discussion #5635 (comment) In Fact: this is how the system is working right now. My description above was not complete. Right now the system does not only check, whether a possible parent process is in the CURRENT project of the child process.
This happens here: Line 77 in 9826e41
and here Line 128 in 9826e41
So every search request automatically requires the parent process to be in the current user's client AND list of projects of that user. So i think it is impossible right now that a user can link to a process to which he or she has no access. So i would say, that we should remove the condition that the parent process is in the CURRENT project. But we can keep the condition that the user has to have access to the project, where the process resides and limit the search to the current client, That should address the problem with the permissions: If a user cannot link to a parent process, he needs to get access to the project where the parent process is located. Links can only be created to processes on the same client (the one which the user is logged in). |
I think i can go with the following solution: The child process gets linked to whatever parent it finds (taken the above considerations into account). It might link to the wrong project. If that happens the user manually has to correct a wrong association then. That should always be possible. Edit: |
There is probably one caveat. The way the search queries are constructed right now, it is probably the case, that a user without permissions to the project of a parent cannot establish a relation to that parent process, because the system will not find it. |
@BartChris : Thanks a lot for the investigation! I hope i understand the concept and i try to answer the different aspects. First, I can agree with your proposal to check first the parent processes of the same project of the child process and then parent processes of other projects (#5626 (comment)). We will hopefully have only one parent process with the same identifier - therefore it should not affect us in the SLUB Dresden. Second, I would support the following options:
If we agree on that, the question remains, who decides, if or how the changes are applied. |
@andre-hohmann sorry for my late response. I agree that the restriction to parent processes in the same project should be removed to avoid creating duplicate processes within the same client. I do not remember why that restriction was added in the first place. I also agree that the restriction to processes within the same client should not be touched. Data from individual clients should ideally be totally separated from each other. I am just not sure about the following two points you made:
In my opinion, the restriction to processes of projects to which the current user has access should not be removed, since this would undermine the current permission system and would probably produce difficult to find errors later on. Technically, it's also in contrast with your next point:
This won't work if we really remove the restriction to projects to which the user has access, because linking processes will change the parent process - specifically, it will add a METS pointer to the child process, hence changing the parent process' data. Therefore I would opt for keeping the strict limitation to projects to which the user has access. In my opinion making sure a user has sufficient access to all projects for which he might digitization processes is the responsibility of the organisation, not the software. Weakining the permission system or working around it instead is not the right way to solve this, I think. The best - and probably most expensive - way to solve this at least for manual linking would be to display the potential parent processes of unaccessible projects in the "title link" tab, but make them non-selectable, with a mark and tooltip explaining as to why they cannot be linked by the user in the current state (e.g. he does not have access to the corresponding parent process' project). Then, the process creation could be canceled, the user is added to the project in question by the admininstrator according to the requirements and then the user could create the new process with valid link to the parent in another project. For automatic linking during hierarchical import this would probably have to be extended to warn the user that a potential parent process exists in another, unaccessible project. This should ideally give the user the option to cancel the import, so that the required permission adjustments decribed above can be performend, or to willingly create a new, duplicate process without changes to the project permission structure. |
@solth : thanks for your extensive reply. Sorry for closing the discussion too hastily. |
Describe the bug
If a subordinate process (for example: volume) is created and the superordinate process exists, but in another project, the two processes are not linked during the import.
In spite, a second superordinate is created, it the import depths is
2
.If the process is linked manually, the following message occurs:
The search completed, but nothing was found. You can only find processes that have the same project and rule set.
To Reproduce
Steps to reproduce the behavior:
2
2 processes retrieved from K10Plus-SLUB-PICA
The search completed, but nothing was found. You can only find processes that have the same project and rule set.
is shownExpected behavior
It should be possible to link subordinate processes of different projects with the same superordinate process, regardless of its project affiliation.
This has worked in earlier versions.
Screenshots
![FehlerUeberordnung01](https://user-images.githubusercontent.com/14835770/232036119-70d2c13e-97ef-4f4e-adcc-fcd6ef255120.jpg)
Release
KITODO.PRODUCTION Version 3.6.0-SNAPSHOT
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: