See also bug 29113 and bug 31503. Bug 31503 adds a location PatronConsent but I need codes like PatronConsent_[suffix] where suffix points to a specific patron consent type.
And another reason: To refine the alias for CMS pages to something better than opac_inly_251 or staff_and_opac_345 etc.
Thinking of two ways to proceed: Add the code field back for blocks and pages: It could be left empty, the system creates a default. If you fill it, check if combination default+code is unique. Changing an existing record should update all children. Add a separate page or modal to change it for existing records. Are you sure etc. More specific action to change it. Safer? Any thoughts?
I would like to proceed here as follows: Allow to change code on the listview form with a separate action that updates the record for default and associated records (via code). Check if the new code is unique. Note that I hacked my 21.11 by adding this one line in the block for saving a new record to achieve a similar effect: + $code = $cgi->param( 'title_default' ) if !$code && $category eq 'html_customizations' && $location eq 'opac_only'; # RMA hack I use opac_only here to mimic the Pages feature in 22.11. We only need to update the title for default after saving a new record. So this is a onetime update of code. This report should make that no longer needed.
With reference to the above, we also use code as a kind of alias in the opac-page URL now in multi-languages setups. This also might make a change of code desirable when you for instance have a page that changes location from staff_only to staff_and_opac while the code is still staff_only_123. Note that you could imagine such a workflow where a page is initially created for staff and when approved moves to opac. The URL would be silly when it still contains staff_only.
If we really want to fix the mess we should split the table into 2 different tables.
(In reply to Jonathan Druart from comment #5) > If we really want to fix the mess we should split the table into 2 different > tables. +1
Closing this one in favor of the header/child table development on bug 31383.