[SHA-315] [Delete] Delete an existing Model Created: 08-Jul-14  Updated: 17-Jul-20  Resolved: 01-Apr-15

Status: Done
Project: Share Application
Component/s: Share Application
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Major
Reporter: Mike Farman Assignee: Closed Issues
Resolution: Fixed Votes: 1
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 2 days, 6 hours, 30 minutes Time Spent: Not Specified
Σ Original Estimate: 2 days, 7 hours Original Estimate: Not Specified

Issue Links:
Dependency
Depends on SHA-317 [Create] Create a new Property Group Done
Depended on by SHA-293 [Editing Property Definitions] Proper... Done
Depended on by SHA-596 Implement QA Share tests defined in S... Done
Sub-Tasks:
Key
Summary
Type
Status
Assignee
SHA-453 Update REST API and backend service t... Sub-task Done Closed Bugs  
SHA-454 Update UI to support delete action Sub-task Done Closed Bugs  
SHA-455 Update Share PO Share tests for delete Sub-task Done Closed Bugs  
SHA-577 Update CMM service to support delete ... Sub-task Done Closed Bugs  
SHA-578 Define QA Share tests for delete Sub-task Done Closed Bugs  
SHA-627 Manual ad hoc testing for Delete an e... Sub-task Done Closed Bugs  
Epic Link: Custom Model Management
Sprint: CMM Sprint 3, CMM Sprint 4, CMM Sprint 5
Story Points: 1

 Description   

User Story:


"As a model manager I can delete a property group definition if it is in the DRAFT, DEPLOYED or PURGED states" so that it no longer appears in the list of Property Groups"

Notes:


  • It is not possible to delete an ACTIVE Property Group (as this means that it will be currently applied to existing nodes). In order to delete an ACTIVE Property Group it will be necessary to get an (overall) Admin to PURGE the Property Groups
  • We will need to perform a DB query to check that the Property Group is not in use (a Solr search will not be sufficient due to eventual consistency).
  • We will need to make a decision on whether or not to run the query for each Property Group to determine whether or not to show a delete action when the list is displayed - although since the information will immediately become stale it probably makes more sense to have a separate query to show deletable Property Groups and then run the DB query again when a delete action is performed

MF:
I'm wondering if we need a "disable group" capability so that a group can no longer be applied to documents, but can be viewed/searched or just hidden from the UI completely (so we don't have to remove all the properties)??



 Comments   
Comment by David Draper [X] (Inactive) [ 31-Oct-14 ]

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.

Comment by Mike Farman [ 31-Oct-14 ]

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

Comment by David Draper [X] (Inactive) [ 04-Nov-14 ]

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)
Comment by Andrew Hind [X] (Inactive) [ 07-Nov-14 ]

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 ....

Comment by Mike Farman [ 25-Nov-14 ]

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.

Comment by Christine Thompson [X] (Inactive) [ 22-Apr-15 ]

Setting Fix Version for first release

Generated at Sat Aug 15 21:30:16 BST 2020 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.