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?
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