Bug 12796

Summary: Default Messaging Preferences not Applied
Product: Koha Reporter: dmin <dminuck>
Component: PatronsAssignee: Bugs List <koha-bugs>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: dminuck, fred.pierre, gmcharlt, katrin.fischer, kyle.m.hall
Version: 3.16   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description dmin 2014-08-20 20:35:04 UTC
When a patron registers through the OPAC, the default messaging preferences for their category are not applied.  

Additionally, when changing a patron's category in the staff client (or when leaving the messaging preferences fields blank) the defaults are not applied, even though the template indicates that they will be. 

9556 addressed the second part and was reported as fixed and pushed to 3.10, but in 3.16 the bug persists.

We're on a customized version of 3.16, but have verified the bug on ByWaters demo which is on 3.17, and I assume 'stock'.
Comment 1 Fred P 2014-08-22 19:22:53 UTC
This may be the intended functionality. Activating the Enhanced Messaging Preferences allows patrons to select their messaging preferences. Changing their category should not necessarily change their selected preferences. 

Koha 3.16 behaves as you describe, however when creating a new patron, the correct default messaging preferences are correctly applied. It is only on a change of category that this problem manifests. 

The solution might be a system preference to "override patron messaging preferences on category change" or something to that effect.
Comment 2 Katrin Fischer 2014-08-23 18:34:28 UTC
Fred is right that changing a category should not change the message preferences - that is the correct behaviour as you would overwrite what the patron chose. Maybe there could be an option to 'force' the standard settings with a checkbox or similar. I think the first concern is a duplicate to 11693 - marking as such.

*** This bug has been marked as a duplicate of bug 11693 ***