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 list of assets per entry position
its visibility can be easily managed through visibility
it allows the front end to store any view option

Source of the portal object

Find below the input to generate this image with plantUml

@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

	name	type	comments
Visibility / Security	status	`child` → `wkfpkgportal`	It is expected that the workflow defines online as well as archived steps. It is expected that non-connected users are granted to view online portals.
	private	`child` → `activated`	When set to `true` only users defined in `team` and `viewers` are allowed to view instances.
	team	`cmlr` → `user`	Defines the list of users allowed to update the instance.
	viewers	`cmlr` → `user`	Defines the list of users allowed to view the instance, even if instance is private
	visibility	`word`	A property used by the Front-End to change visibility of the instance. 3 different values are handled : `private` when this value is given, then the instance is marked private and status is switched to draft `internal` when this value is given, then the instance is marked public and status is switched to draft `public` when this value is given, then the instance is marked public and status is switched to online
Portal / Section common	portal	`child` → `portal`	Allows to define portals and sections as a tree
	position	`integer`	Allows to order the sections within a portal
	name, namefr, namede	`sentence`	Name of portal / section
	state	`text`	Used as a state by Front End to store any display option
Portal specific	description, descriptionfr, descriptionde	`text`	Description of a portal. This property is indexed
	logo	`image`	Logo for the portal
	cover	`image`	Cover image for the portal
Section specific	firstitems	`text`
	newestitems	`text`
	descriptiohtml, descriptionhtmlfr, descriptionhtmlde	`html`