fund code / fund name unicity is now guaranteed (BibLibre MT5553)
Created attachment 7683 [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
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?
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?
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.
<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/>
*** Bug 5017 has been marked as a duplicate of this bug. ***
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
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?
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?