I wonder if it’s possible to check if a user is allowed to open a window before opening it.
Like that, we could disable or even hide buttons that would other wise navigate to an inaccessible screen, without having to give the user that annoying error popup.
Just defining the rights twice is no option, as our navigation bar is multi-layered, so the same button can open different screens depending on what section is selected in the layer above.
If you use Roles to control access you can put a call to system.security.getRoles on the enable or visible of the buttons.
Our navigation is database driven and it checks the users roles before it even shows any buttons.
That way I can indeed get the roles of the current user, but I still can’t check if the user will have permission to open a certain window. I can’t seem to get get the roles that are allowed to open a window.
Or do you mean not using the built-in security settings on the windows, and instead keep them in a separate dataset/sql table/struct?
The default security settings seems easier to maintain to me, and has no possibility to make typos in role names.
Yeah sorry, the builtin security stuff that you are using was too rigid for what we needed.
We do use the builtin roles but we then have our own internal security levels that are controlled by database queries.
In one of my projects I wanted to hide/show navigation buttons depending on the user’s role[s], but with the ‘default’ navigation [Tab Strip] component that seemed to be not possible. So I ended up creating my own navigation bar with a Template Repeater where each button has a set of allowed roles; that way I can hide buttons that shouldn’t be displayed, and display the ones for their role.
For thecesrom:
We’re modifying the ignition navbar depending on roles fetched in a db here.
Basically, we only have one tab in the navbar at the beginning : the only one that is common to everyone.
After that, we duplicate that tab, change what we need in it and in the end re-affect this new dataset to the navbar dataset
The code looks like this :
tab_data = event.source.rootContainer.getComponent('Tab Strip').tabData # Retrieve current navbar dataset
new_tab_h = [] # Future navbar headers dataset
new_tab_d = [] # Future navbar lines dataset
tab_ligne = [] # Temporary line that will be duplicated as much as needed
for col in range(tab_data.columnCount):
new_tab_h.append(tab_data.getColumnName(col)) # Populating the header
if col > 1:
tab_ligne.append(tab_data.getValueAt(0, col)) # Populating the temp line but omitting the first 2 columns (NAME and DISPLAY_NAME) because these are the ones we change on the fly
*Magic with your roles. Basically, we loop through the windows allowed, we append the temporary line and push that to the navbar. Something like :
tab_l = tab_ligne[:] # Duplication
tab_l[:0] = [name, display_name] # Name and Display name variables created earlier in the *magic* section
new_tab_d.append(tab_l) # Append to the future dataset
event.source.rootContainer.getComponent('Tab Strip').tabData = system.dataset.toDataSet(new_tab_h, new_tab_d) # Push
We also use buttons for navigation, but in a tree-like structure. So the top row defines the section, the row below a subsection, and the third row actual pages.
So the security has to be on the third row, but whether it has to be enabled depends on the actual page. That’s configured for it.
Pages however can also be accessed by other buttons on different pages (to follow the product flow more easily).
That’s why it needs to depend on the actual page, and not on the button instance.
Anyone have any insight on why I am unable to get this script to hide the first tab strip when used on a visionWindowOpen event handler if the user has a matching role from the if statement? I can get it to work when the script is placed on an action performed event of a button component within the window.
As noted above, that event fires before bindings are evaluated, which is on component startup. You can’t reliably access components before they start up. You’ll have to pick an event later in the window life cycle.