Query for createTraitDefinition

Balaram Barada · 2025-05-05T19:19:05+00:00

There was an error rendering this rich post.

Hi All ,

Can some one help me to understand the createTraitDefinition attribute properties.

Is attribute properties are fixed or Can we add a custom property to attribute i.e like the below examples custom1,custom2, custom3 ?

Swagger API : https://developer.opentext.com/services/products/content-metadata-service/apis/content-metadata#Trait/createTraitDefinition

Example :

"attributes": [
{
"default_value": "",
"data_type": "string",
"read_only": false,
"repeating": false,
"required": false,
"searchable": true,
"sortable": false,
"visible": true,
"unique": false,
"presentation_type": "TextArea",
"custom1":"",
"custom2":"",
"custom":[],
"flow": "new",
"display_name": "bbtarea4",
"display_name_multilingual": {
"en": "bbtarea4"
},
"id": null,
"name": "bbtarea4",
"size": 2000,
"custom_sequence": 1,
"localizable": true,
"url": "/trait-definitions/bbt4/attributes",
"validators": [
{
"type": "length_validator",
"operation": "Create",
"params": [
{
"name": "min",
"value": "1"
}
]
}
]
}
]

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

All comments

LazarescuA

Hello,

Yes, you can create a new trait using the API or using the VS Code extensions (Thrust Studio: https://developer.opentext.com/cloud-platform/documentation/build-with-our-vs-code-extension ). We strongly recommend to use the VS Code extensions to manage and create new definitions (Type, Trait, Workflow, etc.).

If you need to create a Trait definition using the API, in the Swagger example, the attributes node will contain as many attributes you want to add to your trait definition, each object in the array will be one custom attribute. For example, the array below would create a trait with 3 attributes:

. . .
"attributes": [
  {
    "name": "custom1",
    "display_name": "Custom Field 1",
    "data_type": "string",
    "size": 1000
  },
  {
    "name": "custom2",
    "display_name": "Custom Field 2",
    "data_type": "string",
    "size": 256
  },
  {
    "name": "custom",
    "display_name": "Custom Array",
    "data_type": "string",
    "repeating": true,
    "size": 100
  }
],
. . .

The mandatory fields are name, display_name, and data_type. The rest of the properties are optional and control the attribute validation, search, etc.

If you want to see which properties are mandatory, in the swagger example, switch to the schema view:

Balaram Barada

Hi @LazarescuA ,

Thanks for your update .

Regarding attributes with the data type "string," is it possible to include custom field properties beyond the standard ones? In the provided example of a single attribute, can we extend it to include fields such as "additionalprop1" and "additionalprop2"? Furthermore, are the attribute properties restricted to a predefined set, or can we consider them an open JSON object allowing arbitrary properties?

Is the below JSON attribute allowed for single attribute

{    "name": "custom1",    "display_name": "Custom Field 1",    "data_type": "string",    "size": 1000 ,"additionalprop1":"", "additionalprop2":"" }

LazarescuA

I am not sure about the use case here. The attribute of the trait is a property that you can set or get on different instances of the trait. Even if you add other additional properties to the attribute, how would you expect to use those? These properties control how the attribute is filled (for example unique, repeating, size, validators, etc.). If you can describe the use case, it would help understand how you plan on using it.

Balaram Barada

Hi @LazarescuA ,

Thanks for your update .

Yes my use case is for textArea , i would like to add some additional properties like hint, custom_sequence, presentation_type etc .

While the trait-definitions API execution was successful and included those properties, they are not present in the CMS attributes API response.

API execution success with below attribute set but highlighted properties are not visible in attributes API response.

Are those ignored while creating attribute in trait-definitions ?

{
"name": "approved_by3",
"display_name": "Approved by3",
"data_type": "string",
"size": 1000,
"default_value": "approver2",
"presentation_type": "TextArea",
"repeating": true,
"searchable": true,
"sortable": true,
"read_only": true,
"auditable": true,
"required": true,
"unique": true,
"url":"tetstststs",
"hint":"hhhhhh",

"presentation_type":"TextArea",

"custom_sequence":1,
"description": "Approved by the user",
"localizable": true,
"validators": [
{
"type": "length_validator",
"operation": "Create",
"params": [
{
"name": "min",
"value": "1"
}
]
}
]
}

LazarescuA

OK, so I get the use case, you want to be able to have some custom properties when defining an attribute so that it can help your custom UI to display it correctly.

I don't think this is available at this point, as you said - the call is successful but the custom properties are not retained or not returned.

Maybe @Prasanna Sridharan can help here: is it possible to save and retrieve custom properties for an attribute when defining a trait or type?

David Henshaw

Hi Alex,

Not wanting to hijack this thread - but we've got a similar situation.

Core Content allows you to define a Text Area attribute type.

e.g.

But the APIs that retrieve details only appear to return that the data_type is a string, which is same if the attribute type is a text input.

Is there anything in the APIs that explicitly delineates between the two?

Regards,

David.

LazarescuA

Hi David, thank you for highlighting these. As far as I tested, the screen you show here is a combination between the Attribute API (which holds the properties Editable, Searchable, Sortable, Required, default value) and some extra properties (display during add version, placehoder, etc.) which are stored in the Core Content config files. Meaning that the application uses logic to combine the two within one screen as the API only allows for the ones in the documentation: