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
  • 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

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • 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

  • 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.

    --

    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

  • 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

    --

    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

  • 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

Reply Children
No Data