Sugar Developer Webinar - Fall '19 (9.2.0)

Hello Everyone,

I would like to add a clarification about enabling new modules on the new portal. If you attempt to do that, please make sure your new module's portal layouts (list.php and record.php) start from a portal module and not from a base module. As an example, you could start from Case's portal layouts (modules/Cases/clients/portal/views/record/record.php and modules/Cases/clients/portal/views/list/list.php) and manually tweak everything that is required (eg: the module name and the field changes).

This is to make sure you will not accidentally add fields that make sense only to the base application UI to your portal.

Specifically, it was reported to us that if the Teams field is added to the portal layout, it prevents the loading of the record view. Teams is not a concept that currently applies to the portal, and therefore it should not be added to any portal module.

Hope this helps you further smooth your customisations attempts.

Cheers

Many thanks Enrico Simonetti !

Thanks a lot Enrico Simonetti

We will look at these points

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