http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11023 --- Comment #37 from Jonathan Druart <jonathan.druart@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;... 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.