When you do a bulk patron import you can choose a privacy setting for your patrons, but when you create a new patron you can't. Many libraries want the default to be 'Never' and have the patrons opt in - while others want the patrons to choose to opt-out instead. Given this librarians should be able to set the default per patron or patron category and then never be allowed to edit that once it's set (in order to let the patron have control over the preference).
Also, patron import shouldn't be allowed to change the privacy setting on existing patrons .. only for new patrons.
The privacy setting is stored in borrowers.privacy which has a default of 1. A quick and dirty hack for a library that wanted 0 or 2 as the default could be to change the default of the column in MySQL. But I agree with Nicole, it would be nice to have a "proper" way to set the defualt to something else than 1, and very nice if a default could be set for each patron category.
*** Bug 4426 has been marked as a duplicate of this bug. ***
Created attachment 19131 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0
Created attachment 19132 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0
Created attachment 19133 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0
Here in Sweden we are generally forbidden to have reading history active. There are certain categories of borrowers however (those reading DAISY for example) that are dependent on reading history being enabled. Therefore it would be highly useful to have Koha allow setting the default privacy per patron category. Imported users should get the default privacy setting if nothing else is specified.
Created attachment 19272 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0 Signed-off-by: Liz Rea <wizzyrea@gmail.com> Tested per plan, all looks ok.
Created attachment 19631 [details] [review] [PASSED QA] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0 Signed-off-by: Liz Rea <wizzyrea@gmail.com> Tested per plan, all looks ok. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Passes all tests and QA script. Additional tests done: - Verified syspref.sql insert works alright - Checked editing patrons left privacy untouched. - Checked importing patrons with overlay leaves privacy alone if not provided.
Functionality wise this works and passes QA, but I am not so happy about the system preference description: NewPatronPrivacySetting: New patrons should have a privacy setting of default|never|forever I don't thinks this explains what this setting will do to a librarian trying to configure Koha and without deeper knowledge about the features and terminology. Also "Privacy" is a pretty broad term and this only affects how long we keep the reading history.
There are two separate requests in this bug to have the default be per-patron category. Kyle, are you amenable to redoing the patch to have the default privacy value be an attribute of patron category? Consider this part of my "sometimes a global YASP is not the right level of configurability" hobbyhorse. Setting to in discussion.
(In reply to Katrin Fischer from comment #10) > Functionality wise this works and passes QA, but I am not so happy about the > system preference description: > > NewPatronPrivacySetting: > New patrons should have a privacy setting of default|never|forever > > I don't thinks this explains what this setting will do to a librarian trying > to configure Koha and without deeper knowledge about the features and > terminology. Also "Privacy" is a pretty broad term and this only affects how > long we keep the reading history. I share Katrin's concerns about the description and feel that it could be expanded a bit. If we end up running with a syspref (but see my previous comment), I also think that DefaultPatronPrivacySetting would be a better name.
Created attachment 23309 [details] [review] [PASSED QA] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds the system preference NewPatronPrivacySetting to define what privacy setting new patrons should have. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a new patron 4) Verify the patron's privacy is set to 1 5) Set NewPatronPrivacySetting to "never" 6) Create a new patron 7) Verify the patron's privacy is set to 2 8) Set NewPatronPrivacySetting to "forever" 9) Create a new patron 10) Verify the patron's privacy is set to 0 Signed-off-by: Liz Rea <wizzyrea@gmail.com> Tested per plan, all looks ok. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Passes all tests and QA script. Additional tests done: - Verified syspref.sql insert works alright - Checked editing patrons left privacy untouched. - Checked importing patrons with overlay leaves privacy alone if not provided.
Created attachment 23310 [details] [review] Bug 6254 - can't set patron privacy by default - QA Followup
Created attachment 23317 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds a new field "default privacy" to the patron categories such that each patron category may have a different default privacy setting. Test Plan: 1) Apply this patch 2) Edit a patron category, change the default privacy to "forever" 3) Create a new patron of that category 4) Log into the catalog as that patron, verify the privacy setting is set to "forever" 5) Repeat steps 2-4 with the settings "never" and "default"
Created attachment 23516 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds a new field "default privacy" to the patron categories such that each patron category may have a different default privacy setting. Test Plan: 1) Apply this patch 2) Edit a patron category, change the default privacy to "forever" 3) Create a new patron of that category 4) Log into the catalog as that patron, verify the privacy setting is set to "forever" 5) Repeat steps 2-4 with the settings "never" and "default"
Patch tested with a sandbox, by Joel Sasse <jsasse@plumcreeklibrary.net>
Created attachment 23520 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds a new field "default privacy" to the patron categories such that each patron category may have a different default privacy setting. Test Plan: 1) Apply this patch 2) Edit a patron category, change the default privacy to "forever" 3) Create a new patron of that category 4) Log into the catalog as that patron, verify the privacy setting is set to "forever" 5) Repeat steps 2-4 with the settings "never" and "default" Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net>
Hi Kyle, ready to QA this, but I have a question about the default setting. In the templates I read: Controls how long a patrons checkout history is kept for new patrons of this category. "Default" lets the library decide, "Never" anonymizes checkouts on return, and "Forever" keeps a patron's checkout history indefinitely. Where and how does the library decide the meaning of "default"?
And a quick note so I don't forget: we should fix the "librairies" typo in categorie.tt :)
(In reply to Katrin Fischer from comment #19) > Where and how does the library decide the meaning of "default"? If i remember correctly, "default" means loans get anonymized as often as the library decides to run the anonymize cronjob: misc/cronjobs/batch_anonymise.pl The language here seems to be same that is used on the privacu settings page in the OPAC (for logged in users).
Some QA notes: - The new column is missing from the summary table - The new column is also missing from the summary on deleting a patron category - The database update could be improved by specifying where the new column will be added ('AFTER categorycode') - I think the note in the staff client could be a bit more specific and mention the cronjob, as it's directed at the librarians and not at the patrons. Kyle, could you provide a follow up?
Created attachment 23983 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default
Created attachment 23985 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default * Adds default privacy column to summary table * Adds default privacy to delete category summary * Adds "AFTER categorycode" to the database update * Whitespace cleanup and formatting for affected code blocks * Switch basic DBI queries to DBIx::Class to simplify code
Created attachment 23986 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default * Adds default privacy column to summary table * Adds default privacy to delete category summary * Adds "AFTER categorycode" to the database update * Whitespace cleanup and formatting for affected code blocks * Switch basic DBI queries to DBIx::Class to simplify code * Adds reference to misc/cronjobs/batch_anonymise.pl to description
Created attachment 23987 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default * Adds default privacy column to summary table * Adds default privacy to delete category summary * Adds "AFTER categorycode" to the database update * Whitespace cleanup and formatting for affected code blocks * Switch basic DBI queries to DBIx::Class to simplify code * Adds reference to misc/cronjobs/batch_anonymise.pl to description
Comment on attachment 23987 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default Review of attachment 23987 [details] [review]: ----------------------------------------------------------------- Kyle, we are really almost there, but there is a translation problem: ::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/categorie.tt @@ +276,5 @@ > + <tr><th scope="row">Enrollment fee: </th><td>[% category.enrolmentfee | format('%.02f') %]</td></tr> > + <tr><th scope="row">Receives overdue notices: </th><td>[% IF ( category.overduenoticerequired ) %]Yes[% ELSE %]No[% END %]</td></tr> > + <tr><th scope="row">Lost items in staff client</th><td>[% IF ( category.hidelostitems ) %]Hidden by default[% ELSE %]Shown[% END %]</td></tr> > + <tr><th scope="row">Hold fee: </th><td>[% category.reservefee | format('%.02f') %]</td></tr> > + <tr><th scope="row">Default privacy: </th><td>[% category.default_privacy %]</td></tr> I think this should be a SWITCH making the never, forever and default translatable. The configuration page already does it correctly. @@ +404,5 @@ > No limitation > [% END %] > </td> > + <td> > + [% loo.default_privacy %] And here.
Created attachment 24606 [details] [review] Bug 6254 [QA Followup 2] - can't set patron privacy by default
Maybe should we hide the "default privacy" entry on the categorie.pl page (form add/edit and list) if OPACPrivacy is off?
All seems good to me. It would have been good to have several patches instead of one (for indentation and wording fixes). I still don't think it is a good idea to call Koha::Database in script file but it seems this idea does not win unanimous support. I will provide 1 patch with 2 small fixes. Marked as Passed QA.
(In reply to Jonathan Druart from comment #29) > Maybe should we hide the "default privacy" entry on the categorie.pl page > (form add/edit and list) if OPACPrivacy is off? I asked to Katrin on the IRC and she answered me: cait: I wonder if a library would want to clean the history for certain patron categories without the patron being able to choose how they do it cait: i mean they could use the cronjob with a special setting for some patron categories... even if you don't let the patrons choose their setting so if that would work... maybe it should always be visible Which is make sense.
Created attachment 24696 [details] [review] Bug 6254 - can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds a new field "default privacy" to the patron categories such that each patron category may have a different default privacy setting. Test Plan: 1) Apply this patch 2) Edit a patron category, change the default privacy to "forever" 3) Create a new patron of that category 4) Log into the catalog as that patron, verify the privacy setting is set to "forever" 5) Repeat steps 2-4 with the settings "never" and "default" Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 24697 [details] [review] Bug 6254 [QA Followup 1] - can't set patron privacy by default * Adds default privacy column to summary table * Adds default privacy to delete category summary * Adds "AFTER categorycode" to the database update * Whitespace cleanup and formatting for affected code blocks * Switch basic DBI queries to DBIx::Class to simplify code * Adds reference to misc/cronjobs/batch_anonymise.pl to description Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 24698 [details] [review] Bug 6254 [QA Followup 2] - can't set patron privacy by default Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 24699 [details] [review] Bug 6254: QA FIX: remove trailing whitespaces This patch removes trailing whitespaces/tab and fix the fields order in the updatedb entry (according to the kohastructure.pl). Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Patch does not apply. Reminder: please keep extensive whitespace changes onto separate patches.
Created attachment 28033 [details] [review] Bug 6254 [1] - Can't set patron privacy by default There is currently no way to set the privacy setting for newly created patrons. This patch adds a new field "default privacy" to the patron categories such that each patron category may have a different default privacy setting. Test Plan: 1) Apply this patch 2) Edit a patron category, change the default privacy to "forever" 3) Create a new patron of that category 4) Log into the catalog as that patron, verify the privacy setting is set to "forever" 5) Repeat steps 2-4 with the settings "never" and "default" Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Bug 6254 [QA Followup 1] - can't set patron privacy by default * Adds default privacy column to summary table * Adds default privacy to delete category summary * Adds "AFTER categorycode" to the database update * Whitespace cleanup and formatting for affected code blocks * Switch basic DBI queries to DBIx::Class to simplify code * Adds reference to misc/cronjobs/batch_anonymise.pl to description Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Bug 6254 [QA Followup 2] - can't set patron privacy by default Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Bug 6254: QA FIX: remove trailing whitespaces This patch removes trailing whitespaces/tab and fix the fields order in the updatedb entry (according to the kohastructure.pl). Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 28034 [details] [review] Bug 6254 [2] - Update Schema File
Created attachment 28035 [details] [review] Bug 6254 [3] - Tidy admin/categorie.pl ( whitespace changes only )
I've re-flowed these patches for simplicity and ease of updating: 1) Squashed all qa followups into main patch 2) Split schema file update into separate patch 3) Split whitespace cleanup into separate patch
Created attachment 28036 [details] [review] Bug 6254 [3] - Tidy admin/categorie.pl ( whitespace changes only )
I do believe this had passed qa. I've made no functional changes with my re-arrangement of the patch set, so back it goes! I did re-test and verify this patch set before uploading.
Pushed to master. Thanks, Kyle!