enhancement
major
minor
defect
critical
major
minor
minor
#30258
React-UI: The only way to display tabs for a single type is by using a type deviation in `access-control`, and that is logged as a WARN.
Background
A tab is often associated only with certain objects in the selection. Example: In the status report of a project tree, the “Maturity Level” tab appears only for the project, not for subprojects or work packages. The “Attachments” and “Sheets” tabs are only available in projects, not in templates. When the selection changes, the tab should appear or disappear.
Problem
A <tab> has no visibility condition. The only way to hide it depending on the object is to use <access-control> with a type:
<access-control inputs="element" object="$element" operation="Read" type="prime:Project"/>
- This works: If the object is not a `prime:Project`, the check returns “No access,” and with ` denied="hide" `, the tab disappears.
- However, the documentation refers to this case as a type mismatch, which is logged. Every time the selection changes to a subproject, it generates a WARN line—often two:
WARN OperationCheck - Access to 'AttributedWrapper(type:prime:Subproject, id: GenericObject:3628, name: Implementation)' denied: it is not an instance of the type 'prime:Project' declared by an 'access-control' checking the operation 'Read'.
- During normal operation, the log fills up with warnings that do not indicate an error.
- The alternative ` object = null ` for other types does not help: In that case, the tab is considered “Empty” and remains visible, but without content.
Version: 8.0.0-alpha12, React-View-Layer (tl-layout-view, OperationCheck, UnitAccess).
Reproduction
- In a view with a tree and tabs, add an <access-control inputs="element" object="$element" operation="Read" type="<Type A>"/> element to a tab.
- Select an object of type A in the tree: The tab appears.
- Select an object of a different type: The tab disappears as expected. The WARN line appears at the top of the log.
Example from an application (Prime): status-report.view.xml, “Maturity Level” tab (only in projects) as well as “Attachments” and “Sheets” (only in projects, not in templates; the root of the structure is checked).
Solution
Every unit that can contain an <access-control> (tab, accordion section, tile, navigation entry, navigation group, and sidebar navigation section) is assigned a <visibility> condition via its own inputs:
<tab id="maturity"> <visibility inputs="element" expr="$element.instanceOf(`prime:Project`)"/> ... </tab>
- If the expression does not return a true value as defined by TL-Script (null, false, empty list, empty text), the unit is hidden within its container (tab bar, accordion, dashboard, sidebar); if an input or an object containing an input changes, the condition is re-evaluated. The condition for a group or section of the sidebar applies to all entries within it.
- The condition is not a permission check and does not generate a log entry. As long as it is not met, any additional <access-control> elements for the unit are not evaluated, not even those within the content of a tab or navigation entry that is still open.
- The name <visible-if> (like the rule of the same name applied to commands) cannot be used on tabs, since <visible-if> is already a content element there.
- The type mismatch in <access-control> remains a WARN message: it indicates a configuration error. The message now specifies the workaround (<visibility> on a unit, the <visible-if> rule in a command’s executability ), as do the documentation for access-control/@type and the article view-layer/access-control.
- Demo: tl-demo-react, Demos → Tree Demo: The “Tickets” tab in the details area appears only when a milestone is selected.
Migration
An <access-control> whose `type` is used solely to hide a unit from objects of other types is replaced by <visibility inputs="..." expr="$x.instanceOf(`<Type>`)"/> (or supplemented if a permission check is also desired; in that case, its `type` is a type shared by all checked objects).