http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14544
Marcel de Rooy <m.de.r...@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #171 from Marcel de Rooy <m.de.r...@rijksmuseum.nl> --- QA Comment: Great job !!! Lot of work involved. Still have some points for consideration: OPAC -- View contents of a list -- Send shelf - Crash Can't call method "can_be_viewed" on an undefined value at /home/koha/testclone/opac/opac-sendshelf.pl line 55. *BLOCKER* OPAC - View contents of a list - Sort by callnumber - Bang DBIx::Class::ResultSet::next(): Unknown column 'itemcallnumber' in 'order clause' at /home/koha/testclone/opac/opac-shelves.pl line 236 *BLOCKER* OPAC - Lists- Open a shared list where you do not have permission to remove items of someone else. Try to remove such an item. No success, but no warning too! IIRC There was a warning in the past about some items not deleted.. Now try to remove a item you added yourself to that list while having permission to remove your own entries. This does not work ! No items are deleted, no message. I am inclined to see this last point as a *BLOCKER* too. OPAC - View list - Delete your own item while the perms are ADD or DDD. Should not be possible. But the owner is able to now. This is change of behavior and not consistent with the wording of those permissions "Do not allow anyone to remove his own contributed entries" (including your own!). I would view it as a sort of Readonly list where you cannot accidentally delete your own items. (Note however that adding is still possible.) I am inclined to see this last point as a *BLOCKER* too (but I may not be completely neutral here :) + # FIXME + # This does not make sense, but it's has been backported from DelFromShelf. + # Why shouldn't we allow to remove his own contribution if allow_delete_other is on? Code Exceptions.pm module comes in now with a dependency Exception::Class. The description => "poeut" still needs some attention apparently :) Not sure what it means btw.. Although this looks good to me on itself, this dev should probably better have gone on its own report. Note there is another report too (13995). It kind of creeps in now. OPAC - Share a list - Enter email address - Return to your lists: This list does not exist ?? op=view && category=1. Adjust the URL? OPAC - I shared a list with AAD perms. The other user could add a few entries. After that removed the share. Now come back as owner of the list and try to remove one item of yourself and one of the other user. You will get the message: The item has been removed from the list. This is not completely true: You could only remove one item; the other is not permitted. OPAC - Create a new list - Starts with permissions D D D - Would it not be better to default to D A D ? Note that if I create a list with save to new list, it does default to DAD. So this is a minor inconsistency.. OPAC - View a list: For a list with ADD or DDD perms, the button Remove could be hidden or disabled? Might be the case now too btw. OPAC Detail - List(s) this item appears in: [nothing filled while expected] I click from view a (private) list on one entry. So go to opac detail. Should I expect that list to be mentioned now? It is not. Staff - View public lists [Related to another report] With the delete public lists permission I can delete the public list of another user. OK The staff user probably has a good reason to do so. Just noting that it would perhaps be more friendly to switch it to Private instead of a rigourous Delete? Code in opac-addbybiblionumber.pl: HandleSelectedShelf: Empty TODO in an else branch. Noting for the record. Code t/db_dependent/Utils/Datatables_Virtualshelves.t and C4/Utils/DataTables/VirtualShelves.pm This is only justified/used by svc/virtualshelves/search Isn't this the time to move this svc script to Koha::Virtualshelves too ? Or at least on another report ? Database design: Do we still need (or use) virtualshelfcontents.flags ? Could a dbrev remove it now? An observation (which could be considered as outside the scope): Add an item to the list with a barcode (in staff) is somewhat strange. You cannot add items, only biblios. This is current situation already. Just for completeness :) Moving the status to FQA now to reflect the need for some adjustments/clarifications. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/