Open APIs

------------------------------
Satish Kumar
------------------------------

Hi Satish

Sub-classing the Permission[Set]Specification for a Permission[Set] instance will break the entitySpec/entity pattern.  Rather than adding your extended status field, it may be better to add the entitySpecification lifecycleStatus and version fields to the Permission[Set]Specification.  I can raise a JIRA ticket on this in TM Forum and you can temporarily add these fields to your version of the TMF672 OAS.

Note that there have been considerable changes between the TMF672 v4 and v5 APIs.  Permission in v4 has been replaced with a PermissionSet instead.  The permissions within the PermissionSet are embedded permissions.

Otherwise, in terms of your polymorphism fields, these are generally correct except perhaps you could use something like @type=PermissionSetSpecificationExtension (rather than PermissionSet the entity/instance).

Thanks Lutz and Dan for your response.

In v5 spec, for a permissionSet resource, I see the payload / spec has these two fields in request:
> permission. (permission also has a permissionSpecificationSet)

> permissionSetSpecification

So what is the difference between "permissionSpecificationSet" inside "permission" field and the "permissionSetSpecification". The reference class for both of them is same- "PermissionSpecificationSetRef".

Thanks,

Satish

Hi Satish

Sub-classing the Permission[Set]Specification for a Permission[Set] instance will break the entitySpec/entity pattern.  Rather than adding your extended status field, it may be better to add the entitySpecification lifecycleStatus and version fields to the Permission[Set]Specification.  I can raise a JIRA ticket on this in TM Forum and you can temporarily add these fields to your version of the TMF672 OAS.

Note that there have been considerable changes between the TMF672 v4 and v5 APIs.  Permission in v4 has been replaced with a PermissionSet instead.  The permissions within the PermissionSet are embedded permissions.

Otherwise, in terms of your polymorphism fields, these are generally correct except perhaps you could use something like @type=PermissionSetSpecificationExtension (rather than PermissionSet the entity/instance).

Hi Satish

The permissionSetSpecification tied to the permissionSet resource is for the implicit permissions automatically assigned to the party playing a PartyRole.  When the PartyRole is instatiated for the Party, a PermissionSet (implicit) should be created at the same time, based on the association between the PartyRoleSpecification and the PermissionSpecificationSet.

The permission field within PermissionSet is for assigning a permission or permissions (set) relating to specific managed entities, e.g. a specific Product.

Jonathan Goldberg wrote a summary of this API on the TM Forum wiki at TMF672 User Role Permission API V5.0.0 - Open API Project - TM Forum Confluence

Hope this helps

Thanks Lutz and Dan for your response.

In v5 spec, for a permissionSet resource, I see the payload / spec has these two fields in request:
> permission. (permission also has a permissionSpecificationSet)

> permissionSetSpecification

So what is the difference between "permissionSpecificationSet" inside "permission" field and the "permissionSetSpecification". The reference class for both of them is same- "PermissionSpecificationSetRef".

Thanks,

Satish

Hi Satish

Sub-classing the Permission[Set]Specification for a Permission[Set] instance will break the entitySpec/entity pattern.  Rather than adding your extended status field, it may be better to add the entitySpecification lifecycleStatus and version fields to the Permission[Set]Specification.  I can raise a JIRA ticket on this in TM Forum and you can temporarily add these fields to your version of the TMF672 OAS.

Note that there have been considerable changes between the TMF672 v4 and v5 APIs.  Permission in v4 has been replaced with a PermissionSet instead.  The permissions within the PermissionSet are embedded permissions.

Otherwise, in terms of your polymorphism fields, these are generally correct except perhaps you could use something like @type=PermissionSetSpecificationExtension (rather than PermissionSet the entity/instance).

Thanks Dan for clarifying the above.

TMF672 also has notification event endpoints. But currently our specific implementation doesnt require any notifications to be sent.

So, Is it also mandatory to implement those endpoints when following TMF672 spec?

Hi Satish

The permissionSetSpecification tied to the permissionSet resource is for the implicit permissions automatically assigned to the party playing a PartyRole.  When the PartyRole is instatiated for the Party, a PermissionSet (implicit) should be created at the same time, based on the association between the PartyRoleSpecification and the PermissionSpecificationSet.

The permission field within PermissionSet is for assigning a permission or permissions (set) relating to specific managed entities, e.g. a specific Product.

Jonathan Goldberg wrote a summary of this API on the TM Forum wiki at TMF672 User Role Permission API V5.0.0 - Open API Project - TM Forum Confluence

Hope this helps

Thanks Lutz and Dan for your response.

In v5 spec, for a permissionSet resource, I see the payload / spec has these two fields in request:
> permission. (permission also has a permissionSpecificationSet)

> permissionSetSpecification

So what is the difference between "permissionSpecificationSet" inside "permission" field and the "permissionSetSpecification". The reference class for both of them is same- "PermissionSpecificationSetRef".

Thanks,

Satish

Hi Satish

Sub-classing the Permission[Set]Specification for a Permission[Set] instance will break the entitySpec/entity pattern.  Rather than adding your extended status field, it may be better to add the entitySpecification lifecycleStatus and version fields to the Permission[Set]Specification.  I can raise a JIRA ticket on this in TM Forum and you can temporarily add these fields to your version of the TMF672 OAS.

Note that there have been considerable changes between the TMF672 v4 and v5 APIs.  Permission in v4 has been replaced with a PermissionSet instead.  The permissions within the PermissionSet are embedded permissions.

Otherwise, in terms of your polymorphism fields, these are generally correct except perhaps you could use something like @type=PermissionSetSpecificationExtension (rather than PermissionSet the entity/instance).