How to configure forms in primaryCategory

 

Overview

This wiki explains how to configure forms in a primaryCategory.

These are a set of configurable fields displayed in a form used in editors for creation, modification and viewing of an asset. These fields correspond to the metadata that are stored as part of an asset. Since the entire creation is driven by “Primary category” definition, the form configuration is also part of the primary category definition.

There are broadly two types of fields that can be configured:

  1. Generic fields (non-framework) - These are fields that define generic metadata related to the asset not specific to any framework. Examples are Name, Description, Keywords, Attributions etc.

  2. Framework related fields - These are fields that are related to a framework. A framework defines a related group of attributes and values that can be tagged to an asset, which help in better organizing and easy discovery of assets. The values of a framework attribute typically come from a predefined list - flat or hierarchical. Example of a framework is a K-12 Curriculum that defines “Board”, “Medium”, “Class” and “Subject” attributes. A K-12 curriculum framework, like say CBSE framework defines all the possible values for Board, Medium, Class and Subject based on its curriculum. Please refer to “Generalized Organization and Target Framework tagging” page for more details about framework tagging.

Forms can be configured with both the above types of fields.

If a generic field is a “list”, the list of values come from a preconfigured list. For a framework related field, the values come from the selected framework.

Following are various behaviors that can be configured for a field:

  1. Is the field read only or editable?

  2. Is the field mandatory or optional?

  3. Does the field have a default value to be populated?

Each field is mapped to an attribute of the asset in which the value is stored.

Following sections detail how forms can be configured for various types of assets.

References

Ref: Please refer to the below wiki for how to create and update primaryCategory.
https://project-sunbird.atlassian.net/wiki/spaces/User/pages/1818722322

Ref: Please refer to the below wiki for a list of input types supported by SB forms.
https://project-sunbird.atlassian.net/wiki/spaces/SingleSource/pages/2400944154/SB-forms+Components+Configurations#List-Of-Components

Ref: Please refer to the below page for details of framework tagging

https://project-sunbird.atlassian.net/wiki/spaces/SingleSource/pages/2477260803

Curl Command to modify form configuration

Form configuration is part of primary category definition. The definition can be changed using the following curl command has to be run:

curl -L -X PATCH '{{host}}/object/category/definition/v1/update/<content category definition id (eg: obj-cat:etextbook_content_all)>' \ -H 'Content-Type: application/json' \ --data-raw '{ "request": { } }'

 

The curl command takes asset category id and request payload as inputs. Asset category id is the id of the primary category for which the form has to be configured. Request payload contains the primary category definition in a json format. Following sections detail the json format for forms configuration for different types of assets.

Form configuration json for a Content type of asset

This section details forms configuration for any primary category whose object type is Content. Content is an individual piece of asset.

Find below request to enable form with Name(text) & Author( text) fields. This is just a sample to enable two fields we can use any inputType supported by SB_forms which we shared in the above reference wiki.

{ "request": { "objectCategoryDefinition": { "forms": { "update": { "templateName": "", "required": [], "properties": [ { "name": "First Section", "fields": [ { "code": "name", "dataType": "text", "description": "Name of the content", "editable": true, "inputType": "text", "label": "Title", "name": "Name", "placeholder": "Title", "renderingHints": { "class": "sb-g-col-lg-1 required" }, "required": true, "visible": true, "validations": [ { "type": "maxLength", "value": "80", "message": "Input is Exceeded" }, { "type": "required", "message": "Title is required" } ] }, { "code": "author", "dataType": "text", "description": "Author", "editable": true, "inputType": "text", "label": "Author:", "name": "Author", "placeholder": "Author", "tooltip": "Provide Author of this content.", "renderingHints": { "class": "sb-g-col-lg-1 required" }, "required": true, "validations": [ { "type": "required", "message": "Author is required" } ] } ] } ] } } } } }

 

Form configuration json for a Collection and Question Set type of asset

This section details forms configuration for any primary category whose object type is either Collection or a Question set. Since both Collection and Question Set have hierarchy and are managed using the same editor, both the type of assets have similar forms configuration.

There are three levels of forms that can be configured for a collection or question set.

  1. Form that should be shown at root level of the hierarchy

  2. Form that should be shown for any folder within the hierarchy

  3. Form that should be shown when for an asset linked to a folder in the hierarchy

Request payload for Root-level form config

Find below request to enable root level form with Name( text) & Description( textarea) fields. This is just a sample to enable two fields we can use any inputType supported by SB_forms which we shared in the above reference wiki.

{ "request": { "objectCategoryDefinition": { "forms": { "create": { "templateName": "", "required": [], "properties": [ { "name": "First Section", "fields": [ { "code": "name", "dataType": "text", "description": "Name of the content", "editable": true, "inputType": "text", "label": "Title", "name": "Name", "placeholder": "Title", "renderingHints": { "class": "sb-g-col-lg-1 required" }, "required": true, "visible": true, "validations": [ { "type": "maxLength", "value": "80", "message": "Input is Exceeded" }, { "type": "required", "message": "Title is required" } ] }, { "code": "description", "dataType": "text", "description": "Description of the content", "editable": true, "inputType": "textarea", "label": "Description", "name": "Description", "placeholder": "Description", "renderingHints": { "class": "sb-g-col-lg-1" }, "required": false, "visible": true, "validations": [ { "type": "maxLength", "value": "256", "message": "Input is Exceeded" } ] } ] } ] } } } } }

Request payload for Root-level form config to enable DIAL code linking

Please find below the request payload to enable DIAL codes linking.

Form Configuration for a Folder / Unit level

Find below a request payload to enable the Folder/ Unit level form with Name( text) & Keywords( keywords) fields.

Form Configuration for an asset linked to a folder

Find below an request to enable asset linked to a folder form with Name( text) & Attributions( text) etc., fields. Note: Currently all the fields are related to the attributes of the asset.

 

Form Configuration for Relational metadata to asset linked to a collection

( )
Find below an request to enable relational metadata to asset linked to a collection form with Name( text) & Keywords( list) etc., fields.

(Note: Please make sure before adding a new field in the form, all the properties must be available in the pre-defined schema. Otherwise, the system will throw an error message. And it’ll not allow saving the relational metadata at the API level.)

Here is the schema link:


Request Body:

Form configuration for reviewer (View Only Mode)

The above sections detail the configuration for a creator to edit the metadata. The same form can be used for a reviewer with view only mode.