Improving permissions on lists (virtual shelves)
Hi all, Still hoping to get some feedback on this subject, I would now propose the following. Please respond to the list, if you agree or disagree. 1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client. 2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added. This makes the distinction between public list and open list no longer needed and adds some refinement in lists management. Only the owner of the list can change these permissions. 3 Add a new (opac) feature to private lists: Share a list (with another patron). Let the user share access to a list by Koha sending an email with a URL including some (temporary) invitation key. When the invited patron clicks that URL (when logged in) he gains access (in accordance with the described permission options for that specific list). The invited patron can always 'delete' the shared list, i.e. delete the share. The owner can 'unshare' the list and remove all shares for that list. 4 With respect to user privacy, a feature may be added in staff client to moderate shared list names. 5 Possibly, libraries do not want patrons sharing lists. So the option could be disabled with a preference. In that case points 2 and 3 still apply. Note that the shared private list concept makes report 7281 (Hiding some lists) obsolete. Bug 7310 will be used for this feature. Your comments are very welcome! Marcel
Kia ora!
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.
I'm still struggling with this. While I realise that some Patrons who shall remain nameless and spammers might create stuff we don't want floating round the OPAC, some of the best bibliographies are created by Patrons, not Staff. I feel like at the bare minimum, there needs be a way for a Patron to send their list to Staff to be made public. I like just giving them the ability to make lists public better, though. Cheers, Brooke
Thanks, Brooke. We could/should make it possible to upgrade a private list to a public list in staff client. Do you have an idea where the user in opac could do such a request to staff? Just an email or something else? Or: Share it with staff?
-----Oorspronkelijk bericht----- Van: BWS Johnson [mailto:abesottedphoenix@yahoo.com] Verzonden: maandag 5 december 2011 12:01 Aan: Marcel de Rooy; koha Onderwerp: Re: [Koha] Improving permissions on lists (virtual shelves)
Kia ora!
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.
I'm still struggling with this. While I realise that some Patrons who shall remain nameless and spammers might create stuff we don't want floating round the OPAC, some of the best bibliographies are created by Patrons, not Staff. I feel like at the bare minimum, there needs be a way for a Patron to send their list to Staff to be made public. I like just giving them the ability to make lists public better, though.
Cheers, Brooke
BWS Johnson schreef op ma 05-12-2011 om 03:00 [-0800]:
I'm still struggling with this. While I realise that some Patrons who shall remain nameless and spammers might create stuff we don't want floating round the OPAC, some of the best bibliographies are created by Patrons, not Staff. I feel like at the bare minimum, there needs be a way for a Patron to send their list to Staff to be made public. I like just giving them the ability to make lists public better, though.
Yeah, I'm not a fan of universally preventing the public from creating lists. It makes sense in a lot of situations, however for e.g. company libraries, it's able to be quite useful if staff can build lists for a topic. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Hi to all, Il 05/12/2011 11:42, Marcel de Rooy ha scritto:
Still hoping to get some feedback on this subject, I would now propose the following. Please respond to the list, if you agree or disagree.
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client. 2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added. This makes the distinction between public list and open list no longer needed and adds some refinement in lists management. Only the owner of the list can change these permissions. 3 Add a new (opac) feature to private lists: Share a list (with another patron). Let the user share access to a list by Koha sending an email with a URL including some (temporary) invitation key. When the invited patron clicks that URL (when logged in) he gains access (in accordance with the described permission options for that specific list). The invited patron can always 'delete' the shared list, i.e. delete the share. The owner can 'unshare' the list and remove all shares for that list. 4 With respect to user privacy, a feature may be added in staff client to moderate shared list names. 5 Possibly, libraries do not want patrons sharing lists. So the option could be disabled with a preference. In that case points 2 and 3 still apply.
Note that the shared private list concept makes report 7281 (Hiding some lists) obsolete. Bug 7310 will be used for this feature.
I think that this RFC is a good develop about virtual shelves. Total OK on point 1. In my opinion i prefer not to use 'sharing lists' so for me point 5 is quite important. I don't understand very well why point 4. Cheers Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer
Point 4: An option like Moderate patron comments just to modify shared list names that would be inappropriate, insulting, etc. (since the list name is no longer private but visible to other users/patrons).
-----Oorspronkelijk bericht----- Van: Zeno Tajoli [mailto:tajoli@cilea.it] Verzonden: maandag 5 december 2011 12:05 Aan: Marcel de Rooy CC: koha Onderwerp: Re: [Koha] Improving permissions on lists (virtual shelves)
Hi to all,
Il 05/12/2011 11:42, Marcel de Rooy ha scritto:
Still hoping to get some feedback on this subject, I would now propose the following. Please respond to the list, if you agree or disagree.
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client. 2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added. This makes the distinction between public list and open list no longer needed and adds some refinement in lists management. Only the owner of the list can change these permissions. 3 Add a new (opac) feature to private lists: Share a list (with another patron). Let the user share access to a list by Koha sending an email with a URL including some (temporary) invitation key. When the invited patron clicks that URL (when logged in) he gains access (in accordance with the described permission options for that specific list). The invited patron can always 'delete' the shared list, i.e. delete the share. The owner can 'unshare' the list and remove all shares for that list. 4 With respect to user privacy, a feature may be added in staff client to moderate shared list names. 5 Possibly, libraries do not want patrons sharing lists. So the option could be disabled with a preference. In that case points 2 and 3 still apply.
Note that the shared private list concept makes report 7281 (Hiding some lists) obsolete. Bug 7310 will be used for this feature.
I think that this RFC is a good develop about virtual shelves. Total OK on point 1. In my opinion i prefer not to use 'sharing lists' so for me point 5 is quite important. I don't understand very well why point 4.
Cheers Zeno Tajoli
-- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer
Comments in line below: On Mon, Dec 5, 2011 at 5:42 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
Hi all,
Still hoping to get some feedback on this subject, I would now propose the following. Please respond to the list, if you agree or disagree.
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.
I think this should be a preference that the librarians can choose from the following options : 1. Allow anyone to create public lists without moderation 2. Allow patrons to create public lists with moderation 3. Allow only staff (with permission) to create public lists
2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added. This makes the distinction between public list and open list no longer needed and adds some refinement in lists management. Only the owner of the list can change these permissions.
In addition I'd say we need general staff list permissions which we don't have right now.
3 Add a new (opac) feature to private lists: Share a list (with another patron). Let the user share access to a list by Koha sending an email with a URL including some (temporary) invitation key. When the invited patron clicks that URL (when logged in) he gains access (in accordance with the described permission options for that specific list). The invited patron can always 'delete' the shared list, i.e. delete the share. The owner can 'unshare' the list and remove all shares for that list.
I like!
4 With respect to user privacy, a feature may be added in staff client to moderate shared list names.
Right now patron names don't show on lists at all - not sure if we need them really.
5 Possibly, libraries do not want patrons sharing lists. So the option could be disabled with a preference. In that case points 2 and 3 still apply.
Yes, preferences to turn things off are always good.
Note that the shared private list concept makes report 7281 (Hiding some lists) obsolete. Bug 7310 will be used for this feature.
Your comments are very welcome!
Marcel
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
4 With respect to user privacy, a feature may be added in staff client to moderate shared list names. Right now patron names don't show on lists at all - not sure if we need them really. I do not mean patron names, but the list name itself could be problematic and needing moderation. Thanks for your comments.
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client. I think this should be a preference that the librarians can choose from the following options : 1. Allow anyone to create public lists without moderation 2. Allow patrons to create public lists with moderation 3. Allow only staff (with permission) to create public lists Brooke came up with an idea where the patron asks staff to upgrade a private list to a public list or so..
On Mon, Dec 5, 2011 at 8:19 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
** **
** **
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.****
I think this should be a preference that the librarians can choose from the following options :
1. Allow anyone to create public lists without moderation 2. Allow patrons to create public lists with moderation 3. Allow only staff (with permission) to create public lists ****
Brooke came up with an idea where the patron asks staff to upgrade a private list to a public list or so..
That would be the same as my 'moderation' request - except that the staff get to choose whether they moderate lists at all. It's more work for the staff, so they should have a say in the matter. Like with the patron submitting edits to their account - librarians can turn this option off if it's too much work for them (or if they have other reasons). Nicole
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.
If it were just me I would agree with this. However I think Nicole's suggestion for options here is a more robust solution.
2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added.
I think this is a good idea. I think it presents a challenge when it comes to explaining the options to the patron.
3 Add a new (opac) feature to private lists: Share a list (with another patron).
This is a nice idea, but I would prioritize it lower than the other features.
4 With respect to user privacy, a feature may be added in staff client to moderate shared list names.
Do we propose to moderate the names of lists which users want to make public, or lists which users want to share with others (option 3)? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
4 With respect to user privacy, a feature may be added in staff client to moderate shared list names.
Do we propose to moderate the names of lists which users want to make public, or lists which users want to share with others (option 3)?
Thanks. My idea is: Do not moderate private list names, but optionally do so for shared private and public lists (visible for >1 patrons).
On 6 December 2011 02:52, Owen Leonard <oleonard@myacpl.org> wrote:
1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client.
If it were just me I would agree with this. However I think Nicole's suggestion for options here is a more robust solution.
I have to agree strongly with Nicole, this needs to be a system preference. We have to remember Koha is used by all types of libraries including specials and corporates. In a lot of corporate libraries the OPAC is only accessible on their intranet, and public lists are used by people working in teams to create bibliographies. We would be removing a well utilised feature if we simply turned this off. So having a preference that would allow them to continue to function in the way they already do, or be moderated, or simply be disallowed is the best solution. Chris
participants (7)
-
BWS Johnson -
Chris Cormack -
Marcel de Rooy -
Nicole Engard -
Owen Leonard -
Robin Sheat -
Zeno Tajoli