## Issues with current API:
Based on the feedback in the related tickets PITA is that public "disabled" option blocks the ability to expand disabled items.

## Best description of what customers want is in the following quote:

>If the admin user has access to View Event Setup, but not to Create Event Setup, then "Create" needs to be disabled and the checkbox needs to be selected/deselected based on whether the user their configuring already has Create access.
Given our scenario, the behaviour I would expect would be that when the parent "Event Setup" is selected, then all child nodes are selected, except those that are disabled. If that means that not all child nodes are selected then the parent remains in the "intermediate" state. If you select the parent again, then all child nodes are de-selected, except those that are disabled. Again, if that means that not all child nodes are unselected then the parent remains in the "intermediate" state.

## Main goals:

- Possibility to disable items, e.g. a data field that defines if item is disabled
- Disabled items are expandable
- Disabled items are not react on user's interaction via click
- Recursive selection. E.g. when a user check \ uncheck an item, its children nodes are checked \ unchecked accordingly.
- Disabled items do not change during the recursive selection
- Support mixed state. E.g. each CheckBox might be checked, unchecked, mixed (if it have children in both states)
- When an item changes state, its parent changes state accordingly. This works for disabled items aswell. I.e. disabled item might became checked if all its items are checked

## What I found:

- Default SelectAll feature is not working in the required way. You need to implement custom SelectAll button.
- It is difficult to use a custom item template with checkbox, because... The template is drawn inside the item's content, which is on the same level as the default checkbox element, i.e. You won't be able to use default styles.
- You cannot use built-in recursive selection. Events are triggered only on a clicked item. The rest of the recursive selections are processed under the hood. There is no way to track it with the public API.
- If you set non-recursive selection and try to select recursively manually, everything seems to work ([code pen](https://codepen.io/justsold1er/pen/dyQaMbr?editors=0010))
- Difficulties arise with mixed status and update of parent node when children changes status. If you try to select/deselect via selectItem \ unselectItem, there are too many recursive calls (performance issues + infinite loops). All attempts to circumvent it, resulted in too cumbersome solutions. If you try to take checkboxes and rewrite their handlers, the built-in selection handlers break the behavior.

## Summary

Meanwhile we can share a partial solution: [code pen](https://codepen.io/justsold1er/pen/dyQaMbr?editors=0010)

We can try research the task further (maybe I am just silly)

In my opinion if we plan to support this usage scenario it is more smooth to handle this as a new feature. Alternatively we can add an event like "onItemSelectionChanging" and allow to cancel this event.