Re: Review Request 73618: RANGER-3458: Add rest api to get policy delta for given resource

2021-10-27 Thread Pradeep Agrawal

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73618/
---

(Updated Oct. 28, 2021, 5:40 a.m.)


Review request for ranger.


Bugs: RANGER-3458
https://issues.apache.org/jira/browse/RANGER-3458


Repository: ranger


Description
---

**Problem Statement:**  To find incremental diff of policy changes for specific 
resource a specific API is needed and available API(mentioned below) does not 
give the results as expected.
API-1: policy download API used by 
plugins(/service/plugins/policies/download/{serviceName}) => This API can give 
the delta, however it does not filter for required resource set, also call for 
specific policyVersion might change the existing policy set in the cache.
API-2: for-resource API 
(/service/plugins/policies/{serviceDefName}/for-resource) => This API can give 
the set of policies for specific resource but can't give policy delta or 
changed policies set after a specific version.

**Proposed solution :** : 
Proposed solution contains the feature of both the API mentioned above and 
creates a separate policy engine and do not refer the existing policy engine 
used by plugins. 
This API can accept resource set and last synced policy version to figure out 
the policies changed after that. If delta could not figured out then it shall 
return all policies matching with provided resource. 
If policy has been deleted then it shall return guid of the policy with 
changetype 2('deleted')


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/plugin/model/RangerPolicyDelta.java
 5292a98cb 
  
security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java 
5a69231ef 
  security-admin/src/main/java/org/apache/ranger/db/XXPolicyChangeLogDao.java 
137b24100 
  security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
01e952a23 
  security-admin/src/main/resources/META-INF/jpa_named_queries.xml 96dc0df8e 


Diff: https://reviews.apache.org/r/73618/diff/2/

Changes: https://reviews.apache.org/r/73618/diff/1-2/


Testing
---

Tested the API with various resource combinations and lastKnownVersion.


Thanks,

Pradeep Agrawal



Re: Review Request 73618: RANGER-3458: Add rest api to get policy delta for given resource

2021-10-27 Thread Abhay Kulkarni

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73618/#review223678
---




security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java
Lines 111 (patched)


Please consider making this method and addPolicyAdmin method static. Then 
this method can be directly invoked from ServiceREST code.

Also, this method is too long. Please consider refactoring it into smaller, 
private methods.



security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java
Lines 118 (patched)


Please add ingress/egress logging messages for debugging help.



security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java
Lines 181 (patched)


Why is this an error? Please review this and line 190.



security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java
Lines 206 (patched)


If deltas are not enabled, how will the deleted policies (which would have 
matched the resource) be handled?



security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCacheForEngineOptions.java
Lines 74 (patched)


Please consider removing this method.



security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java
Lines 632 (patched)


Please consider calling static method in the RangerPolicyAdminCache 
directly from here.



security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java
Lines 3734 (patched)


Please consider removing this method.


- Abhay Kulkarni


On Sept. 29, 2021, 10:08 a.m., Pradeep Agrawal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73618/
> ---
> 
> (Updated Sept. 29, 2021, 10:08 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-3458
> https://issues.apache.org/jira/browse/RANGER-3458
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> **Problem Statement:**  To find incremental diff of policy changes for 
> specific resource a specific API is needed and available API(mentioned below) 
> does not give the results as expected.
> API-1: policy download API used by 
> plugins(/service/plugins/policies/download/{serviceName}) => This API can 
> give the delta, however it does not filter for required resource set, also 
> call for specific policyVersion might change the existing policy set in the 
> cache.
> API-2: for-resource API 
> (/service/plugins/policies/{serviceDefName}/for-resource) => This API can 
> give the set of policies for specific resource but can't give policy delta or 
> changed policies set after a specific version.
> 
> **Proposed solution :** : 
> Proposed solution contains the feature of both the API mentioned above and 
> creates a separate policy engine and do not refer the existing policy engine 
> used by plugins. 
> This API can accept resource set and last synced policy version to figure out 
> the policies changed after that. If delta could not figured out then it shall 
> return all policies matching with provided resource. 
> If policy has been deleted then it shall return guid of the policy with 
> changetype 2('deleted')
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/RangerPolicyDelta.java
>  5292a98cb 
>   
> security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCache.java
>  a6f0a1a2a 
>   
> security-admin/src/main/java/org/apache/ranger/biz/RangerPolicyAdminCacheForEngineOptions.java
>  224bdc258 
>   security-admin/src/main/java/org/apache/ranger/db/XXPolicyChangeLogDao.java 
> 8a1719fcd 
>   security-admin/src/main/java/org/apache/ranger/rest/ServiceREST.java 
> f1123d19c 
>   security-admin/src/main/resources/META-INF/jpa_named_queries.xml ab2d9cd0d 
> 
> 
> Diff: https://reviews.apache.org/r/73618/diff/1/
> 
> 
> Testing
> ---
> 
> Tested the API with various resource combinations and lastKnownVersion.
> 
> 
> Thanks,
> 
> Pradeep Agrawal
> 
>



[jira] [Resolved] (RANGER-3319) Ranger usersync cookie default duration for sync

2021-10-27 Thread Sailaja Polavarapu (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Polavarapu resolved RANGER-3319.

Fix Version/s: 2.2.0
   Resolution: Fixed

> Ranger usersync cookie default duration for sync
> 
>
> Key: RANGER-3319
> URL: https://issues.apache.org/jira/browse/RANGER-3319
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1
>Reporter: Konstantin Tsypin
>Assignee: Sailaja Polavarapu
>Priority: Major
> Fix For: 2.2.0
>
>
> Hi!
> At this moment we cant initial sync out of the box our LDAP with 10k+ users & 
> groups.
> It's because sync works as three steps:
> 1) Sync groups
> 2) Sync users
> 3) Map users&groups as one request and send it to rangeradmin
> From time to time our third step on initial sync generate this single request 
> for a long time
> It can be easily three or four hours.
> Acrossing this timegate we have an error with timeout usersync cookie (that 
> by default is 60 minutes) and failed 3rd step.
>  
> The workaround - is 
> ranger_admin_directory/ews/webapp/WEB-INF/web.xml
> change 
> default 
> 60 
> to just in case
> 1440
> BUT im was really frustrated with this behavior whan faced it first time, and 
> i want to have a mechanism to split mapping step for a smaller part, and 
> update cookie from time to time. 
>  
> Thank you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (RANGER-3319) Ranger usersync cookie default duration for sync

2021-10-27 Thread Sailaja Polavarapu (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Polavarapu reassigned RANGER-3319:
--

Assignee: Sailaja Polavarapu

> Ranger usersync cookie default duration for sync
> 
>
> Key: RANGER-3319
> URL: https://issues.apache.org/jira/browse/RANGER-3319
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1
>Reporter: Konstantin Tsypin
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> Hi!
> At this moment we cant initial sync out of the box our LDAP with 10k+ users & 
> groups.
> It's because sync works as three steps:
> 1) Sync groups
> 2) Sync users
> 3) Map users&groups as one request and send it to rangeradmin
> From time to time our third step on initial sync generate this single request 
> for a long time
> It can be easily three or four hours.
> Acrossing this timegate we have an error with timeout usersync cookie (that 
> by default is 60 minutes) and failed 3rd step.
>  
> The workaround - is 
> ranger_admin_directory/ews/webapp/WEB-INF/web.xml
> change 
> default 
> 60 
> to just in case
> 1440
> BUT im was really frustrated with this behavior whan faced it first time, and 
> i want to have a mechanism to split mapping step for a smaller part, and 
> update cookie from time to time. 
>  
> Thank you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (RANGER-3319) Ranger usersync cookie default duration for sync

2021-10-27 Thread Sailaja Polavarapu (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434898#comment-17434898
 ] 

Sailaja Polavarapu edited comment on RANGER-3319 at 10/27/21, 3:08 PM:
---

[~fullhouse],

>> 3) Map users&groups as one request and send it to rangeradmin

>From time to time our third step on initial sync generate this single request 
>for a long time

It can be easily three or four hours.

>>>

This issue is fixed as part of RANGER-3374

 Please give it a try and re-open if the issue still exists.


was (Author: spolavarapu):
[~fullhouse],

>> 3) Map users&groups as one request and send it to rangeradmin

>From time to time our third step on initial sync generate this single request 
>for a long time

It can be easily three or four hours.

>>>

This issue is fixed as part of RANGER-3374

 

