This is a follow-up of report 18228 that simplifies the permissions for lists. It reapplies the idea of bug 10865, but with one difference: It does not completely hide all permissions if adding public or shared lists is not allowed; it only hides the Anyone-permission if it is not relevant. Note: The Anyone permission is not relevant if it is a private list that has no shares. Note that looking at the prefs OpacAllowPublicListCreation and/or OpacAllowSharingPrivateLists is not decisive. You should look at list permissions and shares in the database; turning off the Sharing pref does not automatically remove all shares in the system. It only blocks creating new shares.
Created attachment 64491 [details] [review] Bug 18834: Show "Anyone seeing this list" permission only for shared and public lists This is a follow-up of report 18228 that simplifies the permissions for lists. It reapplies the idea of bug 10865, but with one difference: It does not completely hide all permissions if adding public or shared lists is not allowed; it only hides the Anyone-permission if it is not relevant. Note: The Anyone permission is not relevant if it is a private list that has no shares. Note that looking at the prefs OpacAllowPublicListCreation and/or OpacAllowSharingPrivateLists is not decisive. You should look at list permissions and shares in the database; turning off the Sharing pref does not automatically remove all shares in the system. It only blocks creating new shares. We only need changes in opac-shelves.tt and virtualshelves/shelves.tt. Test plan: [1] Disable OpacAllowPublicListCreation and OpacAllowSharingPrivateLists. [2] Edit a public list in staff view. Toggle permissions, save and reopen to check the value you saved. Is Anyone permission included? [3] Edit a private list (without shares) in staff. Is Anyone excluded? [4] Edit the same private list in OPAC. Is Anyone excluded too? [5] Enable OpacAllowPublicListCreation. Create a public list in OPAC. [6] Edit this list in OPAC. Do you see Anyone? Save with Anyone. [7] Change category to Private. Save and reopen. Is Owner selected now, and Anyone excluded? [8] Enable sharing. Share a list and accept it with another user. [You can also manually insert a record in virtualshelfshares.] Edit the list in OPAC as owner. Do you see Anyone? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64492 [details] [review] Bug 18834: Add js to dynamically alter the permission options If we we move from Private to Public or vice versa, this actually has an impact on the permissions combo. If we go back to a private list without shares, we could remove Anyone. If we switch to public and the list had no shares, we could add Anyone. Handled in a js sub AdjustPerms, triggered by onchange of the category combo. Test plan: [1] Edit a private list without shares in OPAC. Toggle category. Check if the permissions combo changes accordingly. [2] Edit a public list in staff. Toggle category and check. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64493 [details] [review] Bug 18834: Remove js function Check from opac-shelves This function only serves to check if the shelf name is not empty. It does not even work since it incorrectly refers to f.addshelf (while it should test #shelfname). We can solve this and improve consistency by doing the same as in the staff template with html5 required. Test plan: [1] Without this patch it was possible to add a list without a name in OPAC (with js error: TypeError: f.addshelf is undefined). [2] With this patch, verify that you cannot do this anymore. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64510 [details] [review] Bug 18834: Show "Anyone seeing this list" permission only for shared and public lists This is a follow-up of report 18228 that simplifies the permissions for lists. It reapplies the idea of bug 10865, but with one difference: It does not completely hide all permissions if adding public or shared lists is not allowed; it only hides the Anyone-permission if it is not relevant. Note: The Anyone permission is not relevant if it is a private list that has no shares. Note that looking at the prefs OpacAllowPublicListCreation and/or OpacAllowSharingPrivateLists is not decisive. You should look at list permissions and shares in the database; turning off the Sharing pref does not automatically remove all shares in the system. It only blocks creating new shares. We only need changes in opac-shelves.tt and virtualshelves/shelves.tt. Test plan: [1] Disable OpacAllowPublicListCreation and OpacAllowSharingPrivateLists. [2] Edit a public list in staff view. Toggle permissions, save and reopen to check the value you saved. Is Anyone permission included? [3] Edit a private list (without shares) in staff. Is Anyone excluded? [4] Edit the same private list in OPAC. Is Anyone excluded too? [5] Enable OpacAllowPublicListCreation. Create a public list in OPAC. [6] Edit this list in OPAC. Do you see Anyone? Save with Anyone. [7] Change category to Private. Save and reopen. Is Owner selected now, and Anyone excluded? [8] Enable sharing. Share a list and accept it with another user. [You can also manually insert a record in virtualshelfshares.] Edit the list in OPAC as owner. Do you see Anyone?
Created attachment 64511 [details] [review] Bug 18834: Add js to dynamically alter the permission options If we we move from Private to Public or vice versa, this actually has an impact on the permissions combo. If we go back to a private list without shares, we could remove Anyone. If we switch to public and the list had no shares, we could add Anyone. Handled in a js sub AdjustPerms, triggered by onchange of the category combo. Test plan: [1] Edit a private list without shares in OPAC. Toggle category. Check if the permissions combo changes accordingly. [2] Edit a public list in staff. Toggle category and check.
Created attachment 64512 [details] [review] Bug 18834: Remove js function Check from opac-shelves This function only serves to check if the shelf name is not empty. It does not even work since it incorrectly refers to f.addshelf (while it should test #shelfname). We can solve this and improve consistency by doing the same as in the staff template with html5 required. Test plan: [1] Without this patch it was possible to add a list without a name in OPAC (with js error: TypeError: f.addshelf is undefined). [2] With this patch, verify that you cannot do this anymore.
Rebased (see 18214)
Created attachment 64520 [details] [review] Bug 18834: Show distinction between shared and private lists in staff Just as we show this distinction in OPAC, this patch adds a type column in the Your lists tab that displays Private or Shared. It always contains Public in the other tab. Test plan: [1] Check if you see Shared for a private lists with shares in staff. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64521 [details] [review] Bug 18834: Show "Anyone seeing this list" permission only for shared and public lists This is a follow-up of report 18228 that simplifies the permissions for lists. It reapplies the idea of bug 10865, but with one difference: It does not completely hide all permissions if adding public or shared lists is not allowed; it only hides the Anyone-permission if it is not relevant. Note: The Anyone permission is not relevant if it is a private list that has no shares. Note that looking at the prefs OpacAllowPublicListCreation and/or OpacAllowSharingPrivateLists is not decisive. You should look at list permissions and shares in the database; turning off the Sharing pref does not automatically remove all shares in the system. It only blocks creating new shares. We only need changes in opac-shelves.tt and virtualshelves/shelves.tt. Test plan: [1] Disable OpacAllowPublicListCreation and OpacAllowSharingPrivateLists. [2] Edit a public list in staff view. Toggle permissions, save and reopen to check the value you saved. Is Anyone permission included? [3] Edit a private list (without shares) in staff. Is Anyone excluded? [4] Edit the same private list in OPAC. Is Anyone excluded too? [5] Enable OpacAllowPublicListCreation. Create a public list in OPAC. [6] Edit this list in OPAC. Do you see Anyone? Save with Anyone. [7] Change category to Private. Save and reopen. Is Owner selected now, and Anyone excluded? [8] Enable sharing. Share a list and accept it with another user. [You can also manually insert a record in virtualshelfshares.] Edit the list in OPAC as owner. Do you see Anyone? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64522 [details] [review] Bug 18834: Add js to dynamically alter the permission options If we we move from Private to Public or vice versa, this actually has an impact on the permissions combo. If we go back to a private list without shares, we could remove Anyone. If we switch to public and the list had no shares, we could add Anyone. Handled in a js sub AdjustPerms, triggered by onchange of the category combo. Test plan: [1] Edit a private list without shares in OPAC. Toggle category. Check if the permissions combo changes accordingly. [2] Edit a public list in staff. Toggle category and check. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64523 [details] [review] Bug 18834: Remove js function Check from opac-shelves This function only serves to check if the shelf name is not empty. It does not even work since it incorrectly refers to f.addshelf (while it should test #shelfname). We can solve this and improve consistency by doing the same as in the staff template with html5 required. Test plan: [1] Without this patch it was possible to add a list without a name in OPAC (with js error: TypeError: f.addshelf is undefined). [2] With this patch, verify that you cannot do this anymore. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64524 [details] [review] Bug 18834: Show distinction between shared and private lists in staff Just as we show this distinction in OPAC, this patch adds a type column in the Your lists tab that displays Private or Shared. It always contains Public in the other tab. Test plan: [1] Check if you see Shared for a private lists with shares in staff. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64525 [details] [review] Bug 18834: Show distinction between shared and private lists in staff Just as we show this distinction in OPAC, this patch adds a type column in the Your lists tab that displays Private or Shared. It always contains Public in the other tab. Test plan: [1] Check if you see Shared for a private lists with shares in staff. [2] Run t/db_dependent/Utils/Datatables_Virtualshelves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 64545 [details] [review] Bug 18834: Show "Anyone seeing this list" permission only for shared and public lists This is a follow-up of report 18228 that simplifies the permissions for lists. It reapplies the idea of bug 10865, but with one difference: It does not completely hide all permissions if adding public or shared lists is not allowed; it only hides the Anyone-permission if it is not relevant. Note: The Anyone permission is not relevant if it is a private list that has no shares. Note that looking at the prefs OpacAllowPublicListCreation and/or OpacAllowSharingPrivateLists is not decisive. You should look at list permissions and shares in the database; turning off the Sharing pref does not automatically remove all shares in the system. It only blocks creating new shares. We only need changes in opac-shelves.tt and virtualshelves/shelves.tt. Test plan: [1] Disable OpacAllowPublicListCreation and OpacAllowSharingPrivateLists. [2] Edit a public list in staff view. Toggle permissions, save and reopen to check the value you saved. Is Anyone permission included? [3] Edit a private list (without shares) in staff. Is Anyone excluded? [4] Edit the same private list in OPAC. Is Anyone excluded too? [5] Enable OpacAllowPublicListCreation. Create a public list in OPAC. [6] Edit this list in OPAC. Do you see Anyone? Save with Anyone. [7] Change category to Private. Save and reopen. Is Owner selected now, and Anyone excluded? [8] Enable sharing. Share a list and accept it with another user. [You can also manually insert a record in virtualshelfshares.] Edit the list in OPAC as owner. Do you see Anyone? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lee Jamison <ldjamison@marywood.edu> Works as directed in the test plan. updatedatabase.pl must be run in order for Datatables_Virtualshelves.t to pass
Created attachment 64546 [details] [review] Bug 18834: Add js to dynamically alter the permission options If we we move from Private to Public or vice versa, this actually has an impact on the permissions combo. If we go back to a private list without shares, we could remove Anyone. If we switch to public and the list had no shares, we could add Anyone. Handled in a js sub AdjustPerms, triggered by onchange of the category combo. Test plan: [1] Edit a private list without shares in OPAC. Toggle category. Check if the permissions combo changes accordingly. [2] Edit a public list in staff. Toggle category and check. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Created attachment 64547 [details] [review] Bug 18834: Remove js function Check from opac-shelves This function only serves to check if the shelf name is not empty. It does not even work since it incorrectly refers to f.addshelf (while it should test #shelfname). We can solve this and improve consistency by doing the same as in the staff template with html5 required. Test plan: [1] Without this patch it was possible to add a list without a name in OPAC (with js error: TypeError: f.addshelf is undefined). [2] With this patch, verify that you cannot do this anymore. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Created attachment 64548 [details] [review] Bug 18834: Show distinction between shared and private lists in staff Just as we show this distinction in OPAC, this patch adds a type column in the Your lists tab that displays Private or Shared. It always contains Public in the other tab. Test plan: [1] Check if you see Shared for a private lists with shares in staff. [2] Run t/db_dependent/Utils/Datatables_Virtualshelves.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
(In reply to Lee Jamison from comment #17) > Signed-off-by: Lee Jamison <ldjamison@marywood.edu> Great! Thanks, Lee.
Marcel, I do not think we should hide "Anyone seeing this list" for private lists. First, you are not allowed to select it before sharing it. That can be a bit annoying if you know you are going to share it after you created it. Then imagine the following workflow: - Create a private list - Share it - Edit the list to let your friend adding items to this list - Remove the share => When you edit the list you do not see the correct value, "Anyone seeing this list" is not displayed whereas it is the value of the field.
(In reply to Jonathan Druart from comment #19) > Marcel, I do not think we should hide "Anyone seeing this list" for private > lists. > > First, you are not allowed to select it before sharing it. That can be a bit > annoying if you know you are going to share it after you created it. > > Then imagine the following workflow: > - Create a private list > - Share it > - Edit the list to let your friend adding items to this list > - Remove the share > => When you edit the list you do not see the correct value, "Anyone seeing > this list" is not displayed whereas it is the value of the field. I added it because users apparently get confused from options that are not relevant. See bug 10865 in the past. We could choose another approach too: [1] Tell the user that no one else sees the list (when this applies). [2] Replace Anyone by Owner when we delete the last share. This does not resolve your first remark. Any feedback ?
I would let the option anyway and add a note if it does not apply currently.
(In reply to Jonathan Druart from comment #21) > I would let the option anyway and add a note if it does not apply currently. Will put this approach under report 18980
Bug 18980 has been pushed. This bug can be closed.