[Koha-bugs] [Bug 11023] Toggle new status for items
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Sun Apr 27 15:05:34 CEST 2014
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11023
Katrin Fischer <katrin.fischer at bsz-bw.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Signed Off |Failed QA
CC| |katrin.fischer at bsz-bw.de
--- Comment #35 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
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).
+sub columns {
+sub ToggleNewStatus {
+sub biblioitems_columns {
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.
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?
b) For a general purpose field varchar(32) seems a bit limited.
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.
4) Features in documentation
I think the documentation lists features more like in an ad, than
like in a help file. 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.
+ <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.
+ <li>configure issuing rules depending the 'new' status.</li>
I think this would also require switching the itemtype?
+ <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?
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.
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)
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.
b) There are no mandatory fields, duration is optional, as are
conditions and substitions. So you can define an empty rule.
c) In all other item related forms we use the names defined for the
columns in the default framework (at least that's where I think
those come from). But this feature only shows the names of the
database columns. I think this is because of 2 a)?
6) Exploding?
I defined a mean rule:
Duration: 1 (only 1 item in my database has an accessiondate from
yesterday)
Conditions: no condition
Substitutions:
biblioitems.publishercode = XXXX
biblioitems.url = something
biblioitems.itemtype = XXXX
items.barcode = xxxx
items.materials = xxxx
I didn't expect much to happen, but I had misinterpreted the duration.
Results:
DBD::mysql::st execute failed: Unknown column 'biblioitems.publishercode' in
'field list' at /home/katrin/kohaclone/C4/Items.pm line 2324.
ERROR in _koha_modify_item UPDATE items SET biblioitems.publishercode=? WHERE
itemnumber=?: Unknown column 'biblioitems.publishercode' in 'field list' at
/home/katrin/kohaclone/C4/Items.pm line 2327.
DBD::mysql::st execute failed: Unknown column 'biblioitems.url' in 'field list'
at /home/katrin/kohaclone/C4/Items.pm line 2324.
ERROR in _koha_modify_item UPDATE items SET biblioitems.url=? WHERE
itemnumber=?: Unknown column 'biblioitems.url' in 'field list' at
/home/katrin/kohaclone/C4/Items.pm line 2327.
DBD::mysql::st execute failed: Unknown column 'biblioitems.itemtype' in 'field
list' at /home/katrin/kohaclone/C4/Items.pm line 2324.
ERROR in _koha_modify_item UPDATE items SET biblioitems.itemtype=? WHERE
itemnumber=?: Unknown column 'biblioitems.itemtype' in 'field list' at
/home/katrin/kohaclone/C4/Items.pm line 2327.
DBD::mysql::st execute failed: Duplicate entry 'xxxx' for key 'itembarcodeidx'
at /home/katrin/kohaclone/C4/Items.pm line 2324.
ERROR in _koha_modify_item UPDATE items SET items.barcode=? WHERE itemnumber=?:
Duplicate entry 'xxxx' for key 'itembarcodeidx' at
/home/katrin/kohaclone/C4/Items.pm line 2327.
Of course, no all my items have xxxx in materials. I thought initially
only those items exactly 1 day old would be touched. But it will change
all items older than 1 day. So this potentially will update a lot of items
on each run.
The SQL also shows that you can't actually update biblioitems
columns, although the GUI offers the option.
--------
I really like the idea of this, but to me it seems like there is some
sort of mismatch between the feature description and how it seems to
work. It feels like it needs some more thought.
I think maybe this feature 'grew' since its initial specification?
An example for a mismatch is also the description of the cronjob:
+./toggle_new_status.pl -h
+
+Toggle recent acquisitions status.
+Use this script to delete "new" status for items.
There is no mention of the new column in the script.
Another problem I see is that the feature as it is now is potentially
quite dangerous and substitiutions on biblioitems don't work. Maybe
biblioitems should be removed altogether from this.
I'd love to hear some more opinions on this.
--
You are receiving this mail because:
You are watching all bug changes.
More information about the Koha-bugs
mailing list