Bug 31509 - Additional contents: Allow changing the column 'code' that groups records
Summary: Additional contents: Allow changing the column 'code' that groups records
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Marcel de Rooy
QA Contact: Testopia
Depends on:
Reported: 2022-09-02 08:12 UTC by Marcel de Rooy
Modified: 2022-11-14 22:31 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2022-09-02 08:12:51 UTC
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.
Comment 1 Marcel de Rooy 2022-09-02 08:27:33 UTC
And another reason: To refine the alias for CMS pages to something better than opac_inly_251 or staff_and_opac_345 etc.
Comment 2 Marcel de Rooy 2022-09-02 08:33:13 UTC
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?
Comment 3 Marcel de Rooy 2022-09-28 11:57:31 UTC
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.
Comment 4 Marcel de Rooy 2022-09-28 12:40:35 UTC
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.
Comment 5 Jonathan Druart 2022-10-14 10:36:18 UTC
If we really want to fix the mess we should split the table into 2 different tables.
Comment 6 Katrin Fischer 2022-11-14 22:31:35 UTC
(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.