Review Request 72766: ATLAS-3920 : Harmonize joda-time to version 2.10.latest.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72766/ --- Review request for atlas, Madhan Neethiraj and Sarath Subramanian. Bugs: ATLAS-3920 https://issues.apache.org/jira/browse/ATLAS-3920 Repository: atlas Description --- Atlas currently uses outdated joda-time versions, which can cause issues. To avoid issue we need to update it to the latest version of joda-time. Diffs - pom.xml 5e0442a Diff: https://reviews.apache.org/r/72766/diff/1/ Testing --- The test cases passed and also tested basic features and they worked. Thanks, mayank jain
[jira] [Created] (ATLAS-3920) Harmonize joda-time to version 2.10.latest
Mayank Jain created ATLAS-3920: -- Summary: Harmonize joda-time to version 2.10.latest Key: ATLAS-3920 URL: https://issues.apache.org/jira/browse/ATLAS-3920 Project: Atlas Issue Type: Bug Reporter: Mayank Jain Atlas currently uses outdated joda-time versions, which can cause issues. To avoid issue we need to update it to the latest version of joda-time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3875) Adding missing APIs in AtlasClient with test cases
[ https://issues.apache.org/jira/browse/ATLAS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyoti Singh updated ATLAS-3875: --- Attachment: ATLAS-3875-2.patch > Adding missing APIs in AtlasClient with test cases > -- > > Key: ATLAS-3875 > URL: https://issues.apache.org/jira/browse/ATLAS-3875 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Jyoti Singh >Assignee: Jyoti Singh >Priority: Major > Labels: api, client > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3875-1.patch, ATLAS-3875-2.patch, > ATLAS-3875-4.patch > > > 1. There are many new APIs added to Atlas Project but the corresponding APIs > are missing from AtlasClientv2. The aim of this task is to complete the gap > amongst existing APIs and their endpoints in Atls client. This will also > include adding test cases via integration testing. > There are functions from AtlasClient for the following REST endpoints > * TypeRest > * EntityRest > * LineageRest > * DiscoveryRest > * GlossaryRest > * RelationshipRest > 2. Added Sample-Project to showcase how to integrate with Atlas using > AtlasCleint. This helps the user to understand the basic rest functionality > of Atlas. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3900) UI: Allow user to select the date range for date attribute in basic search
[ https://issues.apache.org/jira/browse/ATLAS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176583#comment-17176583 ] Sarath Subramanian commented on ATLAS-3900: --- Thanks for the patch [~kevalbhatt]. +1. > UI: Allow user to select the date range for date attribute in basic search > -- > > Key: ATLAS-3900 > URL: https://issues.apache.org/jira/browse/ATLAS-3900 > Project: Atlas > Issue Type: Sub-task > Components: atlas-webui >Affects Versions: 2.1.0 >Reporter: Keval Bhatt >Assignee: Keval Bhatt >Priority: Major > Labels: basic-search, datetimepicker > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3900-1.patch, ATLAS-3900-2.patch, > ATLAS-3900-3.patch, ATLAS-3900.patch, Screen Shot 2020-07-21 at 10.59.59 > PM.png, Screen Shot 2020-07-21 at 11.00.08 PM.png, Screen Shot 2020-07-21 at > 11.00.15 PM.png > > > In basic search attribute popup if the user selects the date type attribute > then UI should show a few quick search operator and custom range selection. > example: > !Screen Shot 2020-07-21 at 10.59.59 PM.png|width=631,height=282! > > !Screen Shot 2020-07-21 at 11.00.08 PM.png|width=630,height=302! > > !Screen Shot 2020-07-21 at 11.00.15 PM.png|width=630,height=304! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3919) Handling classification propagation as deferred-action
[ https://issues.apache.org/jira/browse/ATLAS-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarath Subramanian updated ATLAS-3919: -- Affects Version/s: 2.0.0 2.1.0 > Handling classification propagation as deferred-action > -- > > Key: ATLAS-3919 > URL: https://issues.apache.org/jira/browse/ATLAS-3919 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Jayendra Parab >Assignee: Jayendra Parab >Priority: Major > > Currently, whenever a user assigns a tag or updates a tag on an entity, it > gets propagated to all the entities derived from the tagged entity. This > operation takes quite a lot of time to complete (sometimes into minutes) and > causes usability issues on the UI and other clients invoking the REST API > To resolve this issue, tag-propagation needs to be handled as > deferred-action, so that time consuming like propagation, audits & > notifications can be processed in background threads -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ATLAS-3917) While deleting parent tag, shows incorrect message.
[
https://issues.apache.org/jira/browse/ATLAS-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chaitali borole reassigned ATLAS-3917:
--
Assignee: chaitali borole
> While deleting parent tag, shows incorrect message.
> ---
>
> Key: ATLAS-3917
> URL: https://issues.apache.org/jira/browse/ATLAS-3917
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Durga Kadam
>Assignee: chaitali borole
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: tag_with_{0}_reproducible.mkv
>
>
> Actual Behaviour - While deleting parent tag if the tag is not associated
> with any entity shows this message :: "Failed to delete classification
> 'parent_abc'. Given type \{0} has reference."
> Expected Result - There should be value instead of \{0}
> Steps to generate
> # Create tag with sub classification.
> # Don't associate the created parent tag with any of the entity
> # Try to delete the parent tag
> # Shows validation message with some encrypted value
>
> PFA Evidence file
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ATLAS-3917) While deleting parent tag, shows incorrect message.
[
https://issues.apache.org/jira/browse/ATLAS-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chaitali borole updated ATLAS-3917:
---
Description:
Actual Behaviour - While deleting parent tag if the tag is not associated with
any entity shows this message :: "Failed to delete classification 'parent_abc'.
Given type \{0} has reference."
Expected Result - There should be value instead of \{0}
Steps to generate
# Create tag with sub classification.
# Don't associate the created parent tag with any of the entity
# Try to delete the parent tag
# Shows validation message with some encrypted value
PFA Evidence file
was:
Actual Behaviour - While deleting parent tag if the tag is associated with any
entity shows this message :: "Failed to delete classification 'parent_abc'.
Given type \{0} has reference."
Expected Result - There should be value instead of \{0}
Steps to generate
# Create tag
# Associate the created tag with any of the entity
# Try to delete the tag
# Shows validation message with some encrypted value
PFA Evidence file
> While deleting parent tag, shows incorrect message.
> ---
>
> Key: ATLAS-3917
> URL: https://issues.apache.org/jira/browse/ATLAS-3917
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Durga Kadam
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: tag_with_{0}_reproducible.mkv
>
>
> Actual Behaviour - While deleting parent tag if the tag is not associated
> with any entity shows this message :: "Failed to delete classification
> 'parent_abc'. Given type \{0} has reference."
> Expected Result - There should be value instead of \{0}
> Steps to generate
> # Create tag with sub classification.
> # Don't associate the created parent tag with any of the entity
> # Try to delete the parent tag
> # Shows validation message with some encrypted value
>
> PFA Evidence file
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ATLAS-3900) UI: Allow user to select the date range for date attribute in basic search
[ https://issues.apache.org/jira/browse/ATLAS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keval Bhatt updated ATLAS-3900: --- Attachment: ATLAS-3900-3.patch > UI: Allow user to select the date range for date attribute in basic search > -- > > Key: ATLAS-3900 > URL: https://issues.apache.org/jira/browse/ATLAS-3900 > Project: Atlas > Issue Type: Sub-task > Components: atlas-webui >Affects Versions: 2.1.0 >Reporter: Keval Bhatt >Assignee: Keval Bhatt >Priority: Major > Labels: basic-search, datetimepicker > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3900-1.patch, ATLAS-3900-2.patch, > ATLAS-3900-3.patch, ATLAS-3900.patch, Screen Shot 2020-07-21 at 10.59.59 > PM.png, Screen Shot 2020-07-21 at 11.00.08 PM.png, Screen Shot 2020-07-21 at > 11.00.15 PM.png > > > In basic search attribute popup if the user selects the date type attribute > then UI should show a few quick search operator and custom range selection. > example: > !Screen Shot 2020-07-21 at 10.59.59 PM.png|width=631,height=282! > > !Screen Shot 2020-07-21 at 11.00.08 PM.png|width=630,height=302! > > !Screen Shot 2020-07-21 at 11.00.15 PM.png|width=630,height=304! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176262#comment-17176262 ] Yue Dong edited comment on ATLAS-3916 at 8/12/20, 11:03 AM: [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : *_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : *_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. was (Author: yued): [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176262#comment-17176262 ] Yue Dong edited comment on ATLAS-3916 at 8/12/20, 11:02 AM: [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. was (Author: yued): [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3916) Get metrics according to the user permissions
[ https://issues.apache.org/jira/browse/ATLAS-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176262#comment-17176262 ] Yue Dong commented on ATLAS-3916: - [~sarath] I get you point. I've tried to add the new functionality. The biggest problem I had was checking permissions of field EntityId (value of entity-unique attribute). It's what you comment, individual entities need to be checked according user permissions. So I had to add one more method to authorization interface, which * checks the permissions of AtlasPrivilege, entityTypes and classifications * and, if everything goes well, it will return a subquery that allows to scrub the entities which the user doesn't have access. With the new method, * when it is a user with EntityId restriction, the count query will be: _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (public_data* OR module_a*)_ * and when it is admin, the query will be: (Maybe it'd be better without _AND $v$"Referenceable.qualifiedName" : (*)_) _$v$"__typeName" : (hive_db) AND $v$"__state" : (ACTIVE) AND $v$"Referenceable.qualifiedName" : (*)_ And the new behavior of the method getMetrics is: * if the user does't have entities read or types permissions, the count query will not be executed. * if the user has restriction, like EntityId, the count query will be executed with authorization subquery. At the moment it seems to work fine for my requirement. Maybe I miss something, I can show you the code with a wip pull request if you want. I would like to help with this requirement. > Get metrics according to the user permissions > - > > Key: ATLAS-3916 > URL: https://issues.apache.org/jira/browse/ATLAS-3916 > Project: Atlas > Issue Type: New Feature > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Yue Dong >Priority: Major > Attachments: Captura-de-pantalla-de-2020-08-11-10-20-06.png > > > I have two user groups: admin who has access to all tables and reader can > only see public data and module A tables. So I have configured Atlas to use a > simple authorizer with a little variation, which is to hide entities that are > not accessible to the user. > The searches and displaying results work properly. > The only problem I find is that the metrics. In the elements of search by > type, it indicates the number of all the entities of each type in the system. > And this is not consistent with the search result of a reader user. > !Captura-de-pantalla-de-2020-08-11-10-20-06.png! > > I have verified that these numbers come from the getMetrics method, which is > not secured so it does not obtain the numbers according to the users' > configuration. Am I missing something? Is there any way to change these > numbers? > Maybe it'd be nice to have something that allows to modify the querys of the > metrics based on security and authorization, like > AtlasAuthorizer.scrubSearchResults in search methods. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Review Request 72698: ATLAS-3875: Introduce sample project for AtlasClient
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72698/#review221556 --- Ship it! Ship It! - Madhan Neethiraj On Aug. 4, 2020, 4:27 p.m., Jyoti Singh wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72698/ > --- > > (Updated Aug. 4, 2020, 4:27 p.m.) > > > Review request for atlas, Ashutosh Mestry, Madhan Neethiraj, Sarath > Subramanian, and Sidharth Mishra. > > > Bugs: ATLAS-3875 > https://issues.apache.org/jira/browse/ATLAS-3875 > > > Repository: atlas > > > Description > --- > > Using this project users can get an idea as how to integrate with Atlas using > AtlasCleint. This helps the user to understand the basic rest functionality > of Atlas such as > > - EntityRest > - TypeDefRest > - DiscoveryRest > - LineageRest > - GlossaryRest > > > Diffs > - > > atlas-examples/pom.xml PRE-CREATION > atlas-examples/sample-app/README.md PRE-CREATION > atlas-examples/sample-app/pom.xml PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/DiscoveryExample.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/EntityExample.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/GlossaryExample.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/LineageExample.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/SampleApp.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/SampleAppConstants.java > PRE-CREATION > > atlas-examples/sample-app/src/main/java/org/apache/atlas/examples/sampleapp/TypeDefExample.java > PRE-CREATION > atlas-examples/sample-app/src/main/resources/atlas-application.properties > PRE-CREATION > pom.xml 5e0442ae5 > > > Diff: https://reviews.apache.org/r/72698/diff/7/ > > > Testing > --- > > > Thanks, > > Jyoti Singh > >
[jira] [Commented] (ATLAS-3875) Adding missing APIs in AtlasClient with test cases
[ https://issues.apache.org/jira/browse/ATLAS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176061#comment-17176061 ] ASF subversion and git services commented on ATLAS-3875: Commit b7255ec7e24f87da6f2dba47965a4e22e94c2250 in atlas's branch refs/heads/master from jyoti0208 [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=b7255ec ] ATLAS-3875: adding sample client change Signed-off-by: Madhan Neethiraj > Adding missing APIs in AtlasClient with test cases > -- > > Key: ATLAS-3875 > URL: https://issues.apache.org/jira/browse/ATLAS-3875 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.0.0, 2.1.0 >Reporter: Jyoti Singh >Assignee: Jyoti Singh >Priority: Major > Labels: api, client > Fix For: 3.0.0, 2.2.0 > > Attachments: ATLAS-3875-1.patch, ATLAS-3875-4.patch > > > 1. There are many new APIs added to Atlas Project but the corresponding APIs > are missing from AtlasClientv2. The aim of this task is to complete the gap > amongst existing APIs and their endpoints in Atls client. This will also > include adding test cases via integration testing. > There are functions from AtlasClient for the following REST endpoints > * TypeRest > * EntityRest > * LineageRest > * DiscoveryRest > * GlossaryRest > * RelationshipRest > 2. Added Sample-Project to showcase how to integrate with Atlas using > AtlasCleint. This helps the user to understand the basic rest functionality > of Atlas. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ATLAS-3919) Handling classification propagation as deferred-action
Jayendra Parab created ATLAS-3919: - Summary: Handling classification propagation as deferred-action Key: ATLAS-3919 URL: https://issues.apache.org/jira/browse/ATLAS-3919 Project: Atlas Issue Type: Improvement Components: atlas-core Reporter: Jayendra Parab Assignee: Jayendra Parab Currently, whenever a user assigns a tag or updates a tag on an entity, it gets propagated to all the entities derived from the tagged entity. This operation takes quite a lot of time to complete (sometimes into minutes) and causes usability issues on the UI and other clients invoking the REST API To resolve this issue, tag-propagation needs to be handled as deferred-action, so that time consuming like propagation, audits & notifications can be processed in background threads -- This message was sent by Atlassian Jira (v8.3.4#803005)
