Summary: | MANUAL_INV values should be able to have a code, a description, and a price. | ||
---|---|---|---|
Product: | Koha | Reporter: | Kyle M Hall <kyle> |
Component: | Circulation | Assignee: | Kyle M Hall <kyle> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | 1joynelson, gmcharlt, katrin.fischer, kyle.m.hall, martin.renvoize, nengard |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9173 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21739 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23049 |
||
Change sponsored?: | Sponsored | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: |
Sponsored by Pasco County Library System
|
Version(s) released in: |
Description
Kyle M Hall
2019-09-18 15:12:19 UTC
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. |