[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

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.