Bug 37934 - Extend length of API key, requestor ID and customer ID for data providers
Summary: Extend length of API key, requestor ID and customer ID for data providers
Status: Pushed to stable
Alias: None
Product: Koha
Classification: Unclassified
Component: ERM (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: Katrin Fischer
QA Contact: Lucas Gass (lukeg)
URL:
Keywords: rel_24_11_candidate
: 38807 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-09-16 16:46 UTC by Katrin Fischer
Modified: 2025-06-19 08:05 UTC (History)
9 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
25.05.00,24.11.06
Circulation function:


Attachments
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers (3.69 KB, patch)
2025-04-01 09:31 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers (3.74 KB, patch)
2025-04-01 10:02 UTC, Jesse Maseto
Details | Diff | Splinter Review
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers (3.80 KB, patch)
2025-04-02 09:36 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2024-09-16 16:46:36 UTC
API Key, requestor ID and customer ID are defined as varchar(80). We had reports that this can be not enough in some cases. Suggestion is to extend to varchar(255).

https://schema.koha-community.org/24_05/tables/erm_usage_data_providers.html
Comment 1 Michaela Sieber 2024-10-25 11:02:31 UTC
And for service_url 80 characters are not enough as well
Comment 2 Katrin Fischer 2025-01-02 09:41:21 UTC
*** Bug 38807 has been marked as a duplicate of this bug. ***
Comment 3 Mathieu Saby 2025-01-03 10:07:53 UTC
Is there a specification in SUSHI documentation regarding the lengh of those fields? I tried to search but I only found in their OpenAPI specification that those fields have "ApiKey" datatype, which does not seem to have a lenght limit.
Comment 4 Katrin Fischer 2025-01-03 10:16:43 UTC
(In reply to Mathieu Saby from comment #3)
> Is there a specification in SUSHI documentation regarding the lengh of those
> fields? I tried to search but I only found in their OpenAPI specification
> that those fields have "ApiKey" datatype, which does not seem to have a
> lenght limit.

I have wondered the same thing in order to make sure we pick the right datatypes here. Did you encounter anything close to 255 chars yet?
Comment 5 Jonathan Field 2025-01-03 10:39:28 UTC
(In reply to Katrin Fischer from comment #4)
> (In reply to Mathieu Saby from comment #3)
> > Is there a specification in SUSHI documentation regarding the lengh of those
> > fields? I tried to search but I only found in their OpenAPI specification
> > that those fields have "ApiKey" datatype, which does not seem to have a
> > lenght limit.
> 
> I have wondered the same thing in order to make sure we pick the right
> datatypes here. Did you encounter anything close to 255 chars yet?

(In reply to Mathieu Saby from comment #3)
> Is there a specification in SUSHI documentation regarding the lengh of those
> fields? I tried to search but I only found in their OpenAPI specification
> that those fields have "ApiKey" datatype, which does not seem to have a
> lenght limit.

I think the NISO standard is the place to look - https://groups.niso.org/higherlogic/ws/public/download/29097/Z39-93-2014_SUSHI-1_7.pdf - However, there don't seem to be restrictions on length. So, I guess we need to work with the longest examples we have. I think increasing to 255 would cover that, wouldn't you?
Comment 6 Katrin Fischer 2025-01-03 10:50:34 UTC
> I think the NISO standard is the place to look -
> https://groups.niso.org/higherlogic/ws/public/download/29097/Z39-93-
> 2014_SUSHI-1_7.pdf - However, there don't seem to be restrictions on length.
> So, I guess we need to work with the longest examples we have. I think
> increasing to 255 would cover that, wouldn't you?

I believe so. It would be interesting to hear what the longest encountered were to see how close we get.
Comment 7 Katrin Fischer 2025-03-11 13:11:55 UTC
@Michaela maybe: Can you check in your data for the length of your longest key?
Comment 8 Michaela Sieber 2025-03-12 10:05:01 UTC
(In reply to Katrin Fischer from comment #7)
> @Michaela maybe: Can you check in your data for the length of your longest
> key?

The longest API Key we have is for SAE Mobilus (see https://registry.countermetrics.org/platform/ee4dbcd0-e6ca-49c8-aca1-759eae5f624f)
and it has 256 characters.
Comment 9 Katrin Fischer 2025-03-12 10:27:34 UTC
That is a lot, thanks!
Comment 10 Katrin Fischer 2025-03-12 10:30:10 UTC
I wonder if we should just use text then.
Comment 11 Katrin Fischer 2025-04-01 09:31:32 UTC
Created attachment 180107 [details] [review]
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers

This changes the datatype of customer ID, requestor ID, and API key
from limited varchar to text to accustom for longer values.

To test:
* Apply the patch
* Run updatedatabase (a sandbox will do this automatically)
* Activate the ERM module in the system preferences (ERMModule)
* Go to E-ressource management > Data providers > New data provider
* Make sure you can enter values longer than 265 in the fields named
  above and that they are stored correctly.
Comment 12 Jesse Maseto 2025-04-01 10:02:14 UTC
Created attachment 180112 [details] [review]
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers

This changes the datatype of customer ID, requestor ID, and API key
from limited varchar to text to accustom for longer values.

To test:
* Apply the patch
* Run updatedatabase (a sandbox will do this automatically)
* Activate the ERM module in the system preferences (ERMModule)
* Go to E-ressource management > Data providers > New data provider
* Make sure you can enter values longer than 265 in the fields named
  above and that they are stored correctly.

Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Comment 13 Lucas Gass (lukeg) 2025-04-02 09:36:00 UTC
Created attachment 180273 [details] [review]
Bug 37934: Extend data types for customer ID, requestor ID, and API key for ERM data providers

This changes the datatype of customer ID, requestor ID, and API key
from limited varchar to text to accustom for longer values.

To test:
* Apply the patch
* Run updatedatabase (a sandbox will do this automatically)
* Activate the ERM module in the system preferences (ERMModule)
* Go to E-ressource management > Data providers > New data provider
* Make sure you can enter values longer than 265 in the fields named
  above and that they are stored correctly.

Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 14 Katrin Fischer 2025-04-14 06:52:35 UTC
Pushed for 25.05!

Well done everyone, thank you!
Comment 15 Fridolin Somers 2025-06-19 08:05:22 UTC
Pushed to 24.11.x for 24.11.06