Bug 30319 - Patron self-modification values not retained if field blocked in PatronSelfRegistrationBorrowerUnwantedField
Summary: Patron self-modification values not retained if field blocked in PatronSelfRe...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low major
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-18 20:09 UTC by Andrew Fuerste-Henry
Modified: 2024-07-19 15:27 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:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2022-03-18 20:09:52 UTC
When a field is hidden for self-registration, Koha is mistakenly discarding values for that field in self-modification. Somehow these two sysprefs are not being enforced distinctly.

To test:
1 - turn on OPACPatronDetails
2 - confirm PatronSelfModificationBorrowerUnwantedField is blank, all fields allowed
3 - set PatronSelfRegistrationBorrowerUnwantedField to hide Title
4 - log into the opac, go to self mod (/cgi-bin/koha/opac-memberentry.pl), set a title (it is not hidden, which is correct), and save your updates
5 - go to the patron modification page in the staff interface (/cgi-bin/koha/members/members-update.pl), confirm your modification request is there but shows no changes
6 - update PatronSelfRegistrationBorrowerUnwantedField to allow title
7 - repeat step 4
8 - your new modification request shows a change to title
Comment 1 Katrin Fischer 2024-06-28 15:21:36 UTC
I just ran into this and only found the duplicate after writing up my test plan and everything... so adding it here instead:

If a field is set as Unwanted for the self registration form, it will not be reported to the library if an address change is requested by a registered user from their account.

To test:
- BorrowerUnwantedField: Set a field of your choice to "unwanted". Example: sex
- Make sure same field is visible in:
  PatronSelfModificationBorrowerUnwantedField	
  PatronSelfRegistrationBorrowerUnwantedField
- Log into your OPAC account
- Request a change of said field
- Check the change request in the staff interface: field will be missing
- PatronSelfRegistrationBorrowerUnwantedField: Update to make field visible
- Request another change from the OPAC
- Verify field is now visible in the change request

The PatronSelfRegistrationBorrowerUnwantedField should not influence the change requests, only PatronSelfModificationBorrowerUnwantedField should.

I am updating the severity as this affects the library - user communication and is basically causing an unnoticeable data loss.
Comment 2 Jennifer Marlatt 2024-07-08 18:00:56 UTC
This is causing problems at our library especially for patrons who rely on emails to alert them to due dates, renewals, etc. Patrons are attempting to add/update their email addresses through the OPAC. The request to update a patron record appears in the staff interface, but the data is not transferred with the request.