Bug 41101

Summary: Allow extended patron attribute to be non-editable in the staff interface.
Product: Koha Reporter: CJ Lynce <cj.lynce>
Component: PatronsAssignee: CJ Lynce <cj.lynce>
Status: Needs Signoff --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: Chip.Halvorsen, gmcharlt, kyle
Version: Main   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: Sponsored Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 41067    
Bug Blocks:    
Attachments: Bug 41101: DB Updates
Bug 41101: Add ability to make patron extended attributes read-only in staff interface.

Description CJ Lynce 2025-10-24 19:42:44 UTC
It would be helpful to have a selectable option for extended patron attributes to be non-editable in the staff interface, but still be show to staff. The current options only allow to make an extended attribute editable/non-editable in the OPAC.

For example, an extended patron attribute is utilized by our materials recovery service plugin (Unique Management Services - Gentle Nudge) to track if a patron is or is not in a recovery status. The plugin handles changing of the attribute automatically, and staff editing the attribute manually causes issues with the plugin processes. Staff still need to see if the patron is in a recovery status, but should not be able to change it themselves.

Getting into more specifics, I could see 'superlibrarian's being able to change the status to correct certain issues with the plugin, but not most staff.
Comment 1 CJ Lynce 2025-11-04 20:52:13 UTC
Created attachment 189064 [details] [review]
Bug 41101: DB Updates
Comment 2 CJ Lynce 2025-11-04 20:52:16 UTC
Created attachment 189065 [details] [review]
Bug 41101: Add ability to make patron extended attributes read-only in staff interface.

This patch adds the ability for a Patron Extended Attrtibute to be marked as read-only
    in the staff interface for all staff users, except 'superlibrarian's.
    This allows patron attributes to be used by plugins or other features to track
    statuses without allow staff users to change these attributes and cause
    potential unintended issues, while still allowing the statuses to be visible to
    staff.

Testing PREP WORK
A. Create a new staff patron and assign the following permissions
    i.  Staff access, allows viewing of catalogue in staff interface (catalogue)
    ii. Add, modify and view patron information (borrowers)
B. Create a couple of new 'Patron attribute types' under Administration
    i. Vary the following settings
        a. Staff interface mandatory
        b. Authorized value category (include some with no authorized value)
        c. Set some as data values.

To Test
1. Apply patches, run updatedatabase, and restart_all services.
2. Login as 'koha' in the staff interface.
3. To go Administration -> Patron attribute types
4. For various attributes, do the following:
    A. Check the "View-only in Staff interface:"
    B. Verify 'OPAC mandatory' is unchecked and disabled when 'view-only' is checked.
    C. Save these settings
5. Open a test patron and edit said patron.
6. Set values for various the extended patron attributes. Leave some blank to test as well.
7. Logout of the 'koha' user.
8. Login to the staff interface with the user you created in PREP WORK A., above.
9. Open the same patron, and edit the patron.
10. Verify the following things related to the extended attributes.
    A. Attrtibutes marked as view-only cannot be changed.
    B. Date attributes marked as view-only cannot be changed, and do not show a datepicker.
    C. Attributes marked as view-only do not have a Clear, remove, or X button to clear.
11. Change some information on the patron and save the patron.
12. In the Patron details view, verify that your attributes are unchanged and still populated.

Sponsored-by: Westlake Porter Public Library <https://westlakelibrary.org>
Comment 3 CJ Lynce 2025-11-04 20:54:26 UTC
Here is a initial try at implementing this. I welcome any feedback.