x
└── y
└── z
├── a
├── b
├── c
├── d
├── e
└── ...
We recently noticed that our users have create rights to apps a, b and e and only right access to apps c and d. We were expecting our users to have create rights to all the apps and are surprised that this is not the case since there’s not much difference in the code.
All our users are in the “Full Access” user group.
The only difference I noticed was that the “faulty” apps didn’t have integration tests. So I wrote them and pushed but it didn’t change anything.
I also think that the “faulty” apps were published after implementing SSO for our environment. So it might be the reason but I don’t know how to fix the problem.
The issue doesn’t concern administrators, which is not convenient for testing, by the way.
Do you have any idea of what’s going on and how we can fix the problem ?
Hi Pierre, thanks for reaching out, i understand that this is a bit unexpected.
Some starting questions / remarks:
are letter a, b, c, d, e all different EntityTypes within a single tree-type app?
have apps c and e been added in later versions of the application? im hypothesizing that we add all new entitytypes as “only read” to the usergroups to not accidentaly give groups to much permissions.
If you visit Administrator > UserGroups > actions menu > Edit object type permissions for each Usergroup. This will show you the access rights and you can alter them if they don’t have the settings you want
Thank you ! Thanks to your answer I was able to fix the issue !
have apps c and e been added in later versions of the application? im hypothesizing that we add all new entitytypes as “only read” to the usergroups to not accidentaly give groups to much permissions.
They were all added with SDK 14.6.1, if I get what you’re asking.
If you visit Administrator > UserGroups > actions menu > Edit object type permissions for each Usergroup. This will show you the access rights and you can alter them if this is not want to want
Should I understand that we will have to do this manipulation each time we add a new app ? Because we always want that (all) our users “Can use” (all) our apps.
They were all added with SDK 14.6.1, if I get what you’re asking.
No that’s not want i meant. I meant a new version of the app (a new publish)
Should I understand that we will have to do this manipulation each time we add a new app ? Because we always want that (all) our users “Can use” (all) our apps.
Yes you would have to do this for every entitytype you add
Can you explain why you choose to add “apps” as entitytypes instead of creating new apps / workspaces?
It’s truly one app, and we add new, independant features regularly along the line. All those features are based on our same python packages, so it wouldn’t make sense to isolate them in different workspaces. Plus, refering to the schema in the first post, a z entity can contain several types of the entities from a to e. So, to answer your question, they were added in different versions of the app.
Our main maintainer on the Viktor side is on vacation this week so I cannot confirm with him but I guess he was editing the usergroup permissions without the rest of us being aware.
Note: ‘sub-application’ is used to refer to a feature pertaining to a specific entity type in this post.
I would add that the sub-applications while independant might be related to the calculations of the same ‘physical world object’. The users have the options to use a bunch of these sub-applications together and label them accordingly.
So if we have 20 ‘sub-applications’ ; any of the 2 could in theory be used in parallel for one bigger calculation (in this example you would have 2 separate calculations and 2 separate files that the user will bring together).
Although the standard case would be that each sub-application is sufficient on its own.
Our software is built on a tree-based app structure. We had a discussion with VIKTOR when we started, and it was this structure that fits our needs. Prior to the introduction of the “Project” level in the VIKTOR UI (April 2025), we had a single workspace with “Project” as the first level, followed by two levels, and thenour calculation apps (EntityTypes). This was the only structure that met our internal standards and kept the UI usable. The best compromise I would say.
@Leonard_Bonnet Following up: Each time we add an app, manual configuration is required before users can create or manage one. This is no good for adoption of the new features we deliver. Prior to the April 2025 “Project” UI change, we only had to perform this setup once (see procedure above); now it must be repeated for every project, which is inefficient. Plus it is increasing over time.
Although we emailed the procedure to end users, we have no pleasure to verify whether they followed it or not or will remember it later. When items appear greyed out, users may assume the feature is still in beta.