[Koha-bugs] [Bug 11023] Toggle new status for items

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

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

--- Comment #37 from Jonathan Druart <jonathan.druart at biblibre.com> ---
(In reply to Katrin Fischer from comment #35)

Helle Katrin,

> Starting with some initial testing and notes on this:
>
> 1) I am not sure the 2 specialiced subroutines for getting the
>    columns from items and biblioitems are needed - couldn't this
>    be done in ToggleNewStatus with DBIC? Right now it seems like
>    the patch is using a mix of old and new (see comment 18 from Kyle).

There are 2 calls, 1 in C4::Items::ToggleNewStatus and 1 in the pl script.
I don't think it is a good idea to call DBIC directly in pl files.

> 2) The 'new' column
>    In comment 19 you said the goal of the cronjob was to remove the
>    new flag.
>    I am unsure if I see the use of the new field in the code and the
>    feature. To me it seems just like a new 'notes' field, that is not
>    really accessible without further configuration.

As I tried to explain in the commit message, this feature allows to manage new
items as you want.
There is no restriction or a "way todo". I listed test case examples, it is how
we use this field at BibLibre.
This patch is an "introduction" to the idea of manage a "new" status.

>    a) In order to be able to set the field, you need to add a Koha-2-
>       MARC-Mapping and change the bibliographic frameworks. Only then
>       you will be able to catalog it. The field won't be searchable
>       as there is no index on it. If we want to add an index later, this
>       will be difficult, as we can't tell which mappings people will
>       have used.
>       How will libraries learn about the existance of the new
>       column?

Reading the changelog?

>    b) For a general purpose field varchar(32) seems a bit limited.

In a lot of cases, we used it as a boolean, so it is enough. What do you
suggest, VARCHAR(64), TEXT,...?


>    c) It seems the feature is independend on the existance of the new
>       column. The central column for the feature seems to be the
>       existing dateaccessioned column instead.
>       With the implications of a) I am not sure we should include the
>       'new' from the beginning without having a clearer definition
>       on how to use it.

This field is important for the workflow of our users, it is part of the
feature.

> 4) Features in documentation
>    I think the documentation lists features more like in an ad, than
>    like in a help file.

Sorry, it was not the expected goal.


> It's not clear to the reader, how to achieve
>    the described functionality. That's what I have come up with:
>    
> +  <li>know easily what are the new items in the catalogue.</li>
>
>    This still requires SQL, so doesn't seem to depend on the feature.

It depends on the "new" field, so it depends on this feature, no?


> +  <li>display an icon in the search results for new items.</li>
>
>     The only way to do this I can come up with is limited to libraries
>     using biblio level itypes and by switching the itemtype with the
>     script.

Yes, it is one of the purpose of it.


> +  <li>configure issuing rules depending the 'new' status.</li>
>
>     I think this would also require switching the itemtype?

Yes.


> +  <li>get a RSS/Atom feeds on these new items.</li>
>
>     I think this would require using a special value in an item
>     column that is searchable with Zebra. So you can build a search in
>     Zebra that can then be used for the RSS feed?

I don't know how they do that, maybe using a sql query.


> 4) biblioitems
>
>    a) I am worried about some columns that should not be substituted:
>       biblionumber, itemnumber, barcode, totalissues, onloan ...
>       I think those are potentially dangerous and should not be listed.

It is a cronjob script, all of them should be used with full knowledge of the
facts.
I think it is easier/better to list all fields rather than to limit the
possibilities.

>    b) To me it seems like the only goal of including biblioitems is
>       the possibility to change the bibliotitems itemtype. As it is now,
>       it also allows changing values like title, pages, etc. which
>       borders on a record batch edit. To me this seems a bit misplaced
>       here.
>       Also, ToggleNewStatus seems to only do ModItem - but you can
>       define substitutions for biblioitems? (see also 6)

It seems only conditions on biblioitems have been tested, we don't use
biblioitems for substitutions. I will provide a patch to remove the biblioitems
fields in the substitution list.


> 5) GUI
>
>    a) It's not possible to edit a single rule. In order to add a rule
>       or edit a rule, you always have to use 'Edit' and then all rules
>       will display, the form for adding the new rule is at the very
>       bottom. It is not very comfortable.

What do you suggest? I tried to do something ergonomic with a quite complicated
form.
With the actual way, if you have to add several rules, it is useless to save
after adding each one, but only once at the end.
I chose to edit all rules on the same screen, because they are stored in a
syspref and I would prefer not to parse the pref to update the rules.

>    b) There are no mandatory fields, duration is optional, as are
>       conditions and substitions. So you can define an empty rule.

Yes, it could be possible if you want to mark all items as new.

I really want to avoid a long list of follow-ups.
I don't want to add all requests in this report. If some reports are opened and
linked to this one, and they are relevant, I will provide a patch.

Originally, this feature was something like
http://git.biblibre.com/?p=koha;a=blob;f=misc/cronjobs/toggle_new_status.pl;h=5acad013fac5bbbe22d17dab4369f99e28dd93e3;hb=8aa5f86906774da52bd317acef4131d9142c2431

We decided to submit something more flexible and more complete for the
community, in order to open the possibilities.

-- 
You are receiving this mail because:
You are watching all bug changes.