Add url encoding for SearchInterfaceTypes other than SRU
Add url encoding for idPrameter, prefix and identifier for SearchInterfaceTypes other than SRU
fix #5945
Looks good. I am wondering whether we also need to encode the query parameter values here: https://github.com/kitodo/kitodo-production/blob/83b1b9fcbb586add543a55c8d7844d0d82077e36/Kitodo-Query-URL-Import/src/main/java/org/kitodo/queryurlimport/QueryURLImport.java#L417
I suppose this is right now only used in SRU context, where we can search for different values than the ID. But it is probably a good idea to implment encoding here as well for future usages.
Looks good. I am wondering whether we also need to encode the query parameter values here:
https://github.com/kitodo/kitodo-production/blob/83b1b9fcbb586add543a55c8d7844d0d82077e36/Kitodo-Query-URL-Import/src/main/java/org/kitodo/queryurlimport/QueryURLImport.java#L417
I suppose this is right now only used in SRU context, where we can search for different values than the ID. But it is probably a good idea to implment encoding here as well for future usages.
I have updated the fix/url-encoding branch to also fix this for other searchinterfaces. @BartChris do you think, this is sufficient?
Changes look good and work. Regarding the encoding of the search string (query by query field)
https://github.com/kitodo/kitodo-production/blob/25cd0888a4543ad58adb559b40cdb43f2408002f/Kitodo-Query-URL-Import/src/main/java/org/kitodo/queryurlimport/QueryURLImport.java#L421-L427
i noticed that
- there is never a search conducted from Kitodo which is using another interface than SRU (apart from the search by ID of course)
- we are joining the search String by "AND" although it is impossible to have more than one query keyword for a single search
- Other interface are probably not joining their queries by "AND"
But i would suggest keeping it the way it is done in the PR to have it documented in the code that encoding is necessary for all interfaces.
@gerlingsm would you mind opening a corresponding pull request with the same fix against the 3.6.x branch?
@gerlingsm would you mind opening a corresponding pull request with the same fix against the 3.6.x branch?
This is not a problem, I have prepared a corresponding pull request #6060