Add Approve and Reject schema actions

[at055612]

There is currently no sensible way of modelling a the approval/acceptance/rejection of an entity in the schema. For example being able to approve/reject a licence agreement or acceptable use policy.

[burnalting]

As opposed to extending the 'base' event activity, couldn't this be a variation of the Authorise activity and we extend the AuthoriseType to extend the Action enumeration and add generic objects other than Groups.

Basically, I am weary of extending the activities of Alert thru to View

[at055612]

Burn, if I understand you correctly Authorise/Action would have the following enumerations (those with a * being new):

Request
Modify
Approve *
Reject *

and (Add|Remove)Groups would become (Add|Remove) (with a child of 1-* BaseMultiObjectComplexType).

Is this what you meant?

What is your objection to adding additional 'schema action' elements (e.g. create, view, etc.)?

It is unfortunate that Authorise is badly named as the name implies an action different to what the element captures.

An alternative would be model group changes as an Update with the Before and After describing what has changed, though this would make it harder to isolate these sort of authorisation related changes from other changes.

[burnalting]

Yes, the modifications to Authorise/Action and the extension/transformation of the 'Object of the action' is what I meant.

My main concern about adding new schema actions is to ensure we haven't already got an action that covers the concept (this makes the use of the schema simpler). In this case 'approval' activity is, I believe, a variation of the Authorise concept so we already have the 'action'. Yes, we originally aligned the Authorise to 'groups' resulting in it's limited versatility. The changes you recommend mean we can extend the use of Authorise rather than add new constructs. There is a problem to this methodology ... changes become difficult to just be additive ... here you are proposing to transform (Add|Remove)Groups to just (Add|Remove) which means, in an expanding use of the schema, we would have to re-generate or transform existing (Add|Remove)Groups into (Add|Remove) elements to have eventual consistency. But perhaps this is the life of a living schema. That said, the mapping of these two wouldn't be difficult in a schema version uplift translation. If we make the change, perhaps we should document the recommended uplift transformation?

As for the different modeling (using an Update) we still have the EventDetail/TypeId or if need be EventDetail//Object/TypeId

[burnalting]

A further thought to this, we should ensure we have an Other option in the Authorise/Action enumeration to cater for the some Authorise activity we haven't thought of yet. Naturally, one would then use the EventDetail/(TypeId|Description) to add clarity

[burnalting]

I would further add Accept to the Authorisation/Action enumeration to cover @10's initial request.

[at055612]

Fixed in >v3.3.1