Bug 7997 - Can't create a notice with the same code
Summary: Can't create a notice with the same code
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
: 11931 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-23 18:55 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-04-23 18:55:46 UTC
When creating a new notice you can use a code that's in use already and when you save you overwrite the original notice. There is no warning there or block to stop you from doing this.

If this is the intended behavior then we need a warning that says saving this will overwrite the original notice with this code - or we need a way to prevent creation of notices with the same code.

Nicole
Comment 1 Marc Véron 2012-04-25 22:18:35 UTC
I tried t reproduce the behaviour with Version 3.08.00.000



I tested with following steps:

- Create 1st notice with code DOUBLETEST, insert some text, save
- Create 2nd notice, use same code DOUBLETEST, insert other text, save

In my case, the 2nd notice was silently discarded, the 1st notice was unchanged.
This is consistent with the database:

mysql> describe letter;
+------------+--------------+------+-----+---------+-------+
| Field      | Type         | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+-------+
| module     | varchar(20)  | NO   | PRI |         |       |
| code       | varchar(20)  | NO   | PRI |         |       |
| branchcode | varchar(10)  | NO   | PRI |         |       |
| name       | varchar(100) | NO   |     |         |       |
| is_html    | tinyint(1)   | YES  |     | 0       |       |
| title      | varchar(200) | NO   |     |         |       |
| content    | text         | YES  |     | NULL    |       |
+------------+--------------+------+-----+---------+-------+

To prevent frustrations, it would really be nice to have
- at least a warning that the 2nd notice was not saved (and why)
- or better have a mechanisme to pre-test or warn before saving (and go back to the form).

Marc
Comment 2 Nicole C. Engard 2012-04-26 16:16:38 UTC
I tested on 3.8 by adding a new notice with ODUE as the code and the default ODUE notice was overwritten ...
Comment 3 Marc Véron 2012-04-26 19:19:44 UTC
It seems to behave arbitrary.

Testing:
--------
I have:
(All libraries) 	circulation 	ODUE 	Mahnung 11

I make a copy of ODUE for 'Centerville'. 
I give it the the values
Centerville 	circulation 	ODUE 	Mahnung 11

Then Dropdown "Select a library"->Centerville.

Then I create a "New Notice" with the values:
Centerville 	circulation 	ODUE 	Mahnung 12
-> Both ODUE for '(All Libraries)' and for 'Centerville' are unchanged.

Now I go back to the List "Centerville"
I do "Copy" to Centerville and give the value 
Centerville 	circulation 	ODUE 	Copy from Centerville to Centreville
-> Now the slip for 'Centerville' is silently overwritten.

I choose "All libraries"
Do  "New Notice" with
(All libraries) 	circulation 	ODUE 	Mahnung 13
...and ODUE for All Libraries is silently ovewritten

I do "New Notice" with values
Centerville 	circulation 	ODUE 	Mahnung 13

Centerville circulation is still
Centerville 	circulation 	ODUE 	Copy from Centerville to Centreville

Fazit: 
------
Sometimes it overwrites silently and sometimes it discards silently.


Additional glitch:
------------------
With the form "Add Notice" I had the following strange behavior:
- Select Dropdown "Centerville"
- Do "New Notice"
Form displays:
Library: Centerville
Koha module: Catalog

-Now click in "Koha module" and choose "Circulation". Entry changes to "Circulation".
- Now click in field "Code" and then on field "Name"

Result: Entry of "Library" switches from "Centerville" to "All libraries" (!)
(If you then change it to "Centerfield" again, it seems to be stable, the switch seems to be related to a newly opened form).

If you are not aware that the value for "Libray" has changed and save, the Entry of "All libraries" is silently overwritten (as expected from behaviour above).

Marc
Comment 4 Nicole C. Engard 2012-04-26 19:42:32 UTC
I think the solution is that regardless of branch the notice/slip code must be unique. That will prevent this kind of problem in all cases ... won't it?
Comment 5 Marc Véron 2012-04-26 19:50:16 UTC
Agree...
Comment 6 Katrin Fischer 2012-04-26 20:03:38 UTC
I think that's not so easy to do as some letter codes are hardcoded. 
A combined primary key of branch and letter code might be easier here with proper checks in the template?
Comment 7 Nicole C. Engard 2012-04-26 20:17:42 UTC
Well I'd think that codes shouldn't be hardcoded ... instead a primary key should be used. But I'm up for anything that prevents this kind of thing from happening.

Nicole
Comment 8 Katrin Fischer 2012-04-26 20:19:50 UTC
I did think that too a while back, but how would the system know which letter to use for a specific action? It would require something like a unique module for each... a module for holds, module for suggestions accepted... etc. I really think it's more a problem of how the form works here and that we need to check and warn.
Comment 9 Chris Cormack 2012-04-26 20:23:20 UTC
I agree, the form should check and warn, leaving it up to the db to catch the error, is the wrong solution
Comment 10 Nicole C. Engard 2012-04-26 20:29:50 UTC
Oh I agree with that 100% - the form should warn and check - but the DB should also have unique values that it uses.  

This would be another issue, but maybe a triggers type tool for all notices instead of just the overdues - that way the codes don't need to be hardcoded anymore.

Nicole
Comment 11 Nicole C. Engard 2012-07-03 19:04:15 UTC
Just want to nudge this - this is still happening in 3.8.2 - the notices are silently being deleted/failing to be added. This is pretty annoying. Any ideas on how to fix this?
Comment 12 Nicole C. Engard 2012-07-05 14:10:54 UTC
The way I understand it, the way things are now you can't have different notices for different branches ... this is a critical issue.  Either the ability to create notices for different branches needs to be removed or the code fixed to look at the code/branch combo as a key, or make each notice have a unique key.
Comment 13 Marc Véron 2014-04-13 10:18:18 UTC
Still valid with 3.15.00.028
Comment 14 Katrin Fischer 2014-07-12 11:48:51 UTC
*** Bug 11931 has been marked as a duplicate of this bug. ***
Comment 15 Katrin Fischer 2014-11-03 22:43:57 UTC
Updating the bug description a bit:

The problem now is that we DON'T allow for duplicate letter codes and a check has been added in the template (bug 11742).

But I think we forgot about the existence of the hardcoded letter codes - some of those are:

- ACCTDETAULS
- HOLD
- Slip templates...

So... I think we need to find a way to allow duplicates?
Comment 16 Katrin Fischer 2014-11-06 07:25:00 UTC
I think this needs to be fixed prior to release - sorry for missing the problem in testing earlier :(
Comment 17 Katrin Fischer 2015-02-22 09:44:40 UTC
The problem has been fixed with bug 13215.