searchTasks API documentation doesn't document acceptable status arguments
Bug #590561 reported by
Jonathan Lange
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
| lazr.restful |
Triaged
|
Low
|
Unassigned | ||
Bug Description
From https:/
"""
Status
Show only bugs with the given status value or list of values.
"""
It would be very useful to see what actual values one is allowed to provide. From my own experimentation, I think the list is: "New", "Incomplete", "Invalid", "Won't Fix", "Confirmed", "Triaged", "In Progress", "Fix Committed", "Fix Released".
There's maybe a deeper bug here about documenting enum thingystuff over RESTful whatsits.
| Changed in malone: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
Revision history for this message
| Jonathan Lange (jml) wrote | #1 |
| Changed in lazr.restful: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| tags: | added: bug-search |
To post a comment you must log in.
The root cause of this bug is definitely nothing to do with malone, but rather with something in the wadl generation. You'll notice that searchTasks's hardware_bus parameter has documented options, even though status and importance are not documented. This is true down to the wadl level. I *think* this might be related to bug 364596.
Look for "<option" in src/lazr/