Bug 9254 - New option to block patrons from changing messaging preferences in OPAC
Summary: New option to block patrons from changing messaging preferences in OPAC
Status: RESOLVED DUPLICATE of bug 12528
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P2 enhancement (vote)
Assignee: Vitor Fernandes
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-10 15:18 UTC by Vitor Fernandes
Modified: 2016-09-26 04:41 UTC (History)
14 users (show)

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


Attachments
Bug 9254: Problem with EnhancedMessagingPreferences (6.06 KB, patch)
2012-12-19 18:41 UTC, Vitor Fernandes
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9254: Problem with EnhancedMessagingPreferences (6.07 KB, patch)
2012-12-21 16:09 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.17 KB, patch)
2012-12-21 16:13 UTC, Kyle M Hall
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9254: Problem with EnhancedMessagingPreferences (6.63 KB, patch)
2013-02-01 14:19 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.38 KB, patch)
2013-02-01 14:19 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 9254: Problem with EnhancedMessagingPreferences (6.23 KB, patch)
2013-02-28 12:26 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.32 KB, patch)
2013-02-28 12:27 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 9254: redirect to 404 if at least 1 pref is off (2.18 KB, patch)
2013-08-14 14:22 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 9254: Problem with EnhancedMessagingPreferences (5.17 KB, patch)
2015-04-18 21:38 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.28 KB, patch)
2015-04-18 21:39 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: redirect to 404 if at least 1 pref is off (2.03 KB, patch)
2015-04-18 21:39 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.27 KB, patch)
2015-04-25 16:03 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: redirect to 404 if at least 1 pref is off (2.03 KB, patch)
2015-04-25 16:03 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: Problem with EnhancedMessagingPreferences (5.17 KB, patch)
2015-04-25 16:06 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: Followup - Rename pref to EnhancedMessagingPreferencesOPAC (5.27 KB, patch)
2015-04-25 16:06 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 9254: redirect to 404 if at least 1 pref is off (2.03 KB, patch)
2015-04-25 16:06 UTC, Mark Tompsett
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Vitor Fernandes 2012-12-10 15:18:28 UTC
First I don't know the right component to this bug.

The problem is the following:

- when enabling EnhancedMessagingPreferences, the staff client if able to set the messaging preferences for the patrons categories, and then for the patron (normally the messaging preferences are the same for everyone)
- when enabling EnhancedMessagingPreferences, the patrons can set in the OPAC their messaging preferences, which can be against the library rules

Solution:

- enabling EnhancedMessagingPreferences, should allow the the staff client to set the patrons messaging preferences
- enabling EnhancedMessagingPreferences, should't allow patrons to set their messaging preferences (the link doesn't appear in the usermenu.inc)
- should be another preference to allow the patrons to set their messaging preferences.
Comment 1 Nicole C. Engard 2012-12-12 16:22:11 UTC
I agree, it would be nice is there was a way for this preference to be split in to two. One for the staff and one for the OPAC - I'd add that it would be nice if this preference were a list of messages you could offer.  So if you wanted to only allow holds and advanced notices to be options you could put 'hold|advanced|' or something like that in the preference.

Nicole
Comment 2 Vitor Fernandes 2012-12-19 18:41:42 UTC Comment hidden (obsolete)
Comment 3 Kyle M Hall 2012-12-21 16:09:41 UTC Comment hidden (obsolete)
Comment 4 Kyle M Hall 2012-12-21 16:13:55 UTC Comment hidden (obsolete)
Comment 5 Jonathan Druart 2013-01-04 13:53:43 UTC
Last patch needs a signoff.
Comment 6 Bernardo Gonzalez Kriegel 2013-02-01 14:19:40 UTC Comment hidden (obsolete)
Comment 7 Bernardo Gonzalez Kriegel 2013-02-01 14:19:49 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2013-02-28 09:13:00 UTC
There is a typo in the first patch:
6380 	A
Comment 9 Bernardo Gonzalez Kriegel 2013-02-28 12:26:55 UTC Comment hidden (obsolete)
Comment 10 Bernardo Gonzalez Kriegel 2013-02-28 12:27:03 UTC Comment hidden (obsolete)
Comment 11 Bernardo Gonzalez Kriegel 2013-02-28 12:27:42 UTC
(In reply to comment #8)
> There is a typo in the first patch:
> 6380 	A

Ouch! My mistake. Fixed
Comment 12 Jonathan Druart 2013-02-28 13:03:55 UTC
QA comment:

(In reply to comment #10)
> Comment: Works as described. But the patch only hides the link,
> not disable the feature. If you refresh OPAC after unset
> EnhancedMessagingPreferencesOPAC, you can still change
> your messaging preferences.

For me this behevior is blocker. If you introduce a restriction for a page, you have to display an error message if the user try to access directly to this page.
The issue existed before your patch but it is the good time to do it (a simple test in the pl file and 3 lines in the template file should fix the issue).

Marked as Failed QA.
Comment 13 Sophie MEYNIEUX 2013-05-24 11:26:10 UTC
As described in Koha Manual, 

1.12.12. EnhancedMessagingPreferences

Default: Allow

Asks: ___ patrons to choose which notices they receive and when they receive them.

Values:

    Allow

    Don't allow

Important

This only applies to certain kinds of notices, overdue notices will be sent based on the library's rules, not the patron's choice.

So this syspref is defined to allow patrons to choose the notifications they want to receive. What Victor describes as a problem is not one.
Comment 14 Katrin Fischer 2013-06-16 06:56:19 UTC
I think if we got the page access fixed, this would be very close to go in from reading the comments.
Comment 15 Jonathan Druart 2013-08-14 14:22:02 UTC
A customer asked me the same request then I developed a patch and completely forgot this one.
So I will provide a followup with what I needed some months ago :)

But after a little reflexion, I don't know if it is relevant. I think it is not pleasant not to let the choice to the user.

Are you sure it is legal not to let the user deactivate notifications?

Switch to in discussion.
Comment 16 Jonathan Druart 2013-08-14 14:22:32 UTC Comment hidden (obsolete)
Comment 17 Katrin Fischer 2013-11-22 13:11:32 UTC
I am not sure if there is a legal requirement here, but if there is it might also differ from country to country. We already have some prefs/privacy critical features, that you can opt in to use or not.
I think as long as this is a switch, every library can decide what to do.

Resetting to 'Needs Signoff' - Jonathan, please set back to 'In Discussion' if you disagree.
Comment 18 Jonathan Druart 2013-11-22 13:27:40 UTC
I think the patron should, at least, be allow see the screen with read only rights.
Comment 19 Katrin Fischer 2013-11-22 13:33:36 UTC
Hm, the display as it currently is might be a bit confusing to patrons. 
Maybe we also need to think about how to "pretty" it up a bit.
Comment 20 Koha Team AMU 2013-11-29 12:14:34 UTC
We wanted to test this patch but it doesn't apply on a sandbox :

"Applying: Bug 9254: Problem with EnhancedMessagingPreferences\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merging C4/Auth.pm
Auto-merging installer/data/mysql/sysprefs.sql
CONFLICT (content): Merge conflict in installer/data/mysql/sysprefs.sql
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl\nFailed to merge in the changes.\nPatch failed at 0001 Bug 9254: Problem with EnhancedMessagingPreferences\nWhen you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".\nBug 9254 - Problem with EnhancedMessagingPreferences"
Comment 21 Mark Tompsett 2015-04-18 21:38:49 UTC Comment hidden (obsolete)
Comment 22 Mark Tompsett 2015-04-18 21:39:02 UTC Comment hidden (obsolete)
Comment 23 Mark Tompsett 2015-04-18 21:39:09 UTC Comment hidden (obsolete)
Comment 24 Mark Tompsett 2015-04-18 21:41:33 UTC
I set this to 'In Discussion', because it looked like Katrin Fischer and Jonathan Druart were discussing some raised issues in comment #17, comment #18, and comment #19.
Comment 25 Marc Véron 2015-04-22 19:28:29 UTC
There is a typo in koha-tmpl/opac-tmpl/bootstrap/en/includes/usermenu.inc line 81

Koha.Preferences('EnhancedMessagingPreferencesOPAC') 
should be:
Koha.Preference('EnhancedMessagingPreferencesOPAC') 

(Preferences -> Preference)

I tested after locally fixing the issue. IMO status 'In Discussion' could be removed.

Regarding comment #19: '...display as it currently is might be a bit confusing to patrons...':
Maybe there could be some explanation like in the tab 'your privacy'.
Comment 26 Mark Tompsett 2015-04-25 16:03:39 UTC Comment hidden (obsolete)
Comment 27 Mark Tompsett 2015-04-25 16:03:46 UTC Comment hidden (obsolete)
Comment 28 Mark Tompsett 2015-04-25 16:06:01 UTC
Created attachment 38515 [details] [review]
Bug 9254: Problem with EnhancedMessagingPreferences

First I don't know the right component to this bug.

The problem is the following:

- when enabling EnhancedMessagingPreferences, the staff client if able to set the messaging preferences for the patrons categories, and then for the patron (normally the messaging preferences are the same for everyone)
- when enabling EnhancedMessagingPreferences, the patrons can set in the OPAC their messaging preferences, which can be against the library rules

Solution:

- enabling EnhancedMessagingPreferences, should allow the the staff client to set the patrons messaging preferences
- enabling EnhancedMessagingPreferences, should't allow patrons to set their messaging preferences (the link doesn't appear in the usermenu.inc)
- should be another preference to allow the patrons to set their messaging preferences.

Test plan:

- apply the patch
- enable EnhancedMessagingPreferences, the messaging page should appear in OPAC
- disable OPACEnhancedMessagingPreferences, the messaging page shouldn't appear in OPAC
- disable EnhancedMessagingPreferences, the messaging page shouldn't appear in OPAC

Sponsored-by: KEEP SOLUTIONS

NOTE: Re-worked by Mark Tompsett, that's why I removed sign-offs.
Comment 29 Mark Tompsett 2015-04-25 16:06:08 UTC
Created attachment 38516 [details] [review]
Bug 9254: Followup - Rename pref to EnhancedMessagingPreferencesOPAC

If the new pref is named EnhancedMessagingPreferencesOPAC, it will show up adjacent to EnhancedMessagingPreferences

Comment: Works as described. But the patch only hides the link,
not disable the feature. If you refresh OPAC after unset
EnhancedMessagingPreferencesOPAC, you can still change
your messaging preferences.

NOTE: Mark Tompsett removed sign off, since he completely reworked it.
Comment 30 Mark Tompsett 2015-04-25 16:06:14 UTC
Created attachment 38517 [details] [review]
Bug 9254: redirect to 404 if at least 1 pref is off

And set the default value of EnhancedMessagingPreferencesOPAC = EnhancedMessagingPreferences
Comment 31 Mark Tompsett 2015-04-25 16:14:15 UTC
Leaving in discussion as per comments #17, #18, and #19. Which I raised in comment #24. Even though Marc V. suggested that 'In Discussion' was not required in his opinion in comment #25. These other attachments in between were because he pointed out a typo I believe I may have made in rescuing the patch.

Apply the latest and follow any test plans given in comments #28, #29, and #30.
Comment 32 Katrin Fischer 2015-05-24 22:46:03 UTC
(In reply to Jonathan Druart from comment #18)
> I think the patron should, at least, be allow see the screen with read only
> rights.

What about a third option to cover all bases? [Show|Don't show|allow editing of] messaging preferences in OPAC?
Comment 33 jvr 2015-05-29 10:39:51 UTC
Hello All,

I have been playing around with Koha since version 2.xx.

So, version 3.xx is better than 2.xx and this conversion (id=9254) started by Victor Fernandes 2012-12-10 15:18:28, 4 years ago, still with no solution because you don´t want to see the solution and we are all one tracked mind.

The solution is not to amend or the change the existing code (Koha's programmers don´t have time for that, please note, I am not a Koha programmer), but to understand want Koha already has in its framework that no one uses because no one sees it in front of their eyes...

I am talking about OPACUuserCSS property in Administration System Preferences.

CSS is there to change the aspect of your OPAC, so why not use it ?

Remember what your question is? Answer: You just want to hide something...

If you want to hide an hiperlink in OPAC that use CSS to hide it with a value="display: none", and it is just what all you are waiting for 4 years.

For example, to hide the message's hipelink use the following block code. 

#usermenu ul li a[href="/cgi-bin/koha/opac-messaging.pl"] {
  display: none;
}

Please open your minds for similar problems that can be resolved in the use of OPACUserCSS...

Thank you and please don't ask the community to change Koha coding when it is working well, doing that will create another problem that needs to be taken care later...

For more information goto https://bd2.fct.unl.pt/wiki_koha/#99-pt (sorry mainly in portuguese language)
Comment 34 jvr 2015-05-29 15:13:08 UTC
(In reply to Katrin Fischer from comment #32)
> (In reply to Jonathan Druart from comment #18)
> > I think the patron should, at least, be allow see the screen with read only
> > rights.
> 
> What about a third option to cover all bases? [Show|Don't show|allow editing
> of] messaging preferences in OPAC?


So, now we don´t want to hide the messaging hiperlink due to human rigth issues...

Hey. Stop for a minute and thing what is the meaning of "I think the patron should, at least, be allow the screen with only rigths."

ANSWER: It is just the same screen without the SUBMIT BUTTON.

WOW. 
Are you following me. 
Then just hide the SUBMIT BUTTON. 
How? 
ANSWER: OPACUserCSS

Has I explain in Comment 33 this is a similar situation and so to hide the BUTTON use the following block code.

#usermessaging form fieldset.action input.btn {
  display: none;
}

I hope this will help you and all other waiting for a solution...

To learn how to find the needed code and parameters please go to:

https://bd2.fct.unl.pt/wiki_koha/#100-pt

(sorry mainly in portuguese language)
Comment 35 Mark Tompsett 2015-05-29 15:33:48 UTC
(In reply to jvr from comment #34)
> So, now we don´t want to hide the messaging hiperlink due to human rigth
> issues...
> 
...
> Then just hide the SUBMIT BUTTON. 
> How? 
> ANSWER: OPACUserCSS

No, that doesn't work. There exists a user somewhere, that knows how to unhide the things your CSS hides. It needs to physically not be there. CSS is great for situations which don't have further implications if someone decides to forcefully make it visible again or read page source.

Plus by serving the page with the information required to shoot yourself legally, you have most likely violated some legal situation you are trying to avoid.
Comment 36 Katrin Fischer 2015-05-31 13:12:01 UTC
I agree with Mark that CSS is not the ultimate answer here, as people can get around it. I am also not sure that the messaging settings absolutely need to be displayed, as long as the user has actively agreed that the library can email him/her in the first place. 

Going to repeat myself... 3 option pref? Anyone a better idea? :)
> [Show|Don't show|allow editing of]
Comment 37 Marc Véron 2015-06-01 06:43:21 UTC
3 option pref ++
Comment 38 jvr 2015-06-01 09:27:05 UTC
I also agree that 3 option pref is bettter than what we have now (2 or nothing), but it isn't what our staff wants. 

We are an university library and every year thousand of new users that commit the same error, they click of everything and change settings they had no intention. 

So, the lesson to learn, this option (messaging) should not be as is, but be instead a submit form for moderation by the staff before the new settings become permanent. 

Please, understand that because of the fines, the library staff have a lot of extra complains to deal with and all that burocratic work in explaning to the first time users what they did wrong.
Comment 39 Katrin Fischer 2015-07-09 02:19:00 UTC
I am not sure moderation is the right answer here. What will you do if you don't agree with the settings the user has changed? Will you contact them by email to tell them why their choice wasn't good or just deny the change without any explanation? Moderation is great for a lot of things, but I think for switches like that, it wouldn't work really well.

Another suggestion would be to only allow changing settings for some, but not all notices/messages. But I feel like this should be separate from this bug and would be another enhancement.
Comment 40 MAP 2016-03-03 09:50:53 UTC
Dear,

When this patch will available on the version?

Praseeth MA
MAP Innovative Technologies
India, Kerala, Palakkad
Comment 41 Katrin Fischer 2016-03-07 22:24:24 UTC
Can we get this unstuck somehow?
Comment 42 Katrin Fischer 2016-03-07 22:29:51 UTC
Added this bug to the next developer meeting agenda: https://wiki.koha-community.org/wiki/Development_IRC_meeting_22_March
Comment 43 Katrin Fischer 2016-09-26 04:41:04 UTC
It looks like we were still stuck here, bug 12528 and the EnhancedMessagingPreferencesOPAC system preference made it in.

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