Editing UI results in sections disappearing from the interface

[arrlee]

I am having exactly this issue:
https://support.collectiveaccess.org/d/302154-editing-ui-results-in-sections-disappearing-from-the-interface

I migrated from 1.7.17 to 2.0.9

[collectiveaccess]

Please make sure the editor screen's role-based permissions are set to allow editing for all roles that confer editing privileges. Right now if not explicitly set they'll default to no access. In the next release the default will change to allow access - too many people are getting caught on this.

[peterjanssens]

It's not really "getting caught" I think. As long as you don't change old screens everything works as before, but any change to legacy screens makes them toast (without fiddling with the priviliges; what can be a lot of hassle if you have many legacy screens :/ and daunting for regular users).
If you want guard against this you would need to revise all screens, if you do it on a per accident-basis you need good and long lasting communication over the (sometimes changing) user base and/or administrators.

[collectiveaccess]

On older systems where the screen configuration hasn't been touched in a long while no privilege entries are defined. Once you edit and save the screen configuration those privilege entries are created, and they currently default to be restrictive.

A recent change added "all" and "none" controls on the privilege-settings UI with the aim of making it easier to turn those restrictive settings into permissive without having to click on each of a dozen or more drop-downs. The current dev/2.0 code goes further and makes the initial settings permissive. Generally, the tendency is to make defaults more restrictive and (theoretically) safer, but in this case it has been disruptive, and relatively few users rely upon screen-level privs anyway.

[peterjanssens]

thx!

[mbutel]

A temporary workaround is to truncate the screen x role table in the db. This brings back the functioning screens. But if you use the role permissions that won't help obviously.

…

On Wed, Jan 28, 2026, 11:17 peterjanssens ***@***.***> wrote: *peterjanssens* left a comment (collectiveaccess/providence#1846) <#1846 (comment)> It's not really "getting caught" I think. As long as you don't change old screens everything works *as before,* but any change to legacy screens makes them toast (without fiddling with the priviliges; what can be a lot of hassle if you have many legacy screens :/ and daunting for regular users). If you want guard against this you would need to revise all screens, if you do it on a per accident-basis you need good and long lasting communication over the (sometimes changing) user base and/or administrators. — Reply to this email directly, view it on GitHub <#1846 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOJN3LG7OP63RSS6IC735D4JDAJFAVCNFSM6AAAAACSYPZDS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJRGU3TCNRSGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[collectiveaccess]

Or just set the screen's role-based permissions appropriately?

[mbutel]

Sorry, I should have mentioned this: even setting the role permissions for the screen doesn't work. Maybe we are doing something wrong? Emptying the table was the only thing we found we could do to fix the problem. See attached video:

screen.mp4

[poplarmedia]

@Mubutel's solution to edit the db is the only one that works for me as well, on 3 different systems, php 8.3, Ubuntu 24.04 and 22.04.