You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently on master, while adding a block to a config, you can select a group which is derived from a component that is currently in the config you are adding the block to. This does not work, and should not work, but instead adds the block to the "other" group as the component is effectively read-only when changing a configuration.
Instead of the block defaulting to the "other" group, we should not allow trying to add it to a "read-only" component anyway when adding to a config.
This is not hugely important as the block is at least not lost, but it could cause frustration.
Acceptance criteria
Groups are greyed out or not present if there aren't any that are "writable"
How to Test
verbose instructions for reviewer to test changes
(Add before making a PR)
The text was updated successfully, but these errors were encountered:
Where?
Currently on master, while adding a block to a config, you can select a group which is derived from a component that is currently in the config you are adding the block to. This does not work, and should not work, but instead adds the block to the "other" group as the component is effectively read-only when changing a configuration.
Instead of the block defaulting to the "other" group, we should not allow trying to add it to a "read-only" component anyway when adding to a config.
This is not hugely important as the block is at least not lost, but it could cause frustration.
Acceptance criteria
How to Test
verbose instructions for reviewer to test changes
(Add before making a PR)
The text was updated successfully, but these errors were encountered: