[Koha-bugs] [Bug 14544] Move the list related code to Koha::Virtualshelves

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14544

Marcel de Rooy <m.de.rooy at rijksmuseum.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |Failed QA

--- Comment #171 from Marcel de Rooy <m.de.rooy at 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.