5

1

Currently, the only way (that I know about) to get list of cases for given filter via XML API is to use:

  1. cmd=setCurrentFilter, with correct sFilter parameter
  2. cmd=search with empty or missing q parameter -- this returns cases in current filter.

Problem is that setCurrentFilter also changes the filter in web UI. To fix this problem, it's better to use:

  1. cmd=listFilters -- to get current filter, i.e. filter with status="current"
  2. cmd=setCurrentFilter as before
  3. cmd=search as before
  4. cmd=setCurrentFilter to set back filter from step 1.

There are three problems with this scenario: 1) it takes four requests/replies, 2) there is short period of time when filter is changed and user may see unexpected behaviour in the web UI, 3) if current filter during first step is not one of the saved filters, listFilters will not tell us which filter is current, so we cannot set it back in step 4 :-(

Would it be possible to add a possibility to get list of cases for given filter simply by sending sFilter parameter to cmd=search command? It would not change current filter for user, and would return cases for this filter. This solution would not only be fastest (one request/response only), but would also help to fix unexpected behaviour related to changing global filter.

Fog Creek Case FC1814324

flag

1 Answer

1

Ugh. It's odd to have something from the programmatic interface interfere with the user interface. I'm of the mind that we should ditch all filter functionality from the API entirely, having it rely only on search (which is what I'd recommend here).

That said, there is outside functionality built around the filters operating this way, so the next solution is to be able to get the filter results without changing the interface.

link|flag
Ditching filters from API would not really make me and foglyn users happy. It's very convenient to be able to see exactly same cases in web ui as well as via API. I have 5-6 saved filters which I track via foglyn and I know other people are using filters in this way too. Please keep it ;-) The only problem here is getting list of those cases without changing global filter for web interface. Thank you. – Peter Štibraný Nov 24 2009 at 21:55
1 
I would love to see an entire filter defined in the URL - ditch the idea of "current filter" altogether. Keep an interface to create and save a filter, but you should be able to copy and save the url and use it to repeat the results of that filter at a later date. The API should take at least the filter if not both formats as arguments. I feel the way current filter works now borders on a bug. The other day I used two preSaveFilterFixFor filters in the left panel to open two tabs in my Browser. I did a bulk edit on a group in the first one and "whoa!" I got the results of the second filter. – PJM Dec 1 2009 at 15:56
1 
I have case 1814324 open to deal with this issue. – Rich Armstrong Dec 1 2009 at 16:34
Any possibility of this getting fixed/implemented? (Best solution imho would be to introduce new API, e.g. add filter parameter to search command) – Peter Štibraný May 11 2011 at 14:40
Is there an update on the status of this issue? – UnnDunn Mar 8 at 20:53

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.