Issue 2551168
Created on 2021-11-08 17:32 by schlatterbeck, last changed 2022-04-28 08:32 by schlatterbeck.
Messages | |||
---|---|---|---|
msg7360 | Author: [hidden] (schlatterbeck) | Date: 2021-11-08 17:32 | |
In a customer tracker we have a class 'opportunity' with the key 'opportunity_id' Searching in the REST-API for (note the '/' separating the opportunity_id part) .../rest/data/opportunity/opportunity_id=1234567 will retrieve the opportunity with the given ID and display it like the url ended in .../opportunity This seems to be an undocumented feature. It *is* possible to search for .../opportunity/key where key would be the key of the class we search for (which is also currently undocumented as far as I can see). And I remember that for ambiguous cases (like this one) where the key is numeric that it was permitted to add the key property in the URL to allow searching for numeric keys. What do we do with it? Note that this doesn't just do a search like for issue: .../rest/data/issue?title=just%20a%20test will find some issues in my test-tracker while the same with a '/' won't find any. So this only works for key properties. You can reproduce this with the standard schema with .../rest/data/status/name=open or .../rest/data/status/open I think this should be documented and tests be developed... What do you think? |
|||
msg7361 | Author: [hidden] (rouilj) | Date: 2021-11-09 00:39 | |
Hi Ralf: In message <1636392735.95.0.682441672084.issue2551168@roundup.psfhosted.org>, Ralf Schlatterbeck writes: >What do we do with it? > >Note that this doesn't just do a search like for issue: >.../rest/data/issue?title=just%20a%20test >will find some issues in my test-tracker while the same with a '/' >won't find any. So this only works for key properties. > >You can reproduce this with the standard schema with >.../rest/data/status/name=open >or >.../rest/data/status/open > >I think this should be documented and tests be developed... Isn't this the documentation for it: https://www.roundup-tracker.org/docs/rest.html#retrieve-item-using-key-value We do warn that the short form (/data/status/open) doesn't work for numbers (it's interprested as an id) and may not be supported in future versions of the API. >What do you think? Testing yes. But I think it's already doc'ed (although I did forget about that option). |
|||
msg7398 | Author: [hidden] (rouilj) | Date: 2021-12-07 04:55 | |
Ralf, do you agree that this is documented and all we need is testing? |
|||
msg7400 | Author: [hidden] (schlatterbeck) | Date: 2021-12-07 07:49 | |
Yes, I agree that this is well documented, seems I didn't find it immediately when I created this issue. |
|||
msg7437 | Author: [hidden] (rouilj) | Date: 2022-01-09 02:24 | |
Ralf have you had any luck on testing this? |
|||
msg7458 | Author: [hidden] (rouilj) | Date: 2022-03-06 03:17 | |
Hi Ralf, have you added any tests for this? -- rouilj |
|||
msg7471 | Author: [hidden] (schlatterbeck) | Date: 2022-04-28 08:32 | |
Sorry for not following up on this for so long. I've just checked: We *do* test this. See in test/rest_common.py starting around line 332. The comments there read "Obtain data for 'joe' via username lookup." and "Obtain data for 'joe' via username lookup (long form)." The first tests the case .../rest/data/user/joe and the second tests the case .../rest/data/user/username=joe So we actually *do* have the necessary tests. Closing this issue. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-28 08:32:22 | schlatterbeck | set | status: new -> closed messages: + msg7471 |
2022-03-06 03:17:42 | rouilj | set | messages: + msg7458 |
2022-01-09 02:24:44 | rouilj | set | messages: + msg7437 |
2021-12-07 07:49:53 | schlatterbeck | set | messages: + msg7400 |
2021-12-07 04:55:13 | rouilj | set | messages: + msg7398 |
2021-11-09 00:39:03 | rouilj | set | messages: + msg7361 |
2021-11-08 17:32:15 | schlatterbeck | create |