Bug 38769

Summary: Add plugins consent types to OPAC self registration process
Product: Koha Reporter: Martin Renvoize (ashimema) <martin.renvoize>
Component: OPACAssignee: Martin Renvoize (ashimema) <martin.renvoize>
Status: Needs Signoff --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: jake.deery, m.de.rooy
Version: Main   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: Unsponsored Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 31503    
Bug Blocks:    
Attachments: Bug 38769: Display plugin consents on self registration
Bug 38769: Display plugin consents on self registration
Bug 38769: Add consents column to borrower_modifications
Bug 38769: Update DBIC schema for consents column
Bug 38769: Process consents on patron self-registration
Bug 38769: (follow-up) Exclude consents from approve() method

Description Martin Renvoize (ashimema) 2024-12-21 15:18:33 UTC
The new functionality allows plugins to add patron consent types to the system doesn't expose those consent types to the user at self registration time like we do for the data processing consent.  We should have that option
Comment 1 Martin Renvoize (ashimema) 2024-12-21 16:15:38 UTC
Created attachment 175882 [details] [review]
Bug 38769: Display plugin consents on self registration
Comment 2 Martin Renvoize (ashimema) 2024-12-21 16:23:53 UTC
Created attachment 175883 [details] [review]
Bug 38769: Display plugin consents on self registration
Comment 3 Martin Renvoize (ashimema) 2024-12-21 16:24:26 UTC
Work in progress.. currently this patch just displays consent options and doesn't record them against the self-registered user yet.
Comment 4 Martin Renvoize (ashimema) 2026-02-02 12:31:33 UTC
Created attachment 192311 [details] [review]
Bug 38769: Add consents column to borrower_modifications

Add a new 'consents' column to the borrower_modifications table
to store JSON-encoded plugin consents during self-registration
when email verification is enabled.

This allows plugin consents to be stored alongside other patron
data during the email verification workflow and processed after
the patron verifies their email address.
Comment 5 Martin Renvoize (ashimema) 2026-02-02 12:31:34 UTC
Created attachment 192312 [details] [review]
Bug 38769: Update DBIC schema for consents column

Add the 'consents' column definition to the BorrowerModification
DBIC schema class to match the database table change.
Comment 6 Martin Renvoize (ashimema) 2026-02-02 12:31:35 UTC
Created attachment 192313 [details] [review]
Bug 38769: Process consents on patron self-registration

This patch adds support for plugin consent types to self-registration:

- Add proper display of plugin consents with consent_[type] naming
- Only show plugin consents for new registrations (not edit mode)

Backend changes (opac-memberentry.pl):
- Add ParsePluginConsents() to extract consent checkbox values
- Save plugin consents when creating patron directly
- Store consents as JSON for email verification workflow

Email verification (opac-registration-verify.pl):
- Process stored plugin consents after email verification
- Create Koha::Patron::Consent records for each agreed consent

Test plan:
1. Enable a plugin that provides patron_consent_type hook
2. Go to OPAC self-registration page
3. Verify plugin consents are displayed
4. Submit registration with/without email verification
5. Verify consents are saved to patron_consents table
Comment 7 Martin Renvoize (ashimema) 2026-02-02 12:37:36 UTC
Created attachment 192314 [details] [review]
Bug 38769: (follow-up) Exclude consents from approve() method

The approve() method in Koha::Patron::Modification is used for
staff approval of patron profile updates. Since the 'consents'
field is specific to self-registration and is handled separately
in opac-registration-verify.pl, we need to explicitly delete it
from the data hash to prevent any potential issues.

This matches the pattern used for extended_attributes.