> Ranger usersync cookie default duration for sync
> 
>
> Key: RANGER-3319
> URL: https://issues.apache.org/jira/browse/RANGER-3319
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1
>Reporter: Konstantin Tsypin
>Priority: Major
>
> Hi!
> At this moment we cant initial sync out of the box our LDAP with 10k+ users & 
> groups.
> It's because sync works as three steps:
> 1) Sync groups
> 2) Sync users
> 3) Map users&groups as one request and send it to rangeradmin
> From time to time our third step on initial sync generate this single request 
> for a long time
> It can be easily three or four hours.
> Acrossing this timegate we have an error with timeout usersync cookie (that 
> by default is 60 minutes) and failed 3rd step.
>  
> The workaround - is 
> ranger_admin_directory/ews/webapp/WEB-INF/web.xml
> change 
> default 
> 60 
> to just in case
> 1440
> BUT im was really frustrated with this behavior whan faced it first time, and 
> i want to have a mechanism to split mapping step for a smaller part, and 
> update cookie from time to time. 
>  
> Thank you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (RANGER-3319) Ranger usersync cookie default duration for sync

2021-10-27 Thread Sailaja Polavarapu (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434898#comment-17434898
 ] 

Sailaja Polavarapu commented on RANGER-3319:


[~fullhouse],

>> 3) Map users&groups as one request and send it to rangeradmin

>From time to time our third step on initial sync generate this single request 
>for a long time

It can be easily three or four hours.

>>>

This issue is fixed as part of RANGER-3374

 

> Ranger usersync cookie default duration for sync
> 
>
> Key: RANGER-3319
> URL: https://issues.apache.org/jira/browse/RANGER-3319
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 2.1.0, 2.0.1, 2.2.0, 2.1.1
>Reporter: Konstantin Tsypin
>Priority: Major
>
> Hi!
> At this moment we cant initial sync out of the box our LDAP with 10k+ users & 
> groups.
> It's because sync works as three steps:
> 1) Sync groups
> 2) Sync users
> 3) Map users&groups as one request and send it to rangeradmin
> From time to time our third step on initial sync generate this single request 
> for a long time
> It can be easily three or four hours.
> Acrossing this timegate we have an error with timeout usersync cookie (that 
> by default is 60 minutes) and failed 3rd step.
>  
> The workaround - is 
> ranger_admin_directory/ews/webapp/WEB-INF/web.xml
> change 
> default 
> 60 
> to just in case
> 1440
> BUT im was really frustrated with this behavior whan faced it first time, and 
> i want to have a mechanism to split mapping step for a smaller part, and 
> update cookie from time to time. 
>  
> Thank you.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Request to add me as a contributor in Ranger

2021-10-27 Thread Velmurugan Periasamy
Hi Xuze Yang: 

Thanks for your interest in contributing to Ranger. I have added you as 
contributor. 

Welcome to Apache Ranger Dev community. 

Thanks.

On Wed, Oct 27, 2021 at 10:42 AM 杨旭泽  wrote:
Hi Team,



I would request to add me as a contributor in  Apache Ranger. I want that 
RANGER-3500 be assigned to me, and I will upload the available patches later.




My credentials are:

My github username is: yangxuze

And my email id is xuze_y...@163.com 

--

Regards

Xuze Yang

[jira] [Assigned] (RANGER-3500) Ranger policy list doesn't support sorting by field

2021-10-27 Thread Velmurugan Periasamy (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Velmurugan Periasamy reassigned RANGER-3500:


Assignee: Xuze Yang

> Ranger policy list doesn't support sorting by field
> ---
>
> Key: RANGER-3500
> URL: https://issues.apache.org/jira/browse/RANGER-3500
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.1.0
>Reporter: Xuze Yang
>Assignee: Xuze Yang
>Priority: Major
>
> When getting the ranger policy list, we may want to sort the returned policy 
> list according to certain fields, such as policyId, policyName and etc. But 
> case shows that adding the parameters sortBy and sortType to the url has no 
> effect (eg: 
> [http://192.168.0.12:6080/service/plugins/]policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs).
>  I look through the source code and find that code supports sorting by 
> fields, but due to some code bugs, it did not really take effect. 
>  The main reason for the problem is that when the SearchFilter is copied 
> deeply, only the params is copied, the sortBy and sortType attributes is 
> omitted. The code show as follows:
> {code:java}
> Map paramsCopy  = new HashMap<>(filter.getParams());
> SearchFilter   searchFilter = new SearchFilter(paramsCopy);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Request to add me as a contributor in Ranger

2021-10-27 Thread 杨旭泽
Hi Team,



I would request to add me as a contributor in  Apache Ranger. I want that 
RANGER-3500 be assigned to me, and I will upload the available patches later.




My credentials are:

My github username is: yangxuze

And my email id is xuze_y...@163.com

-- 

Regards

Xuze Yang

Re: Permissions

2021-10-27 Thread Velmurugan Periasamy
Hi Pierre - I have added you in wiki to have edit permissions. Thanks for your 
interest in contributing. 

On Wed, Oct 27, 2021 at 3:24 AM Pierre Smits  wrote:
Ping?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz > since
2008 (without privileges)

*Apache Trafodion >, Vice President*
*Apache Directory >, PMC Member*
Apache Incubator >, committer
Apache Steve >, committer


On Tue, Oct 26, 2021 at 12:32 PM Pierre Smits mailto:pierresm...@apache.org>>
wrote:

> Hi all,
>
> I want to contribute. Please provide me with permissions to the wiki.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  > since
> 2008 (without privileges)
>
> *Apache Directory  >, PMC Member*
> Apache Incubator  >, committer
> Apache Steve >, committer
>

[jira] [Commented] (RANGER-3500) Ranger policy list doesn't support sorting by field

2021-10-27 Thread Xuze Yang (Jira)


[ 
https://issues.apache.org/jira/browse/RANGER-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434853#comment-17434853
 ] 

Xuze Yang commented on RANGER-3500:
---

In addition, in the method of sorting the policy list, only the sortBy field is 
used, and the sortType field is not used. so all sorts are 'asc'. We need to 
modify the sorting method to support 'desc' too. So The code can be modified as 
follows:
1. When deep copying SearchFilter, add a copy of sortBy and sortType fields
2. Modify the sorting method to support 'desc'

> Ranger policy list doesn't support sorting by field
> ---
>
> Key: RANGER-3500
> URL: https://issues.apache.org/jira/browse/RANGER-3500
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.1.0
>Reporter: Xuze Yang
>Priority: Major
>
> When getting the ranger policy list, we may want to sort the returned policy 
> list according to certain fields, such as policyId, policyName and etc. But 
> case shows that adding the parameters sortBy and sortType to the url has no 
> effect (eg: 
> [http://192.168.0.12:6080/service/plugins/]policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs).
>  I look through the source code and find that code supports sorting by 
> fields, but due to some code bugs, it did not really take effect. 
>  The main reason for the problem is that when the SearchFilter is copied 
> deeply, only the params is copied, the sortBy and sortType attributes is 
> omitted. The code show as follows:
> {code:java}
> Map paramsCopy  = new HashMap<>(filter.getParams());
> SearchFilter   searchFilter = new SearchFilter(paramsCopy);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (RANGER-3500) Ranger policy list doesn't support sorting by field

2021-10-27 Thread Xuze Yang (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xuze Yang updated RANGER-3500:
--
Description: 
When getting the ranger policy list, we may want to sort the returned policy 
list according to certain fields, such as policyId, policyName and etc. But 
case shows that adding the parameters sortBy and sortType to the url has no 
effect (eg: 
[http://192.168.0.12:6080/service/plugins/]policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs).
 I look through the source code and find that code supports sorting by fields, 
but due to some code bugs, it did not really take effect. 
 The main reason for the problem is that when the SearchFilter is copied 
deeply, only the params is copied, the sortBy and sortType attributes is 
omitted. The code show as follows:
{code:java}
Map paramsCopy  = new HashMap<>(filter.getParams());
SearchFilter   searchFilter = new SearchFilter(paramsCopy);
{code}

  was:
When getting the ranger policy list, we may want to sort the returned policy 
list according to certain fields, such as policyId, policyName and etc. But 
case shows that adding the parameters sortBy and sortType to the url has no 
effect (eg: http://192.168.0.12:6080/service/plugins/ 
policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs). I 
look through the source code and find that code supports sorting by fields, but 
due to some code bugs, it did not really take effect. 
The main reason for the problem is that when the SearchFilter is copied deeply, 
only the params is copied, the sortBy and sortType attributes is omitted. The 
code show as follows:
{code:java}
Map paramsCopy  = new HashMap<>(filter.getParams());
SearchFilter   searchFilter = new SearchFilter(paramsCopy);
{code}


> Ranger policy list doesn't support sorting by field
> ---
>
> Key: RANGER-3500
> URL: https://issues.apache.org/jira/browse/RANGER-3500
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.1.0
>Reporter: Xuze Yang
>Priority: Major
>
> When getting the ranger policy list, we may want to sort the returned policy 
> list according to certain fields, such as policyId, policyName and etc. But 
> case shows that adding the parameters sortBy and sortType to the url has no 
> effect (eg: 
> [http://192.168.0.12:6080/service/plugins/]policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs).
>  I look through the source code and find that code supports sorting by 
> fields, but due to some code bugs, it did not really take effect. 
>  The main reason for the problem is that when the SearchFilter is copied 
> deeply, only the params is copied, the sortBy and sortType attributes is 
> omitted. The code show as follows:
> {code:java}
> Map paramsCopy  = new HashMap<>(filter.getParams());
> SearchFilter   searchFilter = new SearchFilter(paramsCopy);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-3500) Ranger policy list doesn't support sorting by field

2021-10-27 Thread Xuze Yang (Jira)
Xuze Yang created RANGER-3500:
-

 Summary: Ranger policy list doesn't support sorting by field
 Key: RANGER-3500
 URL: https://issues.apache.org/jira/browse/RANGER-3500
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 2.1.0
Reporter: Xuze Yang


When getting the ranger policy list, we may want to sort the returned policy 
list according to certain fields, such as policyId, policyName and etc. But 
case shows that adding the parameters sortBy and sortType to the url has no 
effect (eg: http://192.168.0.12:6080/service/plugins/ 
policies/service/2?sortBy=policyName&sortType=desc&serviceName=default-Hdfs). I 
look through the source code and find that code supports sorting by fields, but 
due to some code bugs, it did not really take effect. 
The main reason for the problem is that when the SearchFilter is copied deeply, 
only the params is copied, the sortBy and sortType attributes is omitted. The 
code show as follows:
{code:java}
Map paramsCopy  = new HashMap<>(filter.getParams());
SearchFilter   searchFilter = new SearchFilter(paramsCopy);
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (RANGER-3499) Ranger - Upgrade tomcat to 8.5.72

2021-10-27 Thread Mateen N Mansoori (Jira)
Mateen N Mansoori created RANGER-3499:
-

 Summary: Ranger - Upgrade tomcat to 8.5.72
 Key: RANGER-3499
 URL: https://issues.apache.org/jira/browse/RANGER-3499
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Mateen N Mansoori


Ranger - Upgrade tomcat to 8.5.72



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Release tag in git repo

2021-10-27 Thread Pierre Smits
Hi all,

According to the download page at https://ranger.apache.org lhe latest
available release is 2.1.0. .But when I try to match this to a point in
time in my git clone (from the Github repo) I can't do this.

In Github I see under the tags tab a lot of tags regarding release
candidates, but none for the actual release(s).

Can we correct this?

Met vriendelijke groet,

Pierre Smits


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


[jira] [Assigned] (RANGER-3428) Null Dereference in RangerValidator.java

2021-10-27 Thread Mallika Gogoi (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mallika Gogoi reassigned RANGER-3428:
-

Assignee: Mallika Gogoi

> Null Dereference in RangerValidator.java
> 
>
> Key: RANGER-3428
> URL: https://issues.apache.org/jira/browse/RANGER-3428
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek Kumar
>Assignee: Mallika Gogoi
>Priority: Minor
>
> Null dereference in RangerValidator.java line numbers : 207,225,265,283,327.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (RANGER-3428) Null Dereference in RangerValidator.java

2021-10-27 Thread Mallika Gogoi (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mallika Gogoi reassigned RANGER-3428:
-

Assignee: Mallika Gogoi

> Null Dereference in RangerValidator.java
> 
>
> Key: RANGER-3428
> URL: https://issues.apache.org/jira/browse/RANGER-3428
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek Kumar
>Assignee: Mallika Gogoi
>Priority: Minor
>
> Null dereference in RangerValidator.java line numbers : 207,225,265,283,327.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (RANGER-3428) Null Dereference in RangerValidator.java

2021-10-27 Thread Mallika Gogoi (Jira)


 [ 
https://issues.apache.org/jira/browse/RANGER-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mallika Gogoi reassigned RANGER-3428:
-

Assignee: (was: Mallika Gogoi)

> Null Dereference in RangerValidator.java
> 
>
> Key: RANGER-3428
> URL: https://issues.apache.org/jira/browse/RANGER-3428
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Abhishek Kumar
>Priority: Minor
>
> Null dereference in RangerValidator.java line numbers : 207,225,265,283,327.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Re: Permissions

2021-10-27 Thread Pierre Smits
Ping?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Tue, Oct 26, 2021 at 12:32 PM Pierre Smits 
wrote:

> Hi all,
>
> I want to contribute. Please provide me with permissions to the wiki.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>