Share this page

# Entity metadata reference

The ALM Octane public REST API is fully metadata-driven. All entities described by metadata resources can be accessed via the REST API as resource collection.

Entity metadata describe the features the entity supports. Here we describe how the features are represented in the REST API.

In this topic:

## URI

Workspace level | `http[s]://<server>:<port>/api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/entities`
Shared space level | `http[s]://<server>:<port>/api/shared_spaces/<space_id>/metadata/entities`
Site level | `http[s]://<server>:<port>/admin/metadata/entities`

Notes

- The URI supports filtering by name.

- For the syntax for specifying parameters in URIs, see Variables and values.

## Supported HTTP Methods

This API supports only the GET operation.

## Properties

Entity | Description
--- | ---
Name | The entity name for which the metadata is defined. Field name: name
Features | Array of features supported by an entity. Each item is a JSON object. Field name: features
Description | A description of the entity.
Label | A label for the entity, typically displayed in the ALM Octane UI.

Back to top

## Features

The table below describes the available features:

REST

REST API-related definitions

Field | Description
--- | ---
name | The name of the feature is a constant value: rest.
url | The resource URL relative to the context root.
methods | An array of strings that the HTTP protocol methods supported. Values: GET POST PUT DELETE

Example: This example is for the workspaces entity (at the shared space level).

    {

        "name": "rest",

        "url": "workspaces",

        "methods": [ "GET", "POST", "PUT" ]

    }

Mailing

Whether the entity supports mailing.

Fields | Description
--- | ---
name | The name of the feature is a constant value: mailing.

    Example: {

        “name”: “mailing”

        “url”: “mails”

    }

Not audit-able

Whether the entity can or cannot be listed when using the REST API for auditing.

For details, see Auditing entities (technical preview).

Fields | Description
--- | ---
name | The name of the feature is a constant value: non-auditable. If this feature is listed for an entity, the entity does not appear during an audit.

    Example: {

        “name”: “non-auditable”

    }

History

Whether the entity can or cannot be listed when using the REST API for viewing history.

For details, see Viewing history (technical preview).

Fields | Description
--- | ---
name | The name of the feature is a constant value: history. If this feature is listed for an entity, the entity does appear when viewing history.

    Example: {

        “name”: “history”

    }

Drafts

Whether drafts of work items (epics, features, user stories, and defects) can be created.

Use drafts to bypass validation rules when POSTing work items via the API. This allows integrations using the API to quickly create work items without, for example, validating required fields.

For details, see Draft entities.

Fields | Description
--- | ---
name | The name of the feature is a constant value: draft_mode.

    Example: {

        “name”: “draft_mode”

    }

Attachments

Whether the entity supports attachments by accessing the <context>/attachments API.

Fields | Description
--- | ---
name | The name of the feature is a constant value: attachments. To add an attachment to entities that support this feature, reference the entity in the <context>/attachments request using the field on the attachment entity: owner_<entity name> Where entity name can be the entity name or the parent entity name, if the entity has the subtype of attribute. The actual field name can be queried via the field metadata API for the attachment entity. For details, see Field metadata reference. Example: owner_defect The attachment entity must have a reference to only one owner entity.

    Example: {

    {

        “name”: “attachments”

    }

Comments

Whether the entity supports comments by accessing the <context>/comments API.

Field | Description
--- | ---
name | The name of the feature is a constant value: comments. The actual field name can be queried via the field metadata API for the comment entity. For details, see Field metadata reference. Example: owner_defect The comment entity must have a reference to only one owner entity.

    Example: {

        “name”: “comments”

        “relation_name”: “comments_to_epic”

    }

Rules

Whether the entity supports rules.

Fields | Description
--- | ---
name | The name of the feature is a constant value: business_rules.

    Example: {

        “name”: “business_rules”

    }

Subtypes

Defines that the entity has subtypes.

Aggregated entities have a field called subtype, which stores the subtype of the entity instance. Similarly, the subtype instances have a field called subtype of, which indicates the aggregated entity to which they are related.

Fields | Description
--- | ---
name | The name of the feature is a constant value: subtypes.
types | A string array of the names of the entities, which are the subtypes of this entity.

    Example: {

        “name”: “subtypes”,

        “types”: [

            “defect”,

            “feature”,

            “epic”,

            “work_item_root”,

            “story”

        ]

    }

Subtype of

Defines that an entity is a subtype of another entity.

Entities that are a "subtype of" have a field called subtype of, which indicates the aggregated entity to which they are related. Similarly, aggregated entities have a field called subtype, which stores the subtype of the entity instance.

Fields | Description
--- | ---
name | The name of the feature is a constant value: subtype_of.
type | The name of the entity, which has this entity in the subtypes feature definition.

    Example: {

        “name”: “subtype_of”,

        “type”: “work_item”

    }

Phases

The ability to advance the status of the entity from phase-to-phase using the defined workflow is supported.

Fields | Description
--- | ---
name | The name of the feature is a constant value: phases.

    Example: {

        “name”: “phases”

    }

Hierarchy

Defines whether the entity is hierarchical.

Fields | Description
--- | ---
name | The name of the feature is a constant value: hierarchy.
root | The root entity in the hierarchy, with the following fields: type. The type of the root entity—often, work_item_root. id. The ID of the root entity. For non-empty arrays, multi-reference field by name children exists on the entity (this field will be defined in the fields metadata API). For non-empty arrays, reference field by name parents exists on the entity (this field will be defined in the fields metadata API). child_types. An array of strings, the allowed types for child entities. parent_types. An array of string, the allowed types for parent entities. max_depth. The maximum number of levels allowed in the hierarchy.

Example of the hierarchy feature for application modules (product areas).

This example shows how the hierarchy feature looks for the product_area entity (also known as application modules).

    Example: {

          "features": [
            {
              "methods": [
                "DELETE",
                "POST",
                "GET",
                "PUT"
              ],
              "name": "rest",
              "url": "product_areas"
            },
            {
              "parent_types": [
                "product_area"
              ],
              "max_depth": 4,
              "root": {
                "type": "product_area",
                "id": "1001"
              },
              "name": "hierarchy",
              "child_types": [
                "product_area"
              ]
            }
          ],
          "name": "product_area",
          "description": "Also known as an application module, a product area is a functional area of the application you are developing. Use product areas to test overall product quality (such as regression testing, end-to-end cross-feature testing).",
          "label": "Product Area",
          "type": "entity_metadata"
        },

Example of how the hierarchy feature looks for the feature entity with a subtype of work_item

    Example: {

          "features": [
            {
              "name": "mailing",
              "url": "mails"
            },
            {
              "name": "attachments",
            },
            {
              "parent_types": [
                "epic"
              ],
              "max_depth": 4,
              "root": {
                "type": "work_item_root",
                "id": "1001"
              },
              "name": "hierarchy",
              "child_types": [
                "defect",
                "story",
                "quality_story"
              ]
            },
            {
              "name": "comments",
            },
            {
              "name": "phases"
            },
            {
              "name": "subtype_of",
              "type": "work_item"
            },
            {
              "name": "user_defined_fields"
            },
            {
              "methods": [
                "DELETE",
                "POST",
                "GET",
                "PUT"
              ],
              "name": "rest",
              "url": "features"
            },
            {
              "name": "business_rules"
            }
          ],
          "name": "feature",
          "description": null,
          "label": "Feature",
          "type": "entity_metadata"
        },

Back to top

## Defect entity example

The entities resource returns metadata about the data returned for a member of a collection. Below is an example of the metadata for the defect entity.

            {
                "features": [
                    {
                        "parent_types": [
                            "feature",
                            "work_item_root"
                        ],
                        "max_depth": 4,
                        "root": {
                            "type": "work_item_root",
                            "id": "1001"
                        },
                        "name": "hierarchy",
                        "child_types": []
                    },
                    {
                        "methods": [
                            "DELETE",
                            "POST",
                            "GET",
                            "PUT"
                        ],
                        "name": "rest",
                        "url": "defects"
                    },
                    {
                        "name": "mailing",
                        "url": "mails"
                    },
                    {
                        "name": "attachments",
                    },
                    {
                        "name": "phases"
                    },
                    {
                        "name": "subtype_of",
                        "type": "work_item"
                    },
                    {
                        "name": "user_defined_fields"
                    },
                    {
                        "name": "comments",
                    },
                    {
                        "name": "business_rules"
                    }
                ],
                "name": "defect",
                "description": "A problem detected in the application.",
                "label": "Defect",
                "type": "entity_metadata"
            },

Back to top

See also:

- Field metadata reference
- Retrieving metadata
- Examples of retrieving metadata

https://admhelp.microfocus.com ALM Octane 8942
Tips to improve your search results... ALM Octane Help Center ALM Octane Help 15.1.90 All View Local Help Center View Online Help Center back Go back in browser history forward Go forward in browser history Remove search highlights next topic Go to next topic previous topic Go to previous topic Print the current topic Version: