Page Comparison

...

• Disable PACKAGED_Portals

• In your front app’s feature config, set portals to false

4/ Configuration possibilites

3/ Configuration possibilities

3.1/ Portals list filters

3.1.1/ Portal list filters configuration

Portals list filters are configured in this file :
portals\explore\filters\default-cursor-config\default-resource-config.json
The configuration is set up and behaves in the same way as it does for the dam domain.

By default, all provided filters are activated. This was achieved while still following the app’s existing principles (same components, filter configurations system combined with named configurations).
We did this by utilizing two core features: constraint filters and cursor query parameter.

{
  "i18nQuery": true,
  "orderby": "modified desc",
  "path": "dam/data/portal",
  "security": ["objectdata/update","objectdata/delete"],
  "withAggregates": false,
  "withRights": true,
  "staticQuery": {
    "portal": {
      "empty": true
    }
  },
  // default active constraints
  // for portals list
  "query": {
    "or:portalrole.creator":{
      "owner": { "eq": "${surfer.id}" }
    },
    "or:portalrole.colaborator":{
      "team": { "ct": "${surfer.id}" }
    },
    "or:portalrole.viewer":{
      "viewers": { "ct": "${surfer.id}" }
    },
    "or:portalrole.none":{
      "and": [
        { "owner": { "neq": "${surfer.id}" } },
        { "team": { "nct": "${surfer.id}" } },
        { "viewers": { "nct": "${surfer.id}" } }
      ] 
    },
    // this constraints allows to hide all content when no portalrole constraint is selected
    "or:portalrole.hide": {
      "id": { "eq": 0} 
    },
    "or:portaltype.public":{
      "visibility": { "eq": "public" }
    },
    "or:portaltype.internal":{
      "visibility": { "eq": "internal" }
    },
    "or:portaltype.private":{
      "visibility": { "eq": "private" }
    },
    // this constraints allows to hide all content when no portaltype constraint is selected
    "or:portaltype.hide": {
      "id": { "eq": 0} 
    },
    "or:portalactive.true": {
      "activated": { "eq": true }
    }
  }
}

You can see on the cursor definition above that the query param’s value is quite large. It is actually containing all the default activated constraints. The key of this implementation is to make sure that the same constraint keys are used on filter’s definition and on cursor’s query param.

Constraint filter’s component(s) have also been updated to allow new UI (selected values on dropdown label, checkbox inline filter)

To improve the user experience, we were tasked with ensuring that if neither of the two default dropdown filters has a selected option, no results are displayed. This was made possible using a small adjustment in the cursor’s query configuration.

These two constraints are always applied to the cursor, allowing us to achieve the desired effect.

    "or:portalrole.hide": {
      "id": { "eq": 0} 
    },
    ...
    "or:portaltype.hide": {
      "id": { "eq": 0} 
    },

The logic operates such that between constraints like or:portalrole:xxx and or:portalrole:yyy, an OR operator is applied. However, between constraints like or:portalrole:xxx and or:portaltype:xxx, an AND operator is used. Below, you'll find more details about what happens at the "query" level:

• We’ve applied one role constraint and one type constraint. The result at the “query” level is :

  • (or:portalrole:xxx OR or:portalrole.hide) AND (or:portaltype:xxx OR or:portaltype.hide)

    • no hidden result, filtered according to chosen constraints

• We haven’t applied a role constraint, but we’ve applied a type constraint. The result at the "query" level is:

  • (or:portalrole.hide) AND (or:portaltype:xxx OR or:portaltype.hide)

    • hidden result

3.1.2/ Example of configuration

This filters configuration can be edited, to add or remove some filters. The configuration system is the same as on the dam side. Here i’ll provide an example of a possible customization

starter-kit\portals\explore\filters\default-cursor-config\default-resource-config.json

{
  "hideSide": true,
  "filters": [
    "portalsRoles", 
    "portalsTypes",
    "portalsActive",
    "status"
  ]
}

...

To activate filters by default when the page loads, follow the approach used for role or type filters. This involves creating a specific filter configuration with constraints and reusing the same constraint keys in the cursor definition within the query parameter

3.2/ Portal default filters

3.2.1/ Portal default filters

3.2.2/ Example of configuration

3.3/ Segmentation of portals and the assets within them

3.4/ Permissions

Guillaume LEPICARD Alioune Badara CAMARA Peut-être ce point n’est pas nécessaire

3.5/ Public Sharing Activation/Deactivation

Alioune Badara CAMARA