You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by "Madhan Neethiraj (JIRA)" <ji...@apache.org> on 2018/04/25 19:46:00 UTC

[jira] [Comment Edited] (ATLAS-2607) Classification lifecycle through metadata properties and relationships

    [ 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)