Override Visibility Strategy while initializing Sugar Bean

Hello Folks,

I wanted to override visibility strategy defined in module bean class definition while initializing that bean.

For eg: I have a module called Test and I have defined following visibility in bean class.

class Test extends SugarBean

{

    public function __construct()

    {

         $this->addVisibilityStrategy("OwnerVisibility");

         parent::__construct();

    }

}

Now, while initializing bean, I wanted to override this strategy in some scenarios.

$testBean = BeanFactory::newBean("Test");

$testBean->addVisibilityStrategy("OwnerOrAdminVisibility");

But the above line is not working. I am not sure how to override the visibility already defined in bean definition.

Any help or idea would be greatly appreciated.

Regards.

Hats

Parents Reply Children
  • 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

  • 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

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

  • 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