Control access for user based on enum value

Hi,

I wanna ask you a question about modeling access right for users. In my application, one user can be for one project manager (see project, full rights to edit project) or employee (see project, cannot edit project). How to model this situation? I wanna achieve situation when user see list of project (both where he is manager or employee) and when he selects one project, as manager he can edit it (edit button -> edit screen -> change value -> ok) but as employee he can only view it (view button -> edit screen read-only -> ok).

1 Like

should be possible to set the editable propertie of the components in the edit screen to “false”, via overriding the init method in the controller. there you can implement the logic you want, checking enum with user or something like that.
shouldn’t be that hard. maybe someone has a better idea

Daniel

Yeah, that is possible, but I was looking for another way to do it than manual way. I have more graphical components related to user-project relationship, so manual approach is not the best idea. Using access groups I should be able to achieve state when user cannot edit not managed project, but only at the time he click save button on edit screen for project. I prefer the different approach not to allow him to click/edit/see data he should not see.

You can use security constraints with Operation Type = Update. In the example below, the constraint enables updating only customers with email equals to email of the current user:
CUBA Application 2018-02-02 17-57-01

Immediately after adding such constraint, it will be checked on middleware and throw AccessDeniedException if the user has no right to update the instance.
In order to disable the OK button in editors, write the following in the controller:

package com.company.sales.web.customer;

import com.company.sales.entity.Customer;
import com.haulmont.cuba.core.global.Security;
import com.haulmont.cuba.gui.components.AbstractEditor;
import com.haulmont.cuba.gui.components.Action;
import com.haulmont.cuba.security.entity.ConstraintOperationType;

import javax.inject.Inject;

public class CustomerEdit extends AbstractEditor<Customer> {

    @Inject
    private Security security;

    @Override
    protected void postInit() {
        setupSaveAction(getAction(Editor.WINDOW_COMMIT));
        setupSaveAction(getAction(Editor.WINDOW_COMMIT_AND_CLOSE));
    }

    private void setupSaveAction(Action action) {
        if (action != null && !security.isPermitted(getItem(), ConstraintOperationType.UPDATE))
            action.setEnabled(false);
    }
}

Here in security.isPermitted() method we check the constraint by running the constraint script on the client tier outside of a transaction, so be sure all entity attributes used in the script are loaded (included in a view).

2 Likes

Thank you Konstantin, this is exactly what I was looking for. Really good job with creating CUBA Platform and with your support. Have a nice day!

1 Like