Bug 31017 - Add type field for vendors
Summary: Add type field for vendors
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 33003 33004
  Show dependency treegraph
 
Reported: 2022-06-22 16:24 UTC by Nick Clemens
Modified: 2023-12-28 20:42 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact: Caroline Cyr La Rose
Documentation submission: https://gitlab.com/koha-community/koha-manual/-/merge_requests/628
Text to go in the release notes:
This enhancement adds a new field to record the vendor type when creating or editing vendors. This field can be used as a free text field, or a drop-down menu if there are authorized values in the VENDOR_TYPE authorized value category.
Version(s) released in:
22.11.00


Attachments
Bug 31017: DB Updates (2.26 KB, patch)
2022-06-23 11:02 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: DO NOT PUSH - Schema updates (1.43 KB, patch)
2022-06-23 11:03 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screena dn display (4.29 KB, patch)
2022-06-23 11:03 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screen and display (6.04 KB, patch)
2022-07-01 13:07 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screen and display (6.10 KB, patch)
2022-07-04 20:16 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 31017: DB Updates (2.32 KB, patch)
2022-07-26 07:01 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 31017: DO NOT PUSH - Schema updates (1.49 KB, patch)
2022-07-26 07:01 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screen and display (6.16 KB, patch)
2022-07-26 07:01 UTC, ByWater Sandboxes
Details | Diff | Splinter Review
Bug 31017: DB Updates (2.32 KB, patch)
2022-08-09 19:39 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screen and display (6.16 KB, patch)
2022-08-09 19:39 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: Update field name to 'type' (5.08 KB, patch)
2022-08-09 19:39 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: DO NOT PUSH - Schema updates (1.41 KB, patch)
2022-08-09 19:39 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 31017: DB Updates (2.40 KB, patch)
2022-08-10 09:35 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 31017: Add new vendor_type field to edit screen and display (6.24 KB, patch)
2022-08-10 09:35 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 31017: Update field name to 'type' (5.17 KB, patch)
2022-08-10 09:35 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 31017: DO NOT PUSH - Schema updates (1.49 KB, patch)
2022-08-10 09:35 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 31017: (follow-up) Add type field to api (761 bytes, patch)
2022-08-10 17:25 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2022-06-22 16:24:01 UTC
Some libraries have many vendors, and they serve different purposes e.g. booksellers vs donors vs electronic resource providers

It would be nice to have a way to differentiate these types for reporting (and eventually for searching)
Comment 1 Nick Clemens 2022-06-23 11:02:59 UTC
Created attachment 136443 [details] [review]
Bug 31017: DB Updates
Comment 2 Nick Clemens 2022-06-23 11:03:03 UTC
Created attachment 136444 [details] [review]
Bug 31017: DO NOT PUSH  - Schema updates
Comment 3 Nick Clemens 2022-06-23 11:03:06 UTC
Created attachment 136445 [details] [review]
Bug 31017: Add new vendor_type field to edit screena dn display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
1 - Apply patch, update database
2 - Edit/create a vendor in acquisitions
3 - Note new 'Vendor type' field, free text in editor
4 - Save a value
5 - Confirm it displays in vendor search results and vendor main page
6 - In Authorised values add a new value to 'VENDOR_TYPE' category
7 - Add/Edit a vendor, note the vendor type is now a dropdown selection
8 - Save with a value
9 - Confirm the description shows in results and vendor page
Comment 4 David Nind 2022-06-27 10:42:45 UTC
I couldn't see the vendor category on the vendor page.

Is the expectation that libraries will choose either the free form text field, or use the authorized values?
Comment 5 Caroline Cyr La Rose 2022-06-30 15:43:50 UTC
Hi Nick!

1) I second David in saying that the vendor type should appear on the vendor details page (supplier.pl). Right now, it only appears in booksellers.pl

2) I would add a description to the authorised value category. Maybe something like
"Values that can be entered to fill in the 'Vendor type' field in the acquisitions module, that can be used for statistical purposes"

(I copied from Bsort1, but feel free to put whatever description you think is best)


To answer David' second comment, I think it is ok to have either free text or authorised value. It is the same about everywhere in Koha: patron sort fields, acquisitions statistical fields, drop downs in MARC frameworks, etc. In all those cases, if you add values in the AV category, the free text field will become a drop down and you cannot choose to have both free text and dropdown. The only exceptions AFAIK are in the MARC frameworks, where it is now possible to add values on the fly while cataloging; the suggestion approval/refusal reasons, where there is an 'Other' option that, when selected opens a free text field; and for the cities and towns in patron files, where you can choose from the drop down or manually enter a city. But that last one (cities) is not authorised values...
Comment 6 David Nind 2022-06-30 18:45:11 UTC
(In reply to Caroline Cyr La Rose from comment #5)
> To answer David' second comment, I think it is ok to have either free text
> or authorised value. It is the same about everywhere in Koha: patron sort
> fields, acquisitions statistical fields, drop downs in MARC frameworks, etc.
> ...

Thanks Caroline. I hadn't noticed this before, and this was the first time I'd come across it. (I've been living such a sheltered life in Kohaland!)
Comment 7 Rachael 2022-06-30 20:36:11 UTC
Tester par Rachael Laritz
Comment 8 Nick Clemens 2022-07-01 13:07:00 UTC
Created attachment 136903 [details] [review]
Bug 31017: Add new vendor_type field to edit screen and display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
 1 - Apply patch, update database
 2 - Edit/create a vendor in acquisitions
 3 - Note new 'Vendor type' field, free text in editor
 4 - Save a value
 5 - Confirm it displays in vendor search results and vendor main page
 6 - In Authorised values add a new value to 'VENDOR_TYPE' category
 7 - Confirm the description of VENDOR_TYPE shows and makes sense
 8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
 9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details
Comment 9 ByWater Sandboxes 2022-07-04 20:16:13 UTC
Created attachment 137134 [details] [review]
Bug 31017: Add new vendor_type field to edit screen and display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
 1 - Apply patch, update database
 2 - Edit/create a vendor in acquisitions
 3 - Note new 'Vendor type' field, free text in editor
 4 - Save a value
 5 - Confirm it displays in vendor search results and vendor main page
 6 - In Authorised values add a new value to 'VENDOR_TYPE' category
 7 - Confirm the description of VENDOR_TYPE shows and makes sense
 8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
 9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details

Signed-off-by: Caroline <caroline.cyr-la-rose@inlibro.com>
Comment 10 ByWater Sandboxes 2022-07-26 07:01:30 UTC
Created attachment 138116 [details] [review]
Bug 31017: DB Updates

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Comment 11 ByWater Sandboxes 2022-07-26 07:01:33 UTC
Created attachment 138117 [details] [review]
Bug 31017: DO NOT PUSH - Schema updates

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Comment 12 ByWater Sandboxes 2022-07-26 07:01:37 UTC
Created attachment 138118 [details] [review]
Bug 31017: Add new vendor_type field to edit screen and display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
 1 - Apply patch, update database
 2 - Edit/create a vendor in acquisitions
 3 - Note new 'Vendor type' field, free text in editor
 4 - Save a value
 5 - Confirm it displays in vendor search results and vendor main page
 6 - In Authorised values add a new value to 'VENDOR_TYPE' category
 7 - Confirm the description of VENDOR_TYPE shows and makes sense
 8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
 9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details

Signed-off-by: Caroline <caroline.cyr-la-rose@inlibro.com>

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Comment 13 Jonathan Druart 2022-08-09 10:00:13 UTC
Why "vendor_type"?
Comment 14 Jonathan Druart 2022-08-09 10:01:38 UTC
I mean, why is the DB column named "vendor_type"? We are not supposed to repeat the table's name in the column's name (aqbooksellers must be named vendor).
Yes, 'type' is a terrible naming, but having the repetition seems worst.
Comment 15 Nick Clemens 2022-08-09 12:01:52 UTC
(In reply to Jonathan Druart from comment #14)
> I mean, why is the DB column named "vendor_type"? We are not supposed to
> repeat the table's name in the column's name (aqbooksellers must be named
> vendor).
> Yes, 'type' is a terrible naming, but having the repetition seems worst.

Happy to adjust if we have a better option:
classification
category
organization_type

Or I can just make it type
Comment 16 Jonathan Druart 2022-08-09 12:36:05 UTC
What would be real-life values?
Comment 17 Katrin Fischer 2022-08-09 12:48:38 UTC
(In reply to Jonathan Druart from comment #16)
> What would be real-life values?

I thought this was related to the ERM work tbh :)

Examples could be: Consortium, Library, Platform, Vendor etc.
Comment 18 Caroline Cyr La Rose 2022-08-09 12:57:41 UTC
(In reply to Katrin Fischer from comment #17)
> (In reply to Jonathan Druart from comment #16)
> > What would be real-life values?
> 
> I thought this was related to the ERM work tbh :)
> 
> Examples could be: Consortium, Library, Platform, Vendor etc.

I thought examples would be: Print, Audio, Maps, etc. Like "what type of things we buy from that vendor" (that's how I classified my vendors when I used to do acquisitions). But I guess that's the beauty of it, that it can be whatever the user needs.
Comment 19 Caroline Cyr La Rose 2022-08-09 13:00:17 UTC
Nick also mentioned other classifications in the bug description

> Some libraries have many vendors, and they serve different purposes e.g.
> booksellers vs donors vs electronic resource providers
Comment 20 Nick Clemens 2022-08-09 13:01:49 UTC
(In reply to Jonathan Druart from comment #16)
> What would be real-life values?

For the library requesting this it was values like:
Copyright holder
Donor
Book vendor
etc.

It's really a way to classify/organize vendors for searching/reporting/etc

category or type feel most correct to me
Comment 21 Jonathan Druart 2022-08-09 13:52:17 UTC
I've used 'type' a lot for ERM, and it always feel wrong/too generic.

If you are happy with 'type', go for it :)
Comment 22 Nick Clemens 2022-08-09 19:39:05 UTC
Created attachment 138942 [details] [review]
Bug 31017: DB Updates

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Comment 23 Nick Clemens 2022-08-09 19:39:09 UTC
Created attachment 138943 [details] [review]
Bug 31017: Add new vendor_type field to edit screen and display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
 1 - Apply patch, update database
 2 - Edit/create a vendor in acquisitions
 3 - Note new 'Vendor type' field, free text in editor
 4 - Save a value
 5 - Confirm it displays in vendor search results and vendor main page
 6 - In Authorised values add a new value to 'VENDOR_TYPE' category
 7 - Confirm the description of VENDOR_TYPE shows and makes sense
 8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
 9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details

Signed-off-by: Caroline <caroline.cyr-la-rose@inlibro.com>

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>
Comment 24 Nick Clemens 2022-08-09 19:39:13 UTC
Created attachment 138944 [details] [review]
Bug 31017: Update field name to 'type'
Comment 25 Nick Clemens 2022-08-09 19:39:17 UTC
Created attachment 138945 [details] [review]
Bug 31017: DO NOT PUSH - Schema updates
Comment 26 Jonathan Druart 2022-08-10 09:35:26 UTC
Created attachment 138964 [details] [review]
Bug 31017: DB Updates

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 27 Jonathan Druart 2022-08-10 09:35:30 UTC
Created attachment 138965 [details] [review]
Bug 31017: Add new vendor_type field to edit screen and display

This patch adds a new vendor_type field when creating/editing vendors
and displays the field on search and details for a vendor

To test:
 1 - Apply patch, update database
 2 - Edit/create a vendor in acquisitions
 3 - Note new 'Vendor type' field, free text in editor
 4 - Save a value
 5 - Confirm it displays in vendor search results and vendor main page
 6 - In Authorised values add a new value to 'VENDOR_TYPE' category
 7 - Confirm the description of VENDOR_TYPE shows and makes sense
 8 - Add/Edit a vendor, note the vendor type is now a dropdown selection
 9 - Save with a value
10 - Confirm the description shows in results and vendor page and vendor details

Signed-off-by: Caroline <caroline.cyr-la-rose@inlibro.com>

Signed-off-by: KIT Library Germany <michaela.sieber@kit.edu>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 28 Jonathan Druart 2022-08-10 09:35:35 UTC
Created attachment 138966 [details] [review]
Bug 31017: Update field name to 'type'

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 29 Jonathan Druart 2022-08-10 09:35:40 UTC
Created attachment 138967 [details] [review]
Bug 31017: DO NOT PUSH - Schema updates

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Comment 30 Jonathan Druart 2022-08-10 09:36:32 UTC
Passing QA, but I don't think we should start with no value (and a free input text).
I think it would be better to have few values (to show what could be possible values) that could even be translatable.
Letting author and RM decide. This could be done separately (but before 21.11 ideally).
Comment 31 Jonathan Druart 2022-08-10 09:37:05 UTC
(In reply to Jonathan Druart from comment #30)
> Letting author and RM decide. This could be done separately (but before
> 21.11 ideally).

Ha, apparently we are (already!) working for 22.11.. :D
Comment 32 Nick Clemens 2022-08-10 17:25:11 UTC
Created attachment 139007 [details] [review]
Bug 31017: (follow-up) Add type field to api
Comment 33 Tomás Cohen Arazi 2022-08-19 19:14:05 UTC
(In reply to Jonathan Druart from comment #31)
> (In reply to Jonathan Druart from comment #30)
> > Letting author and RM decide. This could be done separately (but before
> > 21.11 ideally).
> 
> Ha, apparently we are (already!) working for 22.11.. :D

LOL
Comment 34 Tomás Cohen Arazi 2022-08-19 19:31:39 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!
Comment 35 Lucas Gass 2022-10-14 19:35:13 UTC
Enhancement, will not be backported to 22.05.x series
Comment 36 Jonathan Druart 2023-02-23 09:37:35 UTC
(In reply to Jonathan Druart from comment #30)
> Passing QA, but I don't think we should start with no value (and a free
> input text).
> I think it would be better to have few values (to show what could be
> possible values) that could even be translatable.
> Letting author and RM decide. This could be done separately (but before
> 21.11 ideally).

I should have Failed QA because of this. It adds unnecessary complications when done after...