Configuration

Types

Cards:

[
    {
        "name": "Event", //{1}
        "type": "event", //{2}
        "creatable": true, //{3}
        "createLabel": "New event" //{4}
    },
    {
        "name": "Planning", //{1}
        "type": "planning", //{2}
        "creatable": true, //{3}
        "createLabel": "New planning" //{4}
    },
    {
        "name": "Assignment", //{1}
        "type": "assignment" //{2}
    }
]

  1. Name of the different objects types, displayed in drop down in top left

  2. The internal naming of the different types (don't change)

  3. A flag to determine if the specific item should be creatable and displayed under the menu in top right (default false)

  4. The label to display for creatable items

Property mappings

Model keys to OC property mapping

Event:

{
    "xml": "EventXML", //{1}
    "uuid": "uuid", //{1}
    "mimetype": "mimetype", //{1}
    "name": "EventName", //{1}
    "sector": "EventSector", //{1}
    "startDate": "EventStartDate", //{1}
    "endDate": "EventEndDate", //{1}
    "etag": "checksum", //{1}
    "planningItem": { //{2}
        "property": "EventPlanningItemRelations" //{3}
    }
}

  1. A key value pair where left part is internal keys and right part is OC properties

  2. Internal format to determine that the following part is a relation. Left part internal key

  3. Which property to contains the relation from OC

PlanningItem:

{
    "uuid": "uuid", //{1}
    "etag": "checksum", //{1}
    "xml": "PlanningXML", //{1}
    "mimetype": "mimetype", //{1}
    "headline": "PlanningHeadline", //{1}
    "urgency": "PlanningUrgency", //{1}
    "statusHRM": "PlanningStatusHRM", //{1}
    "sector": "PlanningSector", //{1}
    "startDate": "PlanningStartDate", //{1}
    "endDate": "PlanningEndDate", //{1}
    "event": { //{2}
        "property": "PlanningEventRelation" //{3}
    },
    "assignments": { //{2}
        "property": "PlanningAssignmentsRelation" //{3}
    }
}

  1. A key value pair where left part is internal keys and right part is OC properties

  2. Internal format to determine that the following part is a relation. Left part internal key

  3. Which property to contains the relation from OC

Assignment:

{
    "etag": "checksum", //{1}
    "uuid": "uuid", //{1}
    "contentType": "contenttype", //{1}
    "xml": "AssignmentXML", //{1}
    "mimetype": "mimetype", //{1}
    "headline": "AssignmentHeadline", //{1}
    "type": "AssignmentType", //{1}
    "statusHRM": "AssignmentStatusHRM", //{1}
    "assigneeName": "AssignmentAssigneesName", //{1}
    "endDate": "AssignmentEndDate", //{1}
    "startDate": "AssignmentStartDate", //{1}
    "assignees": { //{2}
        "property": "AssignmentAssigneesRelation" //{3}
    },
    "articles": { //{2}
        "property": "AssignmentArticlesRelation" //{3}
    },
    "planningItem": { //{2}
        "property": "AssignmentPlanningItemRelation" //{3}
    }
}

  1. A key value pair where left part is internal keys and right part is OC properties

  2. Internal format to determine that the following part is a relation. Left part internal key

  3. Which property to contains the relation from OC

SingleView:

{
    "uuid": "uuid", //{1}
    "etag": "checksum", //{1}
    "xml": "AssignmentXML", //{1}
    "type": "AssignmentType", //{1}
    "startDate": "AssignmentStartDate", //{1}
    "assigneeUuid": "AssignmentAssigneesUuid", //{1}
    "planningItem": { //{2}
        "property": "AssignmentPlanningItemRelation" //{3}
    },
    "articles": { //{2}
        "property": "AssignmentArticlesRelation" //{3}
    },
    "assignees": { //{2}
        "property": "AssignmentAssigneesRelation" // {3}
    }
}

  1. A key value pair where left part is internal keys and right part is OC properties

  2. Internal format to determine that the following part is a relation. Left part internal key

  3. Which property to contains the relation from OC

Articles:

{
    "headline": "WriterHeadlines", //{1}
    "leadin": "ArticleLeadin", //{1}
    "mimetype": "mimetype", //{1}
    "body": "ArticleBody", //{1}
    "uuid": "uuid", //{1}
    "created": "created", //{1}
    "status": "WriterPubStatus", //{1}
    "updated": "updated", //{1}
    "authors": "WriterAuthors", //{1}
    "authorsUuid": "WriterAuthorsUuid", //{1}
    "images": "ArticleMetaImageUuids", //{1}
    "caption": "ArticleCaption", //{1}
    "title": "Name", //{1}
    "channels": "ArticleMetaChannels", //{1}
    "publishedDate": "PubDate" //{1}
    "size": "ArticleSize", //{1}
    "premium": "ArticleMetaPremium", //{1}
    "checksum": "checksum", //{1}
    "assignmentUuid": "ArticleMetaAssignmentUuid" //{1}
}

  1. A key value pair where left part is internal keys and right part is OC properties

Concepts:

{
    "xml": "ConceptXML", //{1}
    "uuid": "uuid", //{1}
    "name": "ConceptName", //{1}
    "type": "ConceptImTypeFull", //{1}
    "imidSub": "ConceptImIdSubjectId", //{1}
    "avatar": { //{2}
        "property": "ConceptAvatarRelation" //{3}
    }
}

  1. A key value pair where left part is internal keys and right part is OC properties

  2. Internal format to determine that the following part is a relation. Left part internal key

  3. Which property to contains the relation from OC

Avatar:

{
    "uuid": "uuid", //{1}
    "filename": "Filename" //{1}
}

  1. A key value pair where left part is internal keys and right part is OC properties

Property fetching

Determine what properties to fetch from OC for each type. Left side is keys used in code and right is the named keys from property mapping (not OC properties)

Event:

[
    "xml", //{1}
    "planningItem.xml" //{2}
]

  1. A property mapping key to fetch

  2. An example where the property key is a relation and also fetching the sub key of that relation

PlanningItem:

[
    "xml", //{1}
    "event.xml", //{2}
    "assignments.xml" //{2}
]

  1. A property mapping key to fetch

  2. An example where the property key is a relation and also fetching the sub key of that relation

Assignment:

[
    "xml", //{1}
    "assignees.xml", //{2}
    "planningItem.xml" //{2}
]

  1. A property mapping key to fetch

  2. An example where the property key is a relation and also fetching the sub key of that relation

SingleView:

[
    "xml", //{1}
    "uuid", //{1}
    "type", //{1}
    "etag", //{1}
    "articles.uuid", //{2}
    "articles.title", //{2}
    "articles.status", //{2}
    "articles.headline", //{2}
    "articles.checksum", //{2}
    "articles.size",
    "planningItem.uuid", //{2}
    "planningItem.headline", //{2}
    "planningItem.statusHRM", //{2}
    "planningItem.assignments.xml", //{2}
    "assignees.xml"
]

  1. A property mapping key to fetch

  2. An example where the property key is a relation and also fetching the sub key of that relation

Article:

[
    "headline", //{1}
    "title", //{1}
    "uuid", //{1}
    "status", //{1}
    "created", //{1}
    "updated", //{1}
    "leadin", //{1}
    "body", //{1}
    "authors", //{1}
    "channels", //{1}
    "size", //{1}
    "premium", //{1}
    "checksum", //{1}
    "assignmentUuid" //{1}
]

  1. A property mapping key to fetch

Concept:

{
    "tags": [ //{1}
        "uuid", //{2}
        "name", //{2}
        "avatar.uuid", //{3}
        "avatar.filename" //{3}
    ],
    "assignees": [ //{1}
        "xml", //{2}
        "uuid", //{2}
        "name", //{2}
        "avatar.uuid", //{3}
        "avatar.filename" //{3}
    ],
    "organisers": [ //{1}
        "xml", //{2}
        "uuid", //{2}
        "name" //{2}
    ],
    "participants": [ //{1}
        "xml", //{2}
        "uuid", //{2}
        "name", //{2}
        "avatar.uuid", //{3}
        "avatar.filename" //{3}
    ],
    "users": [ //{1}
        "uuid", //{2}
        "name", //{2}
        "avatar.uuid", //{3}
        "avatar.filename" //{3}
    ]
}

  1. An internal key used to know what to fetch for specific concept types whitin the app

  2. A property mapping key to fetch

  3. An example where the property key is a relation and also fetching the sub key of that relation

Queries & Suggestions

Setup base queries for the different types as well as suggest fields to use

Event:

Base query

The base query for Events

contenttype: Event

Event suggest fields + sort order

The fields to use when using suggest search

{
    "name": 0, //{1}
    "section": 0 //{1}
}

  1. Left part is a property mapping key to fetch while the following number is a rank weight in order to sort the results. Higher number equals higher sorting order

Event labels

{
    "_all": "Free text", //{1}
    "name": "Name", //{1}
    "section": "Section" //{1}
}

  1. A mapping from key to a Label, left part is the key specified in the fields config while the right part is the translated label to display in result

PlanningItem:

Base query

The base query for Planning Items

contenttype: Planning

Planning Item suggest fields + sort order

The fields to use when using suggest search

{
    "urgency": 0, // {1}
    "headline": 0, // {1}
    "statusHRM": 0, // {1}
    "section": 0 // {1}
}

  1. Left part is a property mapping key to fetch while the following number is a rank weight in order to sort the results. Higher number equals higher sorting order

Planning Item labels

{
    "_all": "Free text", //{1}
    "urgency": "Prio", // {1}
    "headline": "Title", // {1}
    "statusHRM": "Status", // {1}
    "section": "Section" // {1}
}

  1. A mapping from key to a Label, left part is the key specified in the fields config while the right part is the translated label to display in result

Assignment:

Base query

The base query for Assignments

contenttype: Assignment

Planning Item suggest fields + sort order

The fields to use when using suggest search

{
    "headline": 0, // {1}
    "type": 0, // {1}
    "statusHRM": 0, // {1}
    "assigneeName": 0 // {1}
}

  1. Left part is a property mapping key to fetch while the following number is a rank weight in order to sort the results. Higher number equals higher sorting order

Planning Item labels

{
    "_all": "Free text", //{1}
    "headline": "Headline", // {1}
    "type": "Assignment type", // {1}
    "statusHRM": "Status", // {1}
    "assigneeName": "Assignee" // {1}
}

  1. A mapping from key to a Label, left part is the key specified in the fields config while the right part is the translated label to display in result

Article

Base query

The base query for Article

contenttype: Article

Article Item suggest fields + sort order

The fields to use when using suggest search

{
    "authors": 0, // {1}
    "channels": 0 // {1}
}

  1. Left part is a property mapping key to fetch while the following number is a rank weight in order to sort the results. Higher number equals higher sorting order

Article labels

{
    "_all": "Free text", //{1}
    "authors": "Authors", //{1}
    "channels": "Channels" // {1}
}

  1. A mapping from key to a Label, left part is the key specified in the fields config while the right part is the translated label to display in result

Article date options

{
    "label": "Publish date",
    "value": "publishedDate"
}

Used to allow date search in linked articles modal.

Providers

Content Provider (LCC/OC)

${DBKS:CA_PROVIDER} // {1}

  1. The named content provider mapped in LCC/OC-communication plugin, uses default key store value

ICP image content provider

{
    "article": { // {1}
        "provider": "${DBKS:ICP_PROVIDER}", // {2}
        "function": "crop", // {3}
        "identifier": "uuid" // (4)
    },
    "avatar": { // {5}
        "provider": "${DBKS:ICP_PROVIDER}", // {2}
        "function": "crop", // {3}
        "identifier": "uuid" // (4)
    }
}

  1. Internal key used by articles

  2. The provider to use from ICP in order to display image

  3. Which function on the specified provider to use

  4. Which type of identifier to use filename/uuid (depending on service)

  5. Internal key used to render Concept avatars

Map options

Maps settings

{
    "apiKey": "${DBKS:GOOGLE_MAPS_API_KEY}" // {1}
}

  1. A valid Google maps api key in order to utilise the map functionality inside NRP

Writer

Writer config

{
    "endpoint": "${DBKS:WRITER_URL}", // {1}
    "openArticleInNewWindow": false // {2}
}

  1. Endpoint to a writer that works towards the same OC

  2. Options wether to open articles in new window or not

Email service

{
    "enable": true, // {1}
    "sendEndpoint": "${DBKS:EMAIL_SERVICE_SEND}", // {2}
    "listEndpoint": "${DBKS:EMAIL_SERVICE_LIST}", // {3}
    "serviceDomain": "${DBKS:EMAIL_SERVICE_DOMAIN}" // {4}
}

  1. If email service should be displayed in app or not

  2. URL to Naviga mail service Send (sendmail.Email/Send)

  3. URL to Naviga mail service List (sendmail.Email/GetThread)

  4. URL to the mail service domain (i.e. saas-stage.infomaker.io)

Debug

Log to console

Switchbutton: false/true // {1}

  1. Determine if extra debug outputs should be outputted into the console of the browser or not

PreviousPlanning and assignment portalNextSorting

Last updated

Was this helpful?