-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tree widget: Incorrect category used for element visibility in filtered tree #1100
Comments
One of the easiest solutions to this would be to start showing categories for child elements. That way, we'd have the category node in filtering path and could use it for determining display status. It would also remove the confusion described in this issue: #1018. @vermanas @jjbeckman13 @jason-crow, I'm interested in hearing your thoughts. |
That approach seems reasonable to me |
I think we could even show/hide the category based on whether it matches parent node's category - this would avoid making the hierarchy deeper in majority of cases, e.g. this situation:
When the categories match, we'd see this:
When the categories don't match, we'd see this:
I could see a couple points of possible confusion, though:
|
A note regarding the proposed solution. If we create the intermediate category node as an instance node, we'd have to way to control its visibility, as it would only have to affect elements under that specific node and not the others. A solution could be creating a |
There might be cases where incorrect category is used when determining or changing element visibility in filtered tree. For example ,if we have tree like:
Filter path to Element B will be:
Subject -> Model -> Category A -> Element A -> Element B
At the moment when we try to determine/change visibility of
Element B
we go up in filter path and look for category. In this particular example we will findCategory A
and use it. However,Element B
is inCategory B
and it should be used instead in all visibility operations.Need a way to find real element category instead of the one that is shown in tree as an ancestor.
The text was updated successfully, but these errors were encountered: