search

jmix-framework / jmix

Jmix framework
https://www.jmix.io
Apache License 2.0
488 stars 112 forks source link

UI component constraints #472

Open andreysubbotin opened 3 years ago

andreysubbotin commented 3 years ago

Like CUBA screen component permissions.

alexbudarov commented 3 years ago

For now decided we don't want them (they are out of deny-by-default concept).

fredbar commented 2 years ago

That is pretty unfortunate, imho. To circumvent, this forces to add ugly tests everywhere based on role parsing OR duplicate pages and trick with fragments OR duplicate pages and end up with a maintenance nightmare. None of this has the elegance of the previous permission system.

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. I was pretty happy of working in jmix compared to cuba, until now. I seriously think about going back just for this feature.

umeshhodwala commented 1 year ago

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

mfpedrotti commented 1 year ago

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.