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.
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
Created attachment 14199 [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
Created attachment 14244 [details] [review] [SIGNED-OFF] 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 Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 14246 [details] [review] Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC If the new pref is named EnhancedMessagingPreferencesOPAC, it will show up adjacent to EnhancedMessagingPreferences
Last patch needs a signoff.
Created attachment 15010 [details] [review] [SIGNED-OFF] 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 Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Rebased on master (2013-02-01)
Created attachment 15011 [details] [review] [SIGNED-OFF] Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC If the new pref is named EnhancedMessagingPreferencesOPAC, it will show up adjacent to EnhancedMessagingPreferences Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> 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.
There is a typo in the first patch: 6380 A
Created attachment 15764 [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 Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Rebased on master (2013-02-01)
Created attachment 15765 [details] [review] Bug 9254 - Problem with EnhancedMessagingPreferences - Followup - Rename pref to EnhancedMessagingPreferencesOPAC If the new pref is named EnhancedMessagingPreferencesOPAC, it will show up adjacent to EnhancedMessagingPreferences Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> 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.
(In reply to comment #8) > There is a typo in the first patch: > 6380 A Ouch! My mistake. Fixed
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.
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.
I think if we got the page access fixed, this would be very close to go in from reading the comments.
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.
Created attachment 20332 [details] [review] Bug 9254: redirect to 404 if at least 1 pref is off And set the value of EnhancedMessagingPreferencesOPAC = EnhancedMessagingPreferences
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.
I think the patron should, at least, be allow see the screen with read only rights.
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.
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"
Created attachment 38122 [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.
Created attachment 38123 [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.
Created attachment 38124 [details] [review] Bug 9254: redirect to 404 if at least 1 pref is off And set the default value of EnhancedMessagingPreferencesOPAC = EnhancedMessagingPreferences
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.
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'.
Created attachment 38513 [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.
Created attachment 38514 [details] [review] Bug 9254: redirect to 404 if at least 1 pref is off And set the default value of EnhancedMessagingPreferencesOPAC = EnhancedMessagingPreferences
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.
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.
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
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.
(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?
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)
(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)
(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.
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]
3 option pref ++
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.
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.
Dear, When this patch will available on the version? Praseeth MA MAP Innovative Technologies India, Kerala, Palakkad
Can we get this unstuck somehow?
Added this bug to the next developer meeting agenda: https://wiki.koha-community.org/wiki/Development_IRC_meeting_22_March
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 ***