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
And for service_url 80 characters are not enough as well
*** Bug 38807 has been marked as a duplicate of this bug. ***
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.
(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 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?
> 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.
@Michaela maybe: Can you check in your data for the length of your longest key?
(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.
That is a lot, thanks!
I wonder if we should just use text then.
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.
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>
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>
Pushed for 25.05! Well done everyone, thank you!
Pushed to 24.11.x for 24.11.06