RFC - remove circ/transferstodo.pl prior to general release

[Galen Charlton]

Hi,

As noted in bug 2171
(http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2171), the
transfers to-do report is not working.  The intention of the report
seems to be:

* get a list of hold requests grouped by branches; specifically, those
that already have a specific item associated with them to fill the
request (i.e., reserves.priority = 0 and reserves.itemnumber is not
null) but have not been transferred yet (i.e., don't have a
branchtransfers record).

* let the operator initiate the transfer (this doesn't work at all at present)

However, by the time any given hold request has priority set to 0, a
branchtransfer has already been initiated.  In addition, the help for
the report implies that this is for potential transfers that are going
out other branches; however, the only time this report shows results
is when items are due into the current branch, thus duplicating the
functionality of circ/transferstoreceive.pl.

Is anybody using this report?  If so, can you explain what it is
supposed to do?  If not, I suggest that this be removed prior to the
general release.

By the way, there seems to be a need for a general report of items
that are in transit from one branch to another and which would catch
items that haven't arrived in a timely fashion.  In its current form,
circ/transferstodo.pl isn't it, but I think such a report should be
considered for 3.2.

Regards,

Galen
--
Galen Charlton
Koha Application Developer
LibLime
[hidden email]
p: 1-888-564-2457 x709
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha.org/mailman/listinfo/koha-devel

[Paul POULAIN-2]

Galen Charlton a écrit :

> Hi,
>
> As noted in bug 2171
> (http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2171), the
> transfers to-do report is not working.  The intention of the report
> seems to be:
>
> * get a list of hold requests grouped by branches; specifically, those
> that already have a specific item associated with them to fill the
> request (i.e., reserves.priority = 0 and reserves.itemnumber is not
> null) but have not been transferred yet (i.e., don't have a
> branchtransfers record).
>
> * let the operator initiate the transfer (this doesn't work at all at present)
>
> However, by the time any given hold request has priority set to 0, a
> branchtransfer has already been initiated.  In addition, the help for
> the report implies that this is for potential transfers that are going
> out other branches; however, the only time this report shows results
> is when items are due into the current branch, thus duplicating the
> functionality of circ/transferstoreceive.pl.
>
> Is anybody using this report?  If so, can you explain what it is
> supposed to do?  If not, I suggest that this be removed prior to the
> general release.

This is a SAN-OP dev. It's usefull for them. I cc: the dev who wrote
this report to have an answer on how it's supposed to work, how they use it.

cheers
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : [phone]
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha.org/mailman/listinfo/koha-devel

[Paul POULAIN-2]

Galen Charlton a écrit :

Hi Galen,

Here is the answer of SAN-OP about this question :
> Pour le fonctionement des reservations je te confirme que les programmes
> transfers to do et transferts to receive n'ont plus leur utilité initiale sur
> la V3. La reservation s'appuit maintenant sur le retour du document avec la
> préférence system ReserveNeedsTo Return. Par contre il serait interressant de
> concerver une liste permettant de visualiser les documents "bloqués" entre
> deux sites.

Translated, it means :
"I confirm transferstodo.pl & transfertorecieve.pl are no more used for
us. The reserve system now relies on document return, with the syspref
ReserveNeedsReturn. However, an interesting list could be the one that
let the librarian see documents "bloqued" (stopped somewhere) between 2
branches.

So, OK to remove them.

--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : [phone]
_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha.org/mailman/listinfo/koha-devel