Custom Attributes Ownership

overview custom attribute ownership (cao) enables developers to build apps with custom attributes across multiple applications within os1 os1 consists of various objects, including integrate with participants docid\ qhbysf19f9yhlhvxlb8ch , integrate with containers docid\ xrf39 iqpntv6dg37nykv , and integrate with entities docid\ oik2vd8yk0gtaeqocejr6 , each with predefined attributes that dictate their properties in addition to these system defined attributes, developers can also create custom attributes tailored to their specific use case in a multi app environment, developers may have several applications that utilize a single object to maintain security and data integrity, developers can regulate read and write access to an object’s attributes in one application, preventing unauthorized modifications by other applications how it works imagine a glossary docid 5r4rg4kdqdwoz0jop70dq organization (t1) with three distinct applications (app1, app2, and app3) allowing each application the authority to create or update any custom attribute within the ecosystem could raise security and consistency concerns for example, if app1 creates a “phone number” attribute, app2 and app3 could potentially modify it without limitations cao addresses this issue by granting tenant control over every attribute in their environment, regardless of the application by implementing this framework, a tenant can effectively manage custom attribute access, enhancing security and ensuring data consistency across all applications key components the objecttypeowner (oto) and customattributeowner (cao) apps are integral components in managing object types and custom attributes within os1 the oto app is responsible for creating and maintaining object types, while the cao app is in charge of managing custom attributes for specific object types both apps work together to ensure proper control and permissions over object types and their associated custom attributes, thus enhancing data security and collaboration between different apps objecttypeowner (oto) app the oto app is designed to establish and manage object types and designating ownership, such as a vehicle being a participanttype of the participant object or a box being a containertype of the container object using the application example above, when app1 uses the participant api to create an vehicle object type, it becomes the oto for vehicle and gains control over any custom attributes added to it as the oto, app1 can grant read/write permissions to other apps for the vehicle’s custom attributes, ensuring secure data access and collaboration customattributeowner (cao) app the cao app focuses on creating and managing attributes for object types for instance, if app1 (oto for vehicle) grants app2 permission to create custom attributes, and app2 creates the registration no attribute for the vehicle object type, app2 becomes the cao for registration no and controls read/write permissions for this attribute similarly, if app1 creates the model attribute for vehicle , it also becomes the cao for model key controls under this framework, the tenant has the following controls the oto app controls the addition of new custom attributes, preventing irrelevant or duplicate attributes the cao app defines access levels to control information sharing between apps all read/write requests for data should go through the oto app, rather than directly interacting with os1, to maintain secure data management attribute creation flow granting app permissions for custom attribute creation the oto grants permission to an application to create custom attributes using an offline procedure app developers can include a request for this permission in the access control yaml file as part of their app submission once the app is deployed, it will have access to the required apis for creating new attributes creating custom attributes once the application has been granted the appropriate permissions, it can create custom attributes using the existing /config/attribute put endpoint to add a custom attribute for a specified objecttype granting read access while adding a custom attribute, the cao can define what apps can read the custom attribute to provide read permissions to other apps, use the put /config/attribute endpoint keep in mind that write access remains exclusively available to the cao by default, the oto app has read access to any custom attributes defined by other apps to specify whether a custom attribute is publicly readable, include the isreadpublic parameter when creating attributes see the example request body below "attributes" \[ { "name" "capacity value", "description" "volume", "datatype" "number", "indexed" true “isreadpublic” “true”, "validation" { "required" false } }, in this context, the isreadpublic parameter can have the following values true grants read access to all apps for the custom attribute false (default) restricts read access to the cao only defining custom attributes to define custom attributes for participanttype , containertype, and entitytype , refer to the following how to guide how to define participant attributes