doing list --state: add option for active

[operte]

Right now the only options are open, closed and all. at least having active would be useful.

[operte]

This is a trickier problem than I first expected.

Turns out that work items have a state and states have a state category.
States are controlled by the user and they can have any name. Right now we check for state, which might not be compatible with teams that have non-default state names.

State categories are not alterable by the user. However, they are linked to the type of process that the project uses. azDo supports 4 projects: Basic, Agile, Scrum and CMMI. These have different state categories:

• Basic and CMMI: Proposed, In Progress and Completed
• Agile and Scrum: Proposed, In Progress, Completed, Removed

See https://medium.com/objectsharp/work-item-states-in-azure-devops-7f355918bc08

We could start checking state category instead of state. However, the user sees state in the web boards, and not the state category, so there would be no direct link between the two.

I don't think we can directly get the state category of the state of a work item.
There is a command to get all states that a board has, including their categories: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work-item-type-states/list?view=azure-devops-rest-5.0#definitions
We could run this command while doing init and store the categories in the config file. These can then be used to filter work items. It would also be clear to the user what the categories mean.

[timvink]

Yeah storing the info in config would be nice. We have some states hard-coded right now (like which ones are 'active').

We should have some defaults when they are not specified in the config (for backward compatibility and for users that start without using the doing init command). Or an error specifying how & what to add to the config.

The question is how useful is this compared to the engineering effort. Good to consider alternatives; maybe to allow AND OR operators for filters. Then you could write a command to filter on issues with states you consider as 'active', and define an alias for it (or add it to your projects Makefile, like make show_active_issues).

[operte]

Hey Tim! :D

Good point on the engineering effort. This looks like a lot of work for something I don't see a great benefit to in the short term.
And I agree with the solution. I think the minimum we can do is allow the user to pass an arbitrary state to --state, but still keep our defaults. I'll pick this up sometime soon.

[timvink]

I had a look at the github cli for gh issue list (link).

-S, --search <query>
Search issues with query
-s, --state <string>
Filter by state: {open|closed|all}

Maybe instead of allowing passing custom states to --state, we could implement --search. Devops also has a kind of query language, see here

[operte]

For this issue I'm planning to do the following:

• add state as a column to doing list. This column could be made optional, since doing list is getting quite wide. add option to list to show column with state #102
• keep the custom options for state open, closed, and all
• add the option to create new custom states on the config file. For simplicity, the custom states should be lists of states that the work item should be IN (as opposed to NOT IN). Add option to specify custom states when listing #99
• add the option to specify an arbitrary state. That state should be within quotes. E.g. I could do doing list --state "'Active'". The quotes would differentiate between the default doing-cli options and the custom ones. Add option to specify custom states when listing #99
• add the option of passing arbitrary conditions to the search query, using wiql. add the option of passing arbitrary conditions to the search query, using wiql. #103

I'll split this into different PRs.