-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI component constraints #472
Comments
For now decided we don't want them (they are out of deny-by-default concept). |
That is pretty unfortunate, imho. However, nothing forbids you from implementing it as a deny-by-default system. "Just" add tools to ease user task of deep-enabling, or add permission/role based fields to components so that can be set in xml and controller. |
This is very much required and i was using it frequently. without this jmix just become LOB app tool for self projects. I make apps in cuba/jmix and host them for clients. All clients have different requirements for roles and permission available to them. With cuba it was very easy as each resource cant be enabled/disabled/hide based on role. In jmix it is impossible unless i develop application separately for my clients. On one of my projects (already in production) i have more than 200 such permutation & combination with roles. How can i implement this in code and what happens when some client ask for a new role (I re-code and re-build) the system? The security model atleat as in cuba is must. for positive consideration |
I apologize if the google translation doesn't help much, but I'll comment. As simple as it may be, there are a number of actions outside the normal include, change, and delete pattern. a tool like Jmix where the objective is to be agile and fast, but the same mechanics are not seen in this part, I understand why it is not simple to elaborate something, but having the resource, which is more agile and simple for the developer is very important as others have commented above, there are many places to validate yourself. But before that, I still think that the screen for configuring permissions could be more intelligent, for example, allowing editing whether the actions will be allowed or not, or copying a profile and changing it, excluding unwanted actions, but I see that the user would be too extensive, not being practical for the day-to-day user. It would be of great value, at the very least, to evaluate it again and maybe think of something that could speed up and facilitate, for everyone, developer and end user. |
Like CUBA screen component permissions.
The text was updated successfully, but these errors were encountered: