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