From a functional point of view, portals are filling the gap between the DAM and Boards. A portal allows to group together different assets and to feature this group within the DAM.

From a DAM perspective, portals is just a tree metadata to index assets. The main relationship for linking an asset to a portal is by checking the asset portals metadata.

In order for portals to have their own landing page, they require some additional properties for storing content.

The portal object

portal is a PONO (Plain Old Noheto Object) defined to meet within a single object, all the needs of a portal to be displayed :

• it is a tree so it can manage sections, with sorting capabilities (portal, position)

• it is i18n and can handle indexed description OR HTML description

• it can be shared with a team like collaborativespace

• it can be private like a board

• it can have viewers

• it can provide a list of assets per entry position

• its visibility can be easily managed through visibility

• it allows the front end to store any view option

@startuml
hide empty members
object user
object wkfpkgportal
object Legend
Legend : -native fields
Legend : ~portals related
Legend : # i18n fields

object portal
portal : -id = identity
portal : -created = datetime
portal : -modified = datetime
portal : -parent = sentence
portal : -child = data
portal : -activated = boolean
portal : ~position = integer
portal : ~state = text
portal : ~private = boolean
portal : ~firstitems = text
portal : ~newestitems = text
portal : ~visibility = data
portal : ~logo = file
portal : ~ cover = file
portal : ~name = data
portal : #namefr = data
portal : #namede = data
portal : ~description = text
portal : #descriptionfr = text
portal : #descriptionde = text
portal : ~descriptionhtml = html
portal : #descriptionhtmlfr = html
portal : #descriptionhtmlde = html
portal --> wkfpkgportal : -status
portal --> portal : ~ portal
portal o--> user : ~ team
portal o--> user : ~ viewers
@enduml

Portals fields

The portal object regarding assets

@startuml
hide empty members
object asset
asset : portals (portal)
object portal
portal : owner (user)
portal : status (wkfpkgportal)
portal : private = boolean
portal : visibility = data
portal : team (user)
portal : viewers (user)
portal : portal (portal)
portal --> portal : portal
asset o--> portal : portals
@enduml

Additional structures and changes to the model

Home widgets

Overview

@startuml
hide empty members
object vueapphomewidget
object homewidgetelttype
object portal
object vueapphomewidgettype
object wxmcart
vueapphomewidget : name = data
vueapphomewidget : position = integer
vueapphomewidget : headercart[1-4] = data
vueapphomewidget : buttoncart[1-4] = data
vueapphomewidget : descriptioncart[1-4] = text
vueapphomewidget : usecartdescription = boolean
vueapphomewidget : titlecart[1-4] = sentence
vueapphomewidget --> vueapphomewidgettype : type
vueapphomewidget --> wxmcart : cart[1-4]
vueapphomewidget --> portal : portal[1-4]
vueapphomewidget --> homewidgetelttype : elttype[1-4]
@enduml

Faces

Faces of vueapphomewidget have been updated to have BO forms with better behaviour.
Only faces for rowX2, rowX3, rowX4 elements have been updated. Faces for carousel and waffle are still the same. Here you will find a plantuml graph explaining the behaviour.

Download assets of a portal

Overview

The media download functionality allows users to download a selection of assets from a portal as a ZIP file. The process involves creating a download request and then retrieving the file through a download link.

Registering the download request

To initiate a media download, a download request must be registered. This is done by requesting the service api/packaged/portals/zip/register/{portalUUID}, which creates an instance of the portaldownload object. This object contains all the necessary information to prepare the ZIP file.

The service will generate a portaldownload object, which holds details like:

1. name: The name of the ZIP file (without the extension).

2. portal: The unique identifier (UUID) of the portals/section from which assets are downloaded.

3. uuids: The UUIDs of the selected media files for download.

4. data: Additional metadata about the request such as download options, file transformation profiles, etc.

5. expires: The expiration date for the download link.
   Once it reaches its expiration date, the instance will be automatically deleted. The expiration date is obtained by adding to the date of the request creation, the value of the parameter portal_download_expiration of the plugin PACKAGED_Portals (the Default value is 7 days).

6. query: If provided, this specifies a query to select assets for dynamic download. If filled, the value set in the uuids property is ignored.

@startuml
hide empty members
object portaldownload
portaldownload : name = data
portaldownload : portal = data
portaldownload : uuids = text
portaldownload : data = text
portaldownload : expires = datetime
portaldownload : query = text
@enduml

Downloading the media

1. The download service lets users retrieve the ZIP file from a portaldownload instance.

2. The download link uses the UUID of the portaldownload instance created during the register step.

3. API Example: GET api/packaged/portals/zip/download/{portalDownloadUUID}

4. Optional parameter :

   • filename: Custom name for the ZIP file

Registered Services

Below is a list of notable services used within the plugin PACKAGED_Portals for the portals feature.

Triggers

Portal

The service com.wedia.packaged.portals.extensions.PortalsTrigger manages triggers related to the "portal" object. It ensures that appropriate actions are performed whenever certain events, such as insertion or update, occur on the portal object.

Visibility

The visibility property of the portal object controls the visibility state of an instance. There are three possible values for this property: public, private, and internal. If an unknown value is set for this property, it will be replaced with a value inferred from the current instance properties.

The properties controlled by the visibility attribute are status and private:

Synchronization Between Portal and Its Sections

With the help of the service trigger on the portal object, certain properties are automatically propagated from the parent portal to its sections. These properties include team, viewers, private, status, and activated.

If a section has one of these properties set to a value different from its parent portal, it will be reverted to the portal’s value for that property.

Sending Notifications to Viewers/Team

The trigger on the portal is also responsible for sending notifications when the team or viewers property is updated with a new user.

Assets

The PACKAGED_Portals plugin provides a trigger on assets related to portals (objects tagged as damobject with a portals field pointing to the portal object). This trigger is executed whenever an asset is inserted or updated.

Primarily, it ensures the correct assignment or removal of assets to or from the portal’s sections through the portals property, updating the portal.newestitems property with the UUIDs of the newly added or removed assets.

Additionally, the trigger checks if instances assigned to the portals property are updatable by the current surfer. If this is not the case, an error will be thrown during the instance save process.

API for Assigning/Removing Assets to/from Portal’s Sections

A key API service within the portals feature is the one that assigns assets to a portal’s section. The removal process follows the same principle.

• Endpoint: api/packaged/portals/assignToPortal/{uuid_of_section}

It accepts a list of UUIDs as a payload (application/json) representing the assets to be assigned:

{ "assets": ["uuid1", "uuid2", "uuid3"] // List of asset UUIDs to assign to the portal }

Before executing, the service performs several checks:

1. Check if the surfer is connected - returns a 401 status code if this fails.

2. Check if the current surfer is allowed to update the portal instance - returns a 403 status code if this fails.

3. Check if the payload is valid - returns a 400 status code if this fails.

4. Check if the portal specified in the payload exists - returns a 400 status code if this fails.

5. Unhandled errors - return a 500 status code.

If the number of submitted assets exceeds the limit defined by the plugin parameter max_assets_async, the assignment will be processed asynchronously. Otherwise:

• If an asset instance among those provided is lockable for an update, it will be automatically assigned to the portal.

• Otherwise, the assignment will be recorded in a queue to be processed later by a scheduled thread pool execution.

Custom Section Service

This service extends the standard APIs provided by the WXM_RESTAPI plugin. It is mainly used to provide a $custom section when using DAM/DATA services on portal object in order to provide additional pieces of information for the front.

Security

From a security perspective, we observe standard security rules. Additionally, we assume that assigning an asset to a portal should be allowed when the user is allowed to update the target portal.

The default starter-kit configuration relies on permissions available / configurable based on the role type.

Role types default permissions

insert rules

Administrators and Contributors types are allowed to create portals

objectdata/insert/$anycreation

NBCOMMONELEMENTS(',27,28,', surfer.roleid) > 0
AND
LOWER(objectname) = 'portal'

Other users can’t create portals

update rules

Administrators are allowed to update any portal

objectdata/insert/$anystatus/$anyowner

NBCOMMONELEMENTS(',27,', surfer.roleid) > 0
AND
LOWER(objectname) = 'portal'

Other roles are allowed to update their portals and portals they are team members of :

objectdata/update/$anystatus/$selfowner

objectdata/update/$anystatus/$teammember

LOWER(objectname) = 'portal'
AND
(
  object.owner = surfer.id
  OR
  NBCOMMONELEMENTS(object.team, surfer.id) > 0
)

View rules

Administrators are allowed to view any portal

objectdata/insert/$anystatus/$anyowner

NBCOMMONELEMENTS(',27,', surfer.roleid) > 0
AND
LOWER(objectname) = 'portal'

Other roles are allowed to view their portals, portals they are team members of, portal they are members of viewers, internal portals and public portal :

objectdata/view/$online/$anyowner

objectdata/view/$public/$anyowner

objectdata/view/$anystatus/$selfowner

objectdata/view/$anystatus/$teammember

objectdata/view/$anystatus/$viewer

LOWER(objectname) = 'portal'
AND
surfer.connected
AND
(
  object.status = 6
  OR
  object.private = 2
  OR
  object.owner = surfer.id
  OR
  NBCOMMONELEMENTS(object.team, surfer.id) > 0
  OR
  NBCOMMONELEMENTS(object.viewers, surfer.id) > 0
)

Extending portals

Adding metadata to the portal object

Portal’s object can be extended. You can add properties for filtering, segmentation, or other specific purposes.

For each added property you can decide to display it on portal’s edition or creation form, you can ou can manage this through portal’s structure facets configuration.

You can find another example of property addition for segmentation purposes here : https://crossmedia.atlassian.net/wiki/spaces/WD/pages/3298787349/Portals+installation+guide#4.3%2F-Segmentation-of-portals