[ https://issues.apache.org/jira/browse/ATLAS-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452955#comment-16452955 ]
Madhan Neethiraj edited comment on ATLAS-2607 at 4/25/18 7:45 PM: ------------------------------------------------------------------ bq. Asset can only be attached to classifications with the status of ACTIVE This implies that the status is on the classification-type - and not on the entity-classification association. I think having the status for entity-classification association would be more useful - like: PII => employee.ssn, PII => employee.phone_num, PII => customer.name bq. All new classifications after this change will start out with DRAFT status Clients that use current APIs will now know of this new attribute 'status'; they expect the classifications given in the API to be active, I think the default should be ACTIVE. Newer clients can choose to specify different value for status. bq. a steward or an admin with appropriate permissions can move them into an ACTIVE state Existing entity-classification-update permission will be used to enforce change to status; new new permission will be introduced for this. If this becomes necessary, I would suggest we take this up in a separate JIRA, post 1.0 release. was (Author: madhan.neethiraj): bq. Asset can only be attached to classifications with the status of ACTIVE This implies that the status is on the classification-type - and not on the entity-classification association. I think having the status for entity-classification association would be more useful - like: PII => employee.ssn, PII => employee.phone_num, PII => customer.name bq. All new classifications after this change will start out with DRAFT status and a steward or an admin with appropriate permissions can move them into an ACTIVE state Clients that use current APIs will now know of this new attribute 'status'; they expect the classifications given in the API to be active, I think the default should be ACTIVE. Newer clients can choose to specify different value for status. > Classification lifecycle through metadata properties and relationships > ---------------------------------------------------------------------- > > Key: ATLAS-2607 > URL: https://issues.apache.org/jira/browse/ATLAS-2607 > Project: Atlas > Issue Type: Improvement > Components: atlas-core > Reporter: Srikanth Venkat > Assignee: Madhan Neethiraj > Priority: Critical > > Currently tags or classifications in Atlas are considered active once they > are defined. For governance and stewardship purposes, it would be important > to attach the notion of what state in its lifecycle a particular > classification is. This would help with workflows to manage the lifecycle > aspects and provide any filtering needed to take appropriate actions. For > example only active classifications should be considered for classification > based policy enforcement. Additionally lifecycle status would help with > filtering and search as well as reporting and compliance/audit scenarios. > Implementation Proposal: > * All tags or classifications have a "Lifecycle Status" property > * They can go through the following list of states during their lifecycle: > DRAFT -> ACTIVE -> RETIRED > * Lifecycle Status can be set as an enum property that is mandatory or > required for all classifications. > * All existing classifications already present in Atlas before this change > will default to an ACTIVE status so that all pre-existing classifications > will continue to work as before. > * All new classifications after this change will start out with DRAFT status > and a steward or an admin with appropriate permissions can move them into an > ACTIVE state (controlled via Metadata security policies) > * Policy enforcement for authorization on classifications can ignore any > that are not in ACTIVE state. > * Asset can only be attached to classifications with the status of ACTIVE > * For a classification in RETIRED state, we might have an optional > relationship with another classification called "Replaced By" which is the > new classification that the current one was remapped or replaced with. The > inverse relationship could be labeled "Replaces" which is on the new > classification and points to the removed classification that it replaces. > * The state RETIRED implies this classification is no longer used and policy > enforcement will ignore any classifications in such states. > * Additionally UI can filter and show by default only classifications that > are not RETIRED and a checkbox to "Show Retired" > * Deletion of classifications should work as it currently does with no > behavioral changes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)