Override Visibility Strategy while initializing Sugar Bean

Hi hats 

I believe the best way is to create a custom visibility which adds either OwnerVisibility or OwnerOrAdminVisibility depends on $this->bean/user attributes.

We have done that very frequently without big deal.

Kind regards

Hi André Lopes,

Thank you so much for the suggestion. There is little complexity in my scenario. I want this visibility to change only when instantiating bean to fetch some rows. With owner visibility, I am not able to fetch records of other users even with admin user and if I set owner or admin visibility, it shows all records even in Sugar UI (which I don't want).

I hope you have understood my scenario. Please let me know if there is any possible way to achieve this or final solution would be to fetch these records using raw SQL queries (which I don't prefer much).

Thank you in advance.

Regards.

Hats

As far I understand my suggestion should work without big deal.

Any Visibility Strategy has the methods addVisibilityFromQuery (you can define the constrains on JOINed tables) and addVisibilityWhereQuery (you can define the constrains on where clauses).

So basically you can, depending on bean status, implement the correct strategy.

Regards

Thank you André Lopes.

I will give this a try and update here.

Hi hats,

First of all, Admin users do not have visibility applied to them. My recommendation for that specific scenario would be to use Admin users only for Administrative actions and not for normal users.

Non-admin users can leverage the custom visibility rules you produce. Remember that whatever filtering you apply to the database layer, you also have to apply it to the search layer.

A good example from our last uncon can be found here: uncon/custom_visibility at 2016 · sugarcrm/uncon · GitHub 

Custom visibilities are applied to objects through extended vardefs as per the example as well.

Also remember that the visibility layer applies to single record loads and most importantly to listviews with real-time queries. Be really mindful at the performance impact a non-optimised query might have. Make sure to profile the queries and the application correctly with production like large data sets, before going live with your changes.

Hope my pointers help you with your objective

Cheers

Hi Enrico Simonetti,

Thank you so much for your reply.

By mentioning "First of all, Admin users do not have visibility applied to them.", do you mean that admin user should be able to see all the records irrespective of the visibility set on the module ? For eg: If I want to fetch all records of a particular module whose visibility is set to "OwnerVisibility", can I get it using any admin user ? I tried to do so, but couldn't get all data. It's fetching only current user data. Please correct me if I am wrong.

Regards.

Hats

Hi Enrico Simonetti and André Lopes,

Also, is there any way we can bypass this visibility while instantiating the bean like how we disable row level security. Please let me know.

Regards.

Hats

hats,

I was not entirely accurate on my previous statement as it does depend on the implementation completed. It is more accurate to say that the out of the box visibility model does not apply to administrators (as in Teams security). Administrators do not adhere both to standard Teams and Roles. See here: http://support.sugarcrm.com/Documentation/Sugar_Versions/7.9/Pro/Administration_Guide/Team_Management/index.html#Team_Membership_Types

Note: Administrators do not adhere to team security and therefore can see all records.

I am not sure right now about ./data/visibility/OwnerVisibility.php, would have to investigate that.

As a rule of thumb, if I had to complete a customisation of visibility or ACL, I would try to leave Admin unrestricted. For integration purposes and for administration of the system by a superuser, the administrator can then achieve actions (like reverting locked records or making a record visible to the correct user) that otherwise might require straight database access.

hats,

After additional review it looks like ./data/visibility/OwnerOrAdminVisibility.php (that extends OwnerVisibility) are internal only visibility classes that you should not use.

They are applied to modules that do not have real data requirements and do not implement search engine filtering for that reason. As I was saying before, you need to make sure you implement correctly the visibility also on the search engine Elasticsearch. I encourage you to look at the previously posted example where it implements 

the required "elastic*" methods.

If I had different needs that change based on some user's parameters I would write my own visibility class and apply my conditional logic in there to behave differently based on the required conditions and that implement correctly the visibility on the search engine as well.

As mentioned previously I highly recommend you to complete profiling at scale as any visibility change (if not completed correctly) might make the system under perform.

Hope it helps

Thank you Enrico Simonetti. This helps. I will write my own visibility class as OwnerVisibility and OwnerOrAdminVisibiltiy doesn't seem to serve the purpose for me. I will follow the uncon example shared above. Thank you so much for directing me to the right path.

Regards.

Hats