Save button is not activated after change is made in edit mode

[henning-gerhardt]

Describe the bug
It is not possible anymore to save changes in different "dialog" forms as the save button is not activated after a change is made. This happens so far at

• changing roles
• changing import configurations

Maybe there are more dialogs which are broken

To Reproduce
Steps to reproduce the behavior:

1. Go to Projects -> Roles
2. Try to edit an existing role
3. 'Save' button stays gray and is not clickable

Expected behavior
After a change is made the Save button should be clickable and the change itself should be stored.

Release
current main Branch (2025-12-09)

[henning-gerhardt]

@solth mentioned and show it to me in a video call but did not open an issue report and now I'm affected too I opened the issue report.

[henning-gerhardt]

Even creating new roles is affected by this issue too but I can create new import configurations.

[solth]

@henning-gerhardt Contrary to what I showed you during our video call I was now able to edit existing and create new import configurations on my system in the current main branch.

I think this has something to do with the new limit of form parameters in Tomcat 10 @thomaslow mentioned in #6692:

Starting with Tomcat v10.1.42 (Ubuntu 24.04 is still on 10.1.16), a new limit for the maximum number of allowed form parameters was introduced (default 10), see CVE. Kitodo.Production requires a high number of form parameters to work (due to the complex forms). Tomcat needs to be configured with the maxPartCount parameter of at least 150. The problem occurs e.g. on the role edit page, which encodes whether a role is assigned or not for each individual role as a separate form parameter.

It seems I updated my server.xml according to @thomaslow 's hints and added the attribute maxPartCount=150 after we spoke. Apparently that fixed my problem with the import configurations.

Editing "Roles", as you described, was still not possible for me, though, even with maxPartCount=150. But this just seems to be slightly below our current number of permissions that can be configured for a role. When I changed the value from 150 to 200, the "role edit" page worked again and the save button was activated correctly.

I think we just need to check whether we have any forms in Kitodo.Production that would need an even higher value for maxPartCount (the metadata editor for processes with lots of metadata fields comes to mind), and then document this number in the installation guide, but otherwise, this does not appear to be a bug after all.

[thomaslow]

That is strange. I did test the role edit form with maxPartCount=150 and it works fine on my system. I assumed the role edit form was the worst-case scenario for this problem (because it did trigger a CI error). Do we have more roles authorities on some installations?

If the number of roles authorities depends on the number of clients, this could be a more serious issue, because then admins needs to calculate that number, e.g. clients * 50 + 100 or something like this.

EDIT: I meant authorities, not roles.

[henning-gerhardt]

It is possible that I forget to set this parameter in the server.xml file or the value is to less. If the meta data editor is affected too (did not check this right now): which number should be configured if you have thousand or more or just a really high number of meta data fields?

If I read the change in Tomcat 10.x correct that we can even hit the limit of the maxPartHeaderSize size too as this is set to 512 as default value.

Which value or values for both parameters maxPartCount and maybe maxPartHeaderSize should be used and documented?

As @thomaslow mentioned the amount of roles: I looked into my local system and there I had already 29 roles on two clients and in the cross table role_x_authority 389 entries and I know that we have a few more roles in our productive environment already as we stay or use many roles with small assigned amount of authorities than few roles with a lot of authorities assigned.

[solth]

Do we have more roles on some installations?

No, I think the problem lies in the database of my system, where I do have a few more authorities/permissions than in the current main branch, for branches currently in development.

[solth]

As @thomaslow mentioned the amount of roles: I looked into my local system and there I had already 29 roles on two clients and in the cross table role_x_authority 389 entries and I know that we have a few more roles in our productive environment already as we stay or use many roles with small assigned amount of authorities than few roles with a lot of authorities assigned.

I think this might be a misunderstanding. Not the number of roles is relevant on the "roleEdit" page, but instead the number of permissions (or "authorities") that can be assigned to a role. And since I have some additional, experimental authorities in my database (see above), the limit of 150 parts was slightly too low in my case.

But since these permissions will probably be added in the near future into the main branch, I think it would be wise to make for some "headroom" in our configuration (since we cannot change the Tomcat server.xml settings in our pull requests, it would be akward to always change the installation guide when a new permission is added and to inform all users that they have to change their server settings every time)

[thomaslow]

I think this might be a misunderstanding. Not the number of roles is relevant on the "roleEdit" page, but instead the number of permissions (or "authorities") that can be assigned to a role.

Yes, you are correct. My mistake, sorry.

[henning-gerhardt]

Okay. I had forgot to add maxPartCount parameter to the Tomcat server.xml. I added the recommended value of 150 and there is no change on editing a role. After I changed this parameter to a value of 200 changing roles did work - at least the save button switched from gray to blue.

Just a question as I have only limit knowledge about the UI: why is this role edit page (or may even others) are submitting changes in in so many multipart/form-data requests? My past experiences with such lists was: send the current list of used entries and a list of all possible entries to the client and the client send back the new list of used entries in one request. So far I know there was no usage of multipart form data requests.

[henning-gerhardt]

An other questions to rise my knowledge: I thought that the trigger of the save button relies on changes on client side by JavaScript or did every key stroke or interaction with lists send to the server and the server change the button from gray to blue?

[solth]

@henning-gerhardt I think the answer to both of your question lies in the depths of JSF. Yes, JSF sends partial requests to the server for user interactions that many frontend frameworks would probably only manage on the client side - I think to ensure the integrity of the so-called "ViewState" of a page.

And with regard to the multipart nature of the requests I think that is just the way JSF works. We didn't change the default behaviour of how JSF sends the information of the picklists on the "role edit" page to the server, AFAIK. Maybe there are some options we could try to change this behaviour, but that will require some research and tinkering, I guess.