Catalog mandatory properties
Catalogs are used to specify mandatory properties for an entity. These properties have an impact on the calculation of the product's progress score when they are not filled in. A catalog can also be used to specify fields and lists to be audited.
The catalog is available on the instance in:
Repository > System > Properties catalog
We recommend checking the validity of the JSON array (without backslashes) with a parser before uploading it to the instance, for example with JSONLint.
Note: You need to clear the caches once the file has been modified, then reformulate the products.
Each catalog contains a number of mandatory or optional fields in its definition:
| Identifier | Type | Mandatory | Description |
|---|---|---|---|
| id | text | Yes | The catalog's unique identifier e.g. "inco" |
| label | text | Yes | The displayed name of the catalog e.g. EU 1169/2011 (INCO) |
| entityType | array | No | Restricts the catalog to a specific entity type e.g.: ['bcpg:finishedProduct'] applies this catalog only to Finished products |
| entityFilter | text | No | Restricts the catalog to entities matching a SPEL formula e.g. "hierarchy1 != null" or "spel(hierarchy1 != null)" applies this catalog only to entities with a family |
| fields | array | Yes | The list of fields to fill in for the entity to be valid e.g.: ["bcpg:legalName", "bcpg:storageConditionsRef"] creates a catalog where the legal name and storage conditions must be filled in |
| uniqueFields | array | No | The list of fields whose value must be unique e.g.: ["bcpg:erpcode", "cm:name"]. If a value is duplicated, the field is reported in the catalog |
| auditedFields | array | No | The list of fields or lists taken into account to update the catalog modification date e.g. ["bcpg:legalName", "compoList"]. When one of these fields is modified, the catalog date is updated |
| i18nMessages | object | No | Field/label mapping to specify a label for a mandatory field. E.g.: {"bcpg:clients": "associé", "cm:title": "becpg.forms.field.tradeName"}: for bcpg:clients, we use the new label associé; for cm:title, we use a language key, which must be declared in a Core language file (Alfresco). |
| locales | array | No | The list of languages to which the catalog applies. If this field is not present, the report languages are used (if any); otherwise, the system language is used. A language is defined by a two-letter code according to the ISO-639-1 standard https://fr.wikipedia.org/wiki/Liste\_des\_codes\_ISO\_639-1 |
| protectedFields | array | No | When a user attempts to modify one of these fields, re-authentication is automatically required to validate the action |
You can indicate an alternative between two fields in a list by separating them with the "|" symbol.
e.g.: ["bcpg:useByDate|bcpg:bestBeforeDate"]
Add/delete a catalog field
- Go to "Repository > System > Properties catalog".
- Hover over "Catalogs" and click "Download".
- Open the file with a text editor (Atom, for example).
- Add or delete a line.
- Return to the instance, click "More", then "Import a new version", and choose the file you have just modified.
- Reformulate the products.
Use a renamed field in the catalog
Use the i18nMessages parameter in the catalog to override the field name.
"i18nMessages" :{
"cm:title":"becpg.forms.field.tradeName"
},
Multilingual fields
For multilingual fields, you can make the field mandatory for one language only: follow the field name with an underscore and the language code. E.g. bcpg:legalName_pl makes
the legal name field mandatory in Polish, regardless of the language selected in the catalog or reports.
Formulas
Formula fields can also be created by prefixing the field with formula{id}|. For example, formula1|isLiquid() or formula1|spel(isLiquid()).
The formula id can then be used to specify its label:
"i18nMessages": {
"formula1" : "becpg.forms.field.tradeName",
"formula2" : "formula2.missingKey"
}
You can use SPEL formulas to test whether a list is filled in or empty, for example:
formula1|spel(costList.?[value != null].size() == costList.size()) tests whether all cost values are filled in.
Badge color
The “color” parameter defines the color of the catalog badge. This is useful when you manage several catalogs: you can assign a specific color to each department, which makes data entry easier for users.
"color": "hsl(0, 60%, 50%)"
Examples
Below are examples of catalogs:
[
{
"id": "incoFinishedProduct",
"label": "EU 1169/2011 (INCO)",
"entityType": [
"bcpg:finishedProduct"
],
"uniqueFields": [
"bcpg:erpCode",
"cm:name"
],
"fields": [
"bcpg:legalName",
"bcpg:precautionOfUseRef",
"bcpg:useByDate|bcpg:bestBeforeDate",
"bcpg:storageConditionsRef",
"cm:title"
],
"i18nMessages": {
"cm:title": "Trade name"
},
"auditedFields": [
"bcpg:legalName",
"cm:title",
"cm:description"
],
"modifiedField": "bcpg:modifiedCatalog1",
"entityFilter": "@beCPG.assocValue(nodeRef,\"bcpg:entityTplRef\")!=null && (@beCPG.assocValue(nodeRef,\"bcpg:entityTplRef\").toString()!=\"workspace://SpacesStore/7d1bf1c6-dc17-42ee-8314-cca9d6d30515\")"
},
{
"id": "incoRawMaterials",
"label": "EU1169/2011 (INCO)",
"entityType": [
"bcpg:rawMaterial"
],
"uniqueFields": [
"bcpg:erpCode",
"cm:name"
],
"fields": [
"bcpg:legalName"
]
},
{
"id": "incoRawMaterials2",
"label": "EU1169/2011 (INCO)",
"entityType": [
"bcpg:rawMaterial"
],
"i18nMessages": {
"cm:title":"becpg.forms.field.tradeName",
"ext:field1":"My translation"
},
"auditedFields": [
"cm:name",
"bcpg:legalName",
"cm:title",
"cm:description",
"bcpg:eanCode",
"bcpg:eanCodeLevel2",
"bcpg:eanCodeLevel3"
],
"protectedFields": [
"bcpg:productState"
],
"modifiedField":
"bcpg:modifiedCatalog1",
"entityFilter": "@beCPG.propValue(nodeRef,\"ext:articlesGroup\") == \"PUB\" || (hierarchy1 != null && (hierarchy1.toString() == \"workspace://SpacesStore/dae7c85f-6abf-4845-bfe1-4b3fa748b48b\"))"
}
]
Link a catalog to a task in a project
In projects, you can link a catalog to a task to check that the fields have been filled in. See this documentation