Cannot hide tab on accordeon through roles

Hi,

I have created a sidemenu for the main screen that holds basically an accordeon with tabs and buttons to access various parts of the application. It replaces the built-in main menu from cuba.

One part of this accordeon holds access to setup and configuration items. Obviously, I do not want all users to access this part of the menu. I thought I would hide this tab through the Roles > UI option but am not able to do so.

Below (and attached) is a test project that isolates the menu part with a setup tab to be hidden to users depending on their role.


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<window xmlns="http://schemas.haulmont.com/cuba/window.xsd"
        caption="msg://caption"
        class="com.company.test.web.screens.Screen"
        messagesPack="com.company.test.web.screens">
    <dialogMode height="600"
                width="800"/>
    <layout>
        <accordion id="accTest"
                   width="100%">
            <tab id="tab1"
                 caption="Tab 1">
                <button id="butTab1"
                        caption="Do something"/>
            </tab>
            <tab id="tab2"
                 caption="Tab 2">
                <button id="butTab2"
                        caption="Do something too"/>
            </tab>
            <tab id="tabSetup"
                 caption="Setup">
                <button id="butSetup"
                        caption="Setup something"/>
            </tab>
        </accordion>
    </layout>
</window>

When configuring to hide the tab, I have tried these role>UI configurations and assigned them to a test user:


[*] screen:
       tabSetup                      -> hide
       accTest[tabSetup]    -> hide
       accTest.tabSetup      -> hide

All without success.

Actually, when using the tabSetup only (or the full path), there was some odd behavior in which the tab (tabSetup) was shown normally but when clicked, it didn’t open and it rather made the content of the tab that was already open to disappear.

Is this a bug or am I doing this the wrong way? any help appreciated.

test.zip (224.6K)

Hi,

Which version of the platform do you use? Does the user have multiple roles?

In my test project on 6.3.4:

  1. I have created an empty screen and added an accordion with tabs and buttons (as you described above).
  2. I have created a new role and adjusted to hide the “tabSetup” component via the administration UI (see the attached screenshot).
  3. After that, I have created a new user and assigned the role to him.

As a result, after the user logs in he sees all the tabs on the accordion layout, but click on the denied one leads to nothing (it is not expanded).

tabSetup

Hi Rostislav,

It’s exactly the same as I did and for the user the effect of clicking the tab SEEMED to be nothing. However, buttons that were located on the tab that was open when clicking the tabSetup suddenly disappeared!

I think this is not intended behavior, is it? I would have expected that the tab itself was hidden rather than the effect of clicking it does nothing. And moreover - this seems to be a bug - nothing should disappear elsewhere.

Maybe you can verify this behavior as well?

I’m on studio 6.3.4 and the user that was used only has one role, exactly as you’ve shown in the screenshot.

Hi,

At first, let me explain how tabs and fields could be hidden when they are part of a tabSheet or a filedGroup.
It should be done by setting up ‘composite’ UI permissions. This means, that instead of specifying ID of the tab, you should specify the ‘path’ to it as “tabSheetID[tabID]”(see the attached screenshot). If to hide the component in such way the tab(or field) will not be shown.

Unfortunately, this behavior has not been implemented for the “Accordion” component yet, but it should. We have created a YouTrack issue, see the link on the right.

The second I should say is: usage of UI permissions is recommended only in production. When the user access could not be restricted by other means.

In your case, you can hide the tab on accordion as follows:

  1. Create a specific permission. It should be registered in the permissions.xml (web-permissions.xml) configuration file.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<permission-config xmlns="http://schemas.haulmont.com/cuba/permissions.xsd">
    <specific>
        <category id="app">
            <permission id="app.showSetup"></permission>
        </category>
</specific>
</permission-config>
  1. In the screen controller, add the code which will check specific permission and hide the tab if it is not permitted.

public class Screen extends AbstractWindow {
    @Inject
    private Security security;

    @Inject
    private Accordion accTest;

    @Override
    public void init(Map<String, Object> params) {

        if (!security.isSpecificPermitted("app.showSetup")) {
            accTest.getTab("tabSetup").setVisible(false);
            super.init(params);
        }
    }
}

Here the tab is ‘completely’ hidden by calling the accTest.getTab(“tabSetup”).setVisible(false).

If to call accTest.getComponent(“tabSetup”).setVisible(false), the result will be similar to described in my previous comment (the tab will be visible but will not show its contents).

Regards.

tabsheet

1 Like

Hi Rostislav,

I considered doing the coding approach but was actually hoping to avoid it as it makes the roles/permissions more hard-coded and thus less flexible and probably requires more maintenance.

Since I wanted a side menu, instead of the main menu bar on top, I’m “forced” to use the UI permission/coding approach rather than doing the preferred permission configuration.

By the way, I tried the accTest[tabSetup] configuration but it didn’t work as it turns out. Glad this is being picked up.

Did you see the odd behavior on the disappearing buttons on the other tabs when clicking the tabSetup? That still seems to be an issue I think.

I will try to setup things as suggested - thanks for your input!

Hi,

Let me announce that since version 6.3.6 visibility of accordion tabs could be adjusted by UI permissions.

Works perfectly - thanks. Very happy with it.

:ticket: See the following issue in our bug tracker:

https://youtrack.cuba-platform.com/issue/PL-8342