In essence, MANUAL_INV authorised values should be able to have a more traditional code for ease of writing queries. For example, instead of "Copier Fees" as the AV, it should be "COPY", with a description of "Copier Fees[.25]" where we can extract the part in brackets as the value to put in price. This would be more friendly and flexible.
If we went a bit further we could do "Description [price][note]"
Maybe it would be cleaner to just add a new column to the db to store the value? We could decide to only show it for some categories (hardcoded for now)
*** Bug 9173 has been marked as a duplicate of this bug. ***
(In reply to Katrin Fischer from comment #2) > Maybe it would be cleaner to just add a new column to the db to store the > value? We could decide to only show it for some categories (hardcoded for > now) That would be a good solution as well, but definitely raises the complexity bar much higher. It's pretty trivial to parse out the value with some form of structure like I am proposing, and it gives us a clean upgrade path as well!
But user side it needs a lot more explanation/documenting and is just another "weird" syntax we use nowhere else :)
(In reply to Katrin Fischer from comment #5) > But user side it needs a lot more explanation/documenting and is just > another "weird" syntax we use nowhere else :) perfect is the enemy of good
(In reply to Kyle M Hall from comment #6) > (In reply to Katrin Fischer from comment #5) > > But user side it needs a lot more explanation/documenting and is just > > another "weird" syntax we use nowhere else :) > > perfect is the enemy of good I am really not sure this applies here - we already have lots of 'undocumented' magic in Koha that gets lost in the dark of the code... I just realized again giving a little workshop recently. Good for us insiders, not so good for people trying to learn Koha on their own.
Personally I hate having this as an authorized value at all.. and have for a long time been trying to work towards pulling it out and putting it into it's own table where extensions like this would make good sense. That's been met with some resistance too however and as such in some of the work I've already done I've reverted to just using the existing code to 'get it done'. I already introduce at least a small part of this feature but misusing av fields in bug 23354 and I propose shifting into it's own table and corresponding UX in bug 23049. I'd love some help working through 23049.. we could even fold it into 23354 if we really needed to.
I ended up implementing all of the features detailed here in 23049 which is now pushed to master. *** This bug has been marked as a duplicate of bug 23049 ***