Is it possible to have an entity based on a view that inherits record permissions from another entity?
Is it possible to create an entity based on a view (so with the "Represents Structure of Database View" checkbox checked, and with the view created using a SQL script) that inherits its record permissions from a "real" entity? I tried to do so by simply checking the record permissions checkbox and specifying the parent object in the "Object to inherit access permissions from" field of the entity, but this doesn't seem to work.
My setup is that we have the OOTB Leads entity, and then I've created a view over the top of it taking all columns but with a filter condition, to be used for reporting over Leads while filtering out certain Leads that should never be included in reporting so we have a more consistent reporting basis and don't have to make sure to include those filters in every widget. I added 2 columns to the view based on the Id and LeadName columns called UsrBaseLeadId and UsrBaseLeadName, which then have a lookup column UsrBaseLead added over them in the view-based entity. This lookup is then used as the "Object to inherit access permissions from" for the view-based entity.
There aren't any errors thrown in the logs when trying to do this, but non-super-users just can't see any of the records. When I tried to check a record in the view's permissions, I could see that the SysRights table for the view entity doesn't exist, so I tried creating that rights "table" as a view in the database that took its data from the Rights Table of the real entity, but while that seemed to work inasmuch as I could check a record's access rights and see that the correct rights were there and was even able to modify those rights, it didn't make it visible to a non-super-user.
Like
It would be great to have the view be able to inherit permissions from some object that the view has as a lookup column. However, I don't believe that is possible. What I typically do is this:
- Create a view and include as a column some other object that has permissions (for example, if the view includes an Opportunity lookup column and the account has permissions)
- Anywhere the view is used, include a filter condition that some column on that related object is not null (that would never be null). Plus it cannot be the Id or the column used as the display value. Example, if my view has a lookup for Opportunity, I could use Opportunity.Stage is filled in.
- Using this approach, the user will only see the rows corresponding to the related record that they have access to, since if they cannot view the related opp the Stage will return a null value.
It's not ideal and definitely not secure, but it does limit the view rows to what the user can see on the related object.
Ryan
It would be great to have the view be able to inherit permissions from some object that the view has as a lookup column. However, I don't believe that is possible. What I typically do is this:
- Create a view and include as a column some other object that has permissions (for example, if the view includes an Opportunity lookup column and the account has permissions)
- Anywhere the view is used, include a filter condition that some column on that related object is not null (that would never be null). Plus it cannot be the Id or the column used as the display value. Example, if my view has a lookup for Opportunity, I could use Opportunity.Stage is filled in.
- Using this approach, the user will only see the rows corresponding to the related record that they have access to, since if they cannot view the related opp the Stage will return a null value.
It's not ideal and definitely not secure, but it does limit the view rows to what the user can see on the related object.
Ryan
Yeah that's a clever workaround, many thanks Ryan! Agreed about the security aspect, but for the the cases where it's just about having those record permissions used to define non-security visibility as I currently have for the base entity it will work for now.
It would definitely be good for the view entities to be able to inherit permissions from lookup columns though, and feels like it would be a relatively quick win for Creatio to add, as most of the functionality around that would already exist. It could even be done in a no-code way by enabling the creation of these view-based entities directly in the config, effectively adding a logical layer to the platform which would be great for filtered views into the data and adding virtual calculated fields. So much utility to be had with such a logical layer.