Bug 23636 - MANUAL_INV values should be able to have a code, a description, and a price.
Summary: MANUAL_INV values should be able to have a code, a description, and a price.
Status: RESOLVED DUPLICATE of bug 23049
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Keywords:
: 9173 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-18 15:12 UTC by Kyle M Hall
Modified: 2019-11-21 09:18 UTC (History)
6 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2019-09-18 15:12:19 UTC
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.
Comment 1 Kyle M Hall 2019-09-18 16:15:57 UTC
If we went a bit further we could do "Description [price][note]"
Comment 2 Katrin Fischer 2019-09-22 10:58:02 UTC
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)
Comment 3 Katrin Fischer 2019-09-22 11:29:51 UTC
*** Bug 9173 has been marked as a duplicate of this bug. ***
Comment 4 Kyle M Hall 2019-09-24 11:16:08 UTC
(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!
Comment 5 Katrin Fischer 2019-09-24 11:17:55 UTC
But user side it needs a lot more explanation/documenting and is just another "weird" syntax we use nowhere else :)
Comment 6 Kyle M Hall 2019-09-24 11:19:34 UTC
(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
Comment 7 Katrin Fischer 2019-09-24 13:33:26 UTC
(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.
Comment 8 Martin Renvoize 2019-09-24 14:05:28 UTC
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.
Comment 9 Martin Renvoize 2019-10-24 21:09:55 UTC
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 ***