Bug 7303 - Not being able to create funds with the same name
Summary: Not being able to create funds with the same name
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Francois Charbonnier
QA Contact: Ian Walls
URL:
Keywords:
: 5017 (view as bug list)
Depends on:
Blocks: 7163
  Show dependency treegraph
 
Reported: 2011-12-02 09:56 UTC by claire.hernandez@biblibre.com
Modified: 2014-12-07 20:02 UTC (History)
6 users (show)

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


Attachments
Bug 7303 Adds unicity for budget and fund (8.14 KB, patch)
2012-02-16 12:06 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 7303: Adds unicity for budget and fund (8.11 KB, patch)
2012-08-10 11:13 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description claire.hernandez@biblibre.com 2011-12-02 09:56:04 UTC
fund code / fund name unicity is now guaranteed	 (BibLibre MT5553)
Comment 1 Jonathan Druart 2012-02-16 12:06:59 UTC Comment hidden (obsolete)
Comment 2 Katrin Fischer 2012-02-16 12:21:58 UTC
I wonder if this is a good idea?

1) The aqbudgets table already has a primary key (budget_id) as has aqbudgetperiods (budget_period_id).
 
2) We have a new feature in master to duplicate budgets and funds for a new year that I think is very useful and will probably be broken by this change.

3) I see no reason, why a library should be forced to rename their funds every year? I think having the fund names unique within a budget would make sense, but having them unique on database level seems not right to me. Where necessary budget and fund could be displayed together to make it possible to see which year/budget period the fund belonged to.

4) It's also currently not enforced, so what will happen on update?
Comment 3 Francois Charbonnier 2012-02-16 16:07:07 UTC
I will let Jonathan find the good way to do it. (Constraint or not at the database level.)

The question is : what feature do we want as a library?

On one hand, if a library duplicates their budgets/funds, I can't see why they should rename them, for sure

On the other hand, if a libray needs to duplicates their budgets/funds, to me, it means that they might have a lot of them. At this point, I can see why they want Koha to tell them that they already created a fund with the same name/code when they will create the funds in the first place...

But, like you said, there is a conflict with this feature (duplicate budget and fund feature)  http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6943 (jonathan just tested it)

So to me, there are 2 options :

* we give up this feature. libraries will be able to create as many fund with the same code/name as they want (which is not going to be fun when they will have to order a new book and choose between the same fund names in the fund list or follow what amouts are ordered/spent/available for each funds on the acquisition home page... ;^)

* we change the old funds code/name during the duplication process. The old fund could be pre or post-fixed by something chose when duplicating the budget/funds. But I'm not sure of the impact of this... At the same time, all the budgets will be inactive once they have been duplicated so maybe we dont care...

So Katrin, what do you think?
Comment 4 Katrin Fischer 2012-02-16 16:55:48 UTC
I don't think (and I might be wrong) that we don't need to check so strictly here. If there are duplicates, they can be corrected easily.
Or perhaps it would perhaps make sense to have a client side check for the same fund name on the same hierarchy level.

In my opinion the problem in budgets and funds is not so much possible duplication, but the missing reflection of hierarchies in display.

I could imagine it would be clearer if we did something like:

fund (budget) = Books (2012)

or

budget (as optgroup in the list)
    fund
    fund
    fund
budget
    fund 
    fund 
        child fund
        child fund

etc.

But that is clearly a different problem :)

I think libraries want to reuse their budget codes and descriptions, because they are using the names and budget codes from their institution. And those will stay the same for each year.
Comment 5 jmbroust 2012-03-19 13:31:07 UTC
<h1>Something went wrong !</h1>Applying: Bug 7303: Adds unicity for budget and
fund<br/>
Using index info to reconstruct a base tree...<br/>
Falling back to patching base and 3-way merge...<br/>
Auto-merging installer/data/mysql/kohastructure.sql<br/>
Auto-merging installer/data/mysql/updatedatabase.pl<br/>
CONFLICT (content): Merge conflict in
installer/data/mysql/updatedatabase.pl<br/>
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/aqbudgets.tt<br/>
Failed to merge in the changes.<br/>
Comment 6 Katrin Fischer 2012-04-15 11:02:14 UTC
*** Bug 5017 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Druart 2012-08-10 11:13:57 UTC
Created attachment 11528 [details] [review]
Bug 7303: Adds unicity for budget and fund

This patch adds a unique key on fields:
aqbudgets.budget_name
aqbudgets.budget_code
aqbudgetperiods.budget_period_description

To test, try to:
- create 2 budgets with same description
- create 2 funds with same name
- create 2 funds with same code

All of these cases should be generate an error
Comment 8 Katrin Fischer 2012-08-10 11:24:10 UTC
Hi Jonathan and all,

I still think a unique key on aqbudgets.budget_name and aqbudgets.budget_code it's a bad idea and will break workflows for libraries.

1) The aqbudgets table already has a primary key (budget_id) as has aqbudgetperiods (budget_period_id).
 
2) It will make it impossible to duplicate your budget hierarchy for the next year which is a working feature in master.

3) A feature I am asked for is a way to move orders and money from one year to the next. I think if it's allowed to use the same codes, this is very easy to do - but if you are forced to change them each year, you will need some tool for mapping funds over several years.

4) The codes libraries here use do not change with each year - you would force them to add a prefix/suffix or something similar. This would make their life harder, for example when they need reports with the official codes and descriptions.

5) It's currently not enforced - I think the update database will not work?

If this is only a check for libraries editing/adding new funds, couldn't we make it only check for duplicates in the same time period/budget? And a way to overwrite if it's intended?
Comment 9 claire.hernandez@biblibre.com 2012-08-17 10:15:00 UTC
The feature asked by the customer cannot be rebased like this in the community version.

Technically it is not possible to have a constraint on the fund code or name.
Usability point of view, each time a user adds a new fund with an existant code koha will asked him "are you sure..." (could be another bz).

The initial patch adds nothing pertinent in the community version and breaks another wanted feature (duplicate budget hierarchy) so I will close it.


(In reply to comment #8)
> Hi Jonathan and all,
> 
> I still think a unique key on aqbudgets.budget_name and
> aqbudgets.budget_code it's a bad idea and will break workflows for libraries.
> 
> 1) The aqbudgets table already has a primary key (budget_id) as has
> aqbudgetperiods (budget_period_id).
>  
> 2) It will make it impossible to duplicate your budget hierarchy for the
> next year which is a working feature in master.
> 
> 3) A feature I am asked for is a way to move orders and money from one year
> to the next. I think if it's allowed to use the same codes, this is very
> easy to do - but if you are forced to change them each year, you will need
> some tool for mapping funds over several years.
> 
> 4) The codes libraries here use do not change with each year - you would
> force them to add a prefix/suffix or something similar. This would make
> their life harder, for example when they need reports with the official
> codes and descriptions.
> 
> 5) It's currently not enforced - I think the update database will not work?
> 
> If this is only a check for libraries editing/adding new funds, couldn't we
> make it only check for duplicates in the same time period/budget? And a way
> to overwrite if it's intended?