Mike Farman The concept of disabling a group was something that I discussed with JN.... I also think it would be useful to have a "DRAFT" state as well, to prevent a Property Group being used before it is ready. There definitely needs to be a well established life-cycle for them.

David Draper [X]Yep, absolutely having a life-cycle makes a lot of sense

I was thinking about the lifecycle stages and think we should have (as a minimum):

• DRAFT (an XML file has been created and placed into the Data Dictionary/Models folder but it is not marked as active)
  • When a Property Group is in DRAFT it can be re-named and can have properties, constraints and include Property Groups freely manipulated
• DEPLOYED (the XML file is marked active AND the Share configuration is updated so that the Property Group can be applied to Nodes)
  • This state indicates that whilst a Property Group could be used it is not currently applied to any nodes so it can still freely be edited
• ACTIVE (the active model has now been applied to a Node
  • This state is where we need to be very careful about what we allow the user to do. Initially I would suggest that we lock-out editing completely until we have some functional code and then explore what is going to be possible
• DISABLED (the model is active, but is removed from the Share configuration so that it can no longer be manually added)
  • Not sure how we'd handle rules that apply the Property Group
• PURGED (the model is no longer active and has been removed from all Nodes - only the Admin will be able to do this)

The life-cycle stages are fine but I would like more clarity on what they mean and what may affect the transitions.
The life-cycle of the model/types etc in the dictionary do not match.

Are there life-cycles for models and the things the model contains?
Can a DEPLOYED model contain a DRAFT aspect/secondary type/property group, etc ?

In the DRAFT stage the models and all they contain will not be in the dictionary as they are not active.
There may be class/property name collisions that prevent deployment - particularly if they use and existing namespace.

I am not clear if property groups are independent or can inherit/combine others which introduces life-cycle relationships.

DEPLOYED -> ACTIVE is an uncontrolled transition - and could happen at any time.
I suggest DEPLOYED means "it" can not be applied to a node and you explicitly activate a "thing" when you are ready.
Indeed you can change it and you can delete it - with only restrictions on dependent models.
It is live in the dictionary and you know it is OK.

Currently all models loaded in the dictionary will only allow limited changes to be applied unless they are removed first.
So you would have to go back to DRAFT to perform most editing (like renaming - and thereby deleting a property)

Restrictions upon changes that can be made to ACTIVE models I believe are addressed in the CMIS 1.1 spec.
Nothing is a good start! I would think adding a property should be next. (Do properties have a life-cyle if they are on an live property group?)

DISABLED on the repository seems to imply deprecation of some sort. The aspect can exists but can NOT be applied.
It is not only share that needs to understand this.

I would prefer a state where the aspect/property is being purged/removed.
I assume removal means take off the aspect and its properties - which will take time.
Then we are back to DEPLOYED and the model could be deleted/updated ....

The intention at this stage is manage the model lifecycle from a UI perspective only, it would still be possible to work with the model that was disabled i.e. programatically, at least for this user story. Enforcement of livecycle states at the repo level should be address as a separate set of stories.

For this story, a deletion would require a DB query to check for the usage of the property group i.e. it's aspect(s) (maxitems>=1). If, it was in use an error along the lines of "cannot be deleted, property group (or aspect name(s)) in use". The is not an expectation that any any automatic cleanup/removal is provided as part of this story. It would be up to an admin to tidy this up.

Setting Fix Version for first release