Displaying built in Modules to customer-self-service

I've trying to display a built-in module (like contacts, accounts, etc..) to the customer support portal. I'm not sure if I should treat it like a custom module (not really any functionality to it).

What I have tried:

Editing the self-service role updating the permissions for the role that is assigned to our Portal users. In Admin > Role Management -> Customer Self Service Portal role. and setting the following permission to display the module:

  • Access - Enabled
  • Access Type - Normal
  • List - All
  • View - All

And after that, when i go to the Admin > Sugar Portal > Configure Portal. There are no hidden modules for me to put in the Displayed Modules list...

Expected output:

Displaying the account module with the contacts corresponding to the account so the customer can see/edit his/her account and contact info.

Should I edit the vardef file to make a module visible in the sugar customer portal?

Parents
  • Hi Karen,

    First of all, I would direct you to read this article and the comments as well before proceeding further: https://sugarclub.sugarcrm.com/dev-club/b/dev-blog/posts/adding-a-custom-module-to-the-customer-portal

    In short, I want to point out a couple of specific parts which should be clarified of your points:

    - The portal needs to know which records the specific portal user (contact) can or cannot see, and that is something that needs to be thought through carefully as you would not want to risk to expose more data than you should, to a customer. That's where the vardefs and potentially a custom visibility come into play

    - The portal needs the portal platform's views for the module you want to enable (list and record as a minimum)

    - The portal normally only allows for creation and not record editing, if you want to change this behaviour, it is a somewhat deep customisation

    If you do want to dig deeper into extending/overriding and in general customising the portal behaviour, I suggest you have a look at "data/visibility/portal/", "src/Portal/", "client/portal/api/ModulePortalApi.php", "data/acl/SugarACLPortal.php", every module's "portal_visibility" section within the vardefs and finally portal specific views to start with.

    Every portal component is now extensible leveraging the custom directory (so do not attempt to modify any core files).

    Hope this helps you towards the right direction!

    --

    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

Reply
  • Hi Karen,

    First of all, I would direct you to read this article and the comments as well before proceeding further: https://sugarclub.sugarcrm.com/dev-club/b/dev-blog/posts/adding-a-custom-module-to-the-customer-portal

    In short, I want to point out a couple of specific parts which should be clarified of your points:

    - The portal needs to know which records the specific portal user (contact) can or cannot see, and that is something that needs to be thought through carefully as you would not want to risk to expose more data than you should, to a customer. That's where the vardefs and potentially a custom visibility come into play

    - The portal needs the portal platform's views for the module you want to enable (list and record as a minimum)

    - The portal normally only allows for creation and not record editing, if you want to change this behaviour, it is a somewhat deep customisation

    If you do want to dig deeper into extending/overriding and in general customising the portal behaviour, I suggest you have a look at "data/visibility/portal/", "src/Portal/", "client/portal/api/ModulePortalApi.php", "data/acl/SugarACLPortal.php", every module's "portal_visibility" section within the vardefs and finally portal specific views to start with.

    Every portal component is now extensible leveraging the custom directory (so do not attempt to modify any core files).

    Hope this helps you towards the right direction!

    --

    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

Children
No Data