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: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: ERM (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: Katrin Fischer
QA Contact: Testopia
URL:
Keywords:
: 38807 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-09-16 16:46 UTC by Katrin Fischer
Modified: 2025-01-03 10:50 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

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.