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.
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.
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.
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:
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).
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!