Sugar Developer Webinar - Fall '19 (9.2.0)

Hi Matt Marum and Michael Shaheen

at first : great jobs ! We were waiting for portal enhancements for a while. So many thanks.

My question is related to custom / additionnal modules that could be embedded inside the portal : what will be the authorization management to access this module data in the portal ? is it going to be the same that cases (only cases link to my account so only modules linked to an account can be embedded) or is it going to be the full module view (like the published articles of the KB) ?

In case your answer is the second one, do you already handle the possibility for partners to override the core REST API for the portal to restrict the records displayed according to the connected user (for instance, only my contracts, only the building located in my area etc.).

Thanks for your feedback and wish you a great day

Matt Marum : congrats for the diaper's management :-)

Frédéric Rinaldi, dotBase

Groupe Sugar,

Custom modules as main single entities can be added to the portal (9.2 onwards) with simple code customisations at the moment.

In regards to the action/acl access for custom modules you would need to change the Portal Role through the UI.

In regards to which records can be viewed on the portal for custom modules, there are different strategies but always through custom code/custom visibility at the moment (and not by modifying the API). It can be through a relationship with Accounts as you mentioned, or all records with specific flag(s) set, or even all records of a module, depending on what/how you customise it based on the specific needs.

Hello Enrico,

Many thanks for the answer.

There is one point I don't understand : why shouldn't we extend the API? Is it so bad to override the API for the portal platform to include a dynamic filtering according to the connected user?

Fred from Groupe Sugar

Hi frinaldi,

No problem!

First of all, also for the base application, the visibility is the place that always makes sure the visibility's security restrictions are applied correctly. That code triggers every time a record or a list of records are loaded. By extending just the api you might run into corner cases where that does not happen and potentially expose more data than intended.

The second reason is that there are pre-made visibility classes for the portal that will facilitate your job as well. If you have the codebase handy, as an example, have a look at the portal visibility class Visible that will present to the portal user all records of the module or at the class Generic where you would just need an extended vardefs to make it work "automatically" for you, based on an additional relationship of your custom module with Accounts (or even with Contacts).

The third reason is the mention of "override" instead of "extend" that scares me a little . Let's assume for a second that you really meant "override" or as an example that you are extending an api of the base application directly, that does not yet exist on the portal. It would mean that if the core product adds new functionality to an api you changed, you/your customer will not gain that functionality and potentially even have a non-intended behaviour in the future.

Let's also keep in mind that the changes on the portal framework are still young and we might iterate quickly on additional changes, so this last point is quite likely to happen.

Hope it helps

Hi frinaldi,

No problem!

First of all, also for the base application, the visibility is the place that always makes sure the visibility's security restrictions are applied correctly. That code triggers every time a record or a list of records are loaded. By extending just the api you might run into corner cases where that does not happen and potentially expose more data than intended.

The second reason is that there are pre-made visibility classes for the portal that will facilitate your job as well. If you have the codebase handy, as an example, have a look at the portal visibility class Visible that will present to the portal user all records of the module or at the class Generic where you would just need an extended vardefs to make it work "automatically" for you, based on an additional relationship of your custom module with Accounts (or even with Contacts).

The third reason is the mention of "override" instead of "extend" that scares me a little . Let's assume for a second that you really meant "override" or as an example that you are extending an api of the base application directly, that does not yet exist on the portal. It would mean that if the core product adds new functionality to an api you changed, you/your customer will not gain that functionality and potentially even have a non-intended behaviour in the future.

Let's also keep in mind that the changes on the portal framework are still young and we might iterate quickly on additional changes, so this last point is quite likely to happen.

Hope it helps

Thanks a lot Enrico Simonetti

We will look at these points

Many thanks Enrico Simonetti !