I like the idea, but think that your simple test data doesn’t highlight some significant limitations that would likely confuse users once they try to use it in practice with their more complicated models.
Undocumented Limitation:
There is a confusing and undocumented limitation around what Smart Folders and Hierarchical Lists support. They seem to only support top-down traversal, where the nested types that can be displayed must have a many-to-one relationship
You may look at your example and say, why would this matter? Let’s say that you want to have a nested view like this, but instead of following the happy case in the example, you want this hierarchy:
Project → Issue Type → Issue
If you setup your Issue Types to be a Type, then there is a many to many relationship between Project and Issue Type. This is not supported, isn’t documented, isn’t communicated in context, and I think should be supported. The only work-around would be to create a unique Issue Type for each Project and actual Issue Type. There might be more workarounds with absolute freedom and toy data, but you don’t have as much freedom with the Integration (like the JIRA one).
This is related to the issues I’ve run into with the JIRA integration and Smart Folders/Context Views.
My Suggestion
- Document the Limitation and plans (if any) to remove that limitation (for this feature and smart folders hierarchy)
- Provide contextual feedback where limitations exist instead of just hiding fields
- (hopefully) Remove the limitation