This will lead to the following structure:
I would very much like to be able to keep seeing the parent nodes, leaving this full branch of the tree intact. This way you never lose the structure of your treeview out of sight while filtering.
Open
Filter in treeviews without losing parent nodes
Let's say I want to apply a manual filter in the following treeview, so I can see all validations assigned to me.
This will lead to the following structure:
I would very much like to be able to keep seeing the parent nodes, leaving this full branch of the tree intact. This way you never lose the structure of your treeview out of sight while filtering.
This will lead to the following structure:
I would very much like to be able to keep seeing the parent nodes, leaving this full branch of the tree intact. This way you never lose the structure of your treeview out of sight while filtering.
- Warrior
This is an issue with all treeviews, whether in the SF or in your own application. Would be great if this could be solved in a generic fashion. Maybe with some sort of setting "keep structure intact on filter" or something like that
+14I most definitely support this idea. I usually solve this by using a hidden column, which contains the filter value of the parent node. However creating a more general feature which supports this, is a way better idea.
+5We've had a bit of a discussion about this request, I'd like to share this with you.
Adding all parent nodes, ignoring all filters was the starting point but it turns out to be a bit tricky.
First, the ignoring all filters-part. There are various ways to apply filters and for some it makes more sense than others.
Regular user filters
Quick-filters, filters in the filter screen, combined filters and excel-style filters can all be disabled without any problem.
Process flow filters
Process flows can apply filters. Should parent nodes be selected if they are not available within the filters applied by a process flow?
Prefilters
Do parent nodes show up outside of prefilters? Keep in mind there can be authorization prefilters active. Disabling these is not possible due to security constraints.
We could say that we only disable all prefilters that the user can toggle. However, mandatory exclusive prefilters are on the horizon. If we were to implement these, turning them all off might result in duplicate parent nodes.
UI detail filters
Details are filtered based on a parent record. Do parent nodes show up in the detail that are actually never supposed to be there?
UI look-up filters
Look-up pop-ups can be filtered based on other columns in the look-up reference. Do parent nodes show up in the look-up pop-up that are outside of these filters, that are not supposed to be selectable as a look-up value?
Then we got to the Adding all parent nodes-part.
We'll run into serious problems if these nodes will become selectable. They will allow the user to 'break out' the current context. For instance, you should never be able to copy one of these records in a detail where they are not supposed to show up, or choose them in a look-up pop-up where they are not supposed to show up.
The active record is always synchronized for all components. If these nodes are selectable, they will also need to show up in other components, such as the grid, a form or a map or even a cube or pivot grid. If the tree is not visible to the user, this might lead to some weird scenarios where you quick-filter in a grid, yet many records that do not match remain for no apparent reason. Switching to a different screen type without a tree will cause the extra records disappear again.
So far, it seems like it's a good idea to make this a visual feature of the tree. Show the parents in the tree, but do not add them to the data set as records. They will not be selectable and cannot be used in any way.
Visualizing all parent nodes in the tree ignoring some types of filters would be a good way to go.
This is significantly trickier to implement. The recursive algorithm to select the parent nodes is fairly straight-forward. However, we need to revisit some mechanisms that assume every node is represented as a record in the general data set, shared by all components. Some examples:
Still, the question remains exactly which filters are to be ignored. I'm curious to hear your input on this.
Adding all parent nodes, ignoring all filters was the starting point but it turns out to be a bit tricky.
First, the ignoring all filters-part. There are various ways to apply filters and for some it makes more sense than others.
Regular user filters
Quick-filters, filters in the filter screen, combined filters and excel-style filters can all be disabled without any problem.
Process flow filters
Process flows can apply filters. Should parent nodes be selected if they are not available within the filters applied by a process flow?
Prefilters
Do parent nodes show up outside of prefilters? Keep in mind there can be authorization prefilters active. Disabling these is not possible due to security constraints.
We could say that we only disable all prefilters that the user can toggle. However, mandatory exclusive prefilters are on the horizon. If we were to implement these, turning them all off might result in duplicate parent nodes.
UI detail filters
Details are filtered based on a parent record. Do parent nodes show up in the detail that are actually never supposed to be there?
UI look-up filters
Look-up pop-ups can be filtered based on other columns in the look-up reference. Do parent nodes show up in the look-up pop-up that are outside of these filters, that are not supposed to be selectable as a look-up value?
Then we got to the Adding all parent nodes-part.
We'll run into serious problems if these nodes will become selectable. They will allow the user to 'break out' the current context. For instance, you should never be able to copy one of these records in a detail where they are not supposed to show up, or choose them in a look-up pop-up where they are not supposed to show up.
The active record is always synchronized for all components. If these nodes are selectable, they will also need to show up in other components, such as the grid, a form or a map or even a cube or pivot grid. If the tree is not visible to the user, this might lead to some weird scenarios where you quick-filter in a grid, yet many records that do not match remain for no apparent reason. Switching to a different screen type without a tree will cause the extra records disappear again.
So far, it seems like it's a good idea to make this a visual feature of the tree. Show the parents in the tree, but do not add them to the data set as records. They will not be selectable and cannot be used in any way.
Visualizing all parent nodes in the tree ignoring some types of filters would be a good way to go.
This is significantly trickier to implement. The recursive algorithm to select the parent nodes is fairly straight-forward. However, we need to revisit some mechanisms that assume every node is represented as a record in the general data set, shared by all components. Some examples:
- Node activation, keyboard navigation
- Dynamic node loading (web)
- Loading data images
- Applying conditional layout
- Translating look-up values and domain elements
- Data refreshing
- Drag-drop
Still, the question remains exactly which filters are to be ignored. I'm curious to hear your input on this.
+9The following idea has been merged into this idea:
https://community.thinkwisesoftware.com/ideas/filter-in-process-analysis-treeview-without-losing-parent-nodes-845
All the votes have been transferred into this idea.
All the votes have been transferred into this idea.
+12On the backlog→Open
+12Status updated to better reflect the Status of the Idea with the clarified Statuses as explained in the Reply here: What happens to your ideas? (updated as per november 2024) | Thinkwise Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.