Revisit 'unselectable' flag (in multy-hier mode)

[logicz]

When I use unselectable flag for a node I suppose it shouldn't be ever selected, but it's selected with selection of parent node.
It's usefull when I attach some tree-organized entities to different records, but I want to disallow selection for entityes attached to another records.
Is it possible to add a new multiselect mode for this purpose?

[mar10]

This behavior is a bit complicated and not yet finally specified:

https://github.com/mar10/fancytree/wiki/SpecSelect

(I modified the issue title to reflect this) Comments welcome.

[olexp]

This issue is the same as #305 in dynatree (https://code.google.com/p/dynatree/issues/detail?id=305). It was not resolved there. Hope it will be resolved in fancytree.
My vision of behavior is as following:

1. Unselectable nodes should not be selected in any way (user click or API)
2. Parent nodes with at lest one unselectable child should be marked as partsel (parents' keys in that case are not selected as well).
   If the behavior described in 2. is not acceptable as default then I'd like to have it configurable with options.

Fig 1. Clicking on top level node selects all children including unselectable child. Incorrect.

Fig 2. Selecting all child nodes except unselectable makes all parent nodes fully selected. Probably incorrect for most cases.

If all nodes collapsed user don't know if there are any unselectable items and could wrongly think that all child nodes are selected (despite there are some problems with nodes that can't be selected).

[mar10]

Thanks for contributing! Maybe you can add a concrete use-case / story for this expectation?

One usecase might be: We want to insert a dummy node that acts as a sub-title. So we set 'uselectable' and 'checkbox: false'.

Another usecase might be: We have a tree of options, that a user can edit, but some of them are readonly (some forced to selected, some unselected). The user would like to easily set or reset all editable settings, for example by clicking the parent checkbox.

I agree that it is not consistent yet, but some decisions that I am not sure about:

• 'unselectable' could mean 'can never be selected' or 'can never be (de)selected by user interaction'.
• A selected parent could mean 'all children selected' or 'all children that a user can select are selected'
• How should we handle a node that is 'unselectable' but has the selected flag set in the source data?

[olexp]

Sorry for late reply.
The scenario I'd like to be supported looks as following.
There is a tree of tools and their builds grouped by major and minor versions to easily work with:
tool1
--1.0
----1.0.430
----1.0.433
----1.0.457
--1.1
----1.1.431
----1.1.460
----1.1.462
tool2
--1.2
----1.2.230
----1.2.245
----1.2.260
The tree used to mark some builds for archiving. Some builds are dependencies for other builds, some builds could not be archived due to other reasons. Those builds marked as 'unselectabe' to prevent archiving and removing from the storage where they can be accessed. Unselectable nodes have different styling to help user to easily detect such nodes and make decision what to do with them. But due to big amount of tools and builds they are collapsed on release level (1.0, 1.1, 1.2). In such a case user does not know if any of release node has some unselectable child nodes. Clicking on release node or tool node user selects all child nodes (that brakes dependencies, etc.) and he is not notified that there are some problems with nodes on third level (partsel checkbox could be a help here).
So in reply to your questions I would say:

• 'unselectable' means 'can never be selected'
• a selected parent means 'all children that a user can select are selected'

But the last question is not that easy to answer. Especially after you examples I realized that there are some cases when it's possible to have node selected but also have uselectable option set to prevent user interaction. But still, user should not be able to drop the selected flag on node by deselecting parent node (like it is in current version of fancytree).
And for me 'unselectable' is node that can't have 'selected' flag set (and checkbox selected) in any case. So setting 'unselectable' and 'selected' on source level is probably programming error.

[joergwork]

Hi mar10,
first of all I like to say 'big thanks' for fancytree. It's fast and handy.

I think the wording 'unselectable' is a litte bit missleading ....
and there is big need for a second option like 'unchangeable' or even better 'disabled'.

The 'unselectables', like they work now, are for those cases where e.g. 'dummy nodes' are needed. So they should never be selected.

Hiding 'disabled' nodes is not an option, because it looks ugly and forces misunderstanding to the user. Fading them would be better, imho.

The 'disabled' nodes belong to the user action and have effect on the 'is selected' state.
Like olexp said, but for the new 'disabled' option:

• 'disabled' means it should never be changed
• a 'select parent' action changes all but not 'disabled' to selected,
• a 'unselect parent' action changes all but not 'disabled' to unselected
• the parent node is always in 'partly selected' mode,
  • if all children are selected, except one of the 'disabled'
  • if all children are not selected, except one of the 'disabled'
  • in that case, the user has to expand the children to see the changes. (or maybe fancytree should expand them)

What do you think about that? . (Apart from being a major change.) That might also go hand in hand with #327 ;)

And as always 'never trust what you get from a javascript', one - I'd say - must anyway implement some fancy server logic.
When using lazy-loading, the tree can never send all child-nodes to the server, so therfore server logic is needed too. - Apart from that, I use the 'get only the selected root nodes' function and thus the behaviour 'if all but unselectable nodes lead to a selected parent' logic forces me to be more fancy in my server scripts.

[allenfantasy]

Hi mar10,

First of all thanks for creating fancytree, which is a really awesome plugin.

Problem and Use case

I would like to ask that whether this issue going to be solved? Here's my use case:

1. We build a tree-like table to let admin user to control the permissions of all users in our website.
2. Some permission items should be disabled, which means they never change, no matter of what status of their parents would be.
3. These "disabled" items are always leaf node.

But when I implement the tree table I found that in selectMode 3 (multi-hier) when I change the status of one parent node, the disabled node are also changed, which is not the expected behavior.

Solutions?

I have read the specSelect and noticed there's one sentence:

(De)Selecting a parent should never change unselectable subnodes.
(But it is possible to implement simple custom select handlers to overide this using the API)

So I would like to know if there's any solutions to get around with this - or should we made some code patch so let it behave as expected?

Thank you again for fancytree and I would be really appreciated to get some response.

Regards,
Allen

[mar10]

I am closing this in favor of a general refactoring: #626

but some thoughts:

I think the wording 'unselectable' is a litte bit missleading .... and there is big need for a second option like 'unchangeable' or even better 'disabled'.

Yes 'unselectable' is misleading, but 'disabled' as well IMO, because I would assume that such a node cannot be made active, i.e. cannot be clicked on.

But when I implement the tree table I found that in selectMode 3 (multi-hier) when I change the status of one parent node, the disabled node are also changed, which is not the expected behavior.

Haven't tested, but the behavior should be consistent with plain trees. This would be a bug and should be reported separately