[jira] [Updated] (JCRVLT-184) vlt shell script prints out error when using openjdk

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-184:

Component/s: Packaging

> vlt shell script prints out error when using openjdk
> 
>
> Key: JCRVLT-184
> URL: https://issues.apache.org/jira/browse/JCRVLT-184
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: 3.1.44
>
>
> {noformat}$ vlt --version
> /usr/bin/vlt: line 141: [: openjdk version "1.8.0_131": integer expression 
> expected
> Jackrabbit FileVault [version 3.1.40] Copyright 2013 by Apache Software 
> Foundation. See LICENSE.txt for more information.{noformat}
> {noformat}$ java -version
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (IcedTea 3.4.0) (suse-1.1-x86_64)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode){noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCRVLT-267) Changing log level to info from error in JcrPackageregistry upload method in case a .jar resource doesn't contains jcr_root

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-267:

Component/s: Packaging

> Changing log level to info from error in JcrPackageregistry upload method in 
> case a .jar resource doesn't contains jcr_root
> ---
>
> Key: JCRVLT-267
> URL: https://issues.apache.org/jira/browse/JCRVLT-267
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Nitin Gupta
>Priority: Major
> Fix For: 3.1.44
>
>
> the jar file could contain some native components as well (c/c++ components 
> compiled for specific platforms and in this case, they would not be OSGI 
> bundles). They are meant to be processed using a custom resource transformer 
> rather than a PackageTransformer which call jackrabbit layer. Also, the 
> PackageTransformer gives _INFO_ in the logs rather than the error which seems 
> to be inconsistent with the jackrabbit layer logging.
> cc @tripodsan



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCRVLT-255) ImportModes act on file serialization level not on node level

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-255:

Component/s: Packaging

> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.1.44
>
>
> When reading the docs at 
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that 
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of 
> the actual serialization format). Unfortunately this is not the case: If I 
> have a serialized docview {{.content.xml}} file covering the current node and 
> three levels below the merging is not done if the entry node level does 
> already exist in the repository, although not all child nodes are in the 
> repository yet.
> This is due to the guard in 
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
>  which prevents the DocViewSAXImporter from kicking in, although there are 
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at 
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it 
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes 
> and subtrees...
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JCRVLT-270) Use Jackrabbit 2.16.1

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-270:
---

 Summary: Use Jackrabbit 2.16.1
 Key: JCRVLT-270
 URL: https://issues.apache.org/jira/browse/JCRVLT-270
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: vlt
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
 Fix For: 3.1.44


Jackrabbit 2.16.1 has updated versions of its dependencies and should be 
bundled with vault cli.

http://www.apache.org/dist/jackrabbit/2.16.1/RELEASE-NOTES.txt



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCRVLT-251) Child nodes mentioned in parent node's docview xml are not cleared correctly during installation

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-251:

Fix Version/s: 3.1.44

> Child nodes mentioned in parent node's docview xml are not cleared correctly 
> during installation
> 
>
> Key: JCRVLT-251
> URL: https://issues.apache.org/jira/browse/JCRVLT-251
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.1.44
>
>
> If a repository contains the following structure
> {code}
> + testroot [nt:unstructured]
>   + testchild [nt:unstructured]
>  - property: value (String)
> {code}
> And a package is being installed there containing a {{.content.xml}} file 
> below folder {{/testroot}} with the following content only
> {code}
> 
> http://sling.apache.org/jcr/sling/1.0; 
> xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:rep="internal"
> jcr:primaryType="nt:unstructured">
> 
> 
> {code}
> and a {{filter.xml}} like this
> {code}
> 
> 
> 
> 
> {code}
> and apart from that no further files/folders, the repository child node at 
> {{/testroot/testchild}} is not correctly cleared, i.e. the property with name 
> "property" and value "value" is still there after installation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JCRVLT-269) Release Jackrabbit FileVault 3.1.44

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-269:
---

 Summary: Release Jackrabbit FileVault 3.1.44
 Key: JCRVLT-269
 URL: https://issues.apache.org/jira/browse/JCRVLT-269
 Project: Jackrabbit FileVault
  Issue Type: Task
  Components: Packaging
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
 Fix For: 3.1.44






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jackrabbit FileVault 3.1.44 Release Plan

[Tobias Bocanegra]

Hi,

I'd like to cut Jackrabbit Filevault 3.1.44 Monday next week, 19-Feb-2018.

The list of open issues scheduled for 3.1.44 are visible in:
  https://issues.apache.org/jira/projects/JCRVLT/versions/12342173

The remaining 4 issues will be resolved until next week.


The candidate release notes are here:
  
http://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/RELEASE-NOTES.txt

As mentioned earlier, I would like to use new voting rules for this release. 
This should give the PMC more time to review and vote. The proposed voting text 
will be:

---
Please vote on releasing this package as Apache Jackrabbit FileVault 
The vote is open for a minimum of 72 hours during business days and passes 
if a majority of at least three +1 Jackrabbit PMC votes are cast. 
The vote fails if not enough votes are cast after 1 week (5 business days).
---

If there are any objections please let me know.

Best regards, Toby



Ps: Thanks for the reminder, Konrad

Apache EU Roadshow CFP Closing Soon (23 February)

[Sharan F]

Hello Everyone

This is an initial reminder to let you all know that we are holding an 
Apache EU Roadshow co-located with FOSS Backstage in Berlin on 13^th and 
14^th June 2018. https://s.apache.org/tCHx


The Call for Proposals (CFP) for the Apache EU Roadshow is currently 
open and will close at the end of next week, so if you have been 
delaying making a submission because the closing date seemed a long way 
off, then it's time to start getting your proposals submitted.


So what are we looking for?
We will have 2 Apache Devrooms available during the 2 day Roadshow so 
are looking for projects including incubating ones, to submit 
presentations, panel discussions, BoFs, or workshop proposals. The main 
focus of the Roadshow will be IoT, Cloud, Httpd and Tomcat so if your 
project is involved in or around any of these technologies at Apache 
then we are very interested in hearing from you.


Community and collaboration is important at Apache so if your project is 
interested in organising a project sprint, meetup or hackathon during 
the Roadshow, then please submit it inthe CFP as we do have some space 
available to allocate for these.


If you are wanting to submit a talk on open source community related 
topics such as the Apache Way, governance or legal aspects then please 
submit these to the CFP for FOSS Backstage.


Tickets for the Apache EU Roadshow are included as part of the 
registration for FOSS Backstage, so to attend the Roadshow you will need 
to register for FOSS Backstage. Early Bird tickets are still available 
until the 21^st February 2018.


Please see below for important URLs to remember:

-  To submit a CFP for the Apache EU Roadshow 
:http://apachecon.com/euroadshow18/ 


-  To submit a CFP for FOSS Backstage : 
https://foss-backstage.de/call-papers


-  To register to attend the Apache EU Roadshow and/or FOSS Backstage : 
https://foss-backstage.de/tickets


For further updates and information about the Apache EU Roadshowplease 
check http://apachecon.com/euroadshow18/


Thanks
Sharan Foga, VP Apache Community Development

[jira] [Assigned] (JCRVLT-132) Document enhanced document view format

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-132:
---

Assignee: Tobias Bocanegra

> Document enhanced document view format
> --
>
> Key: JCRVLT-132
> URL: https://issues.apache.org/jira/browse/JCRVLT-132
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> FileVault is not using the default JCR document view but rather an enhanced 
> format (supporting types and multi-values and same-name siblings). That 
> deserves a dedicated page in the documentation. The only documentation I 
> could find about that is 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/util/DocViewProperty.html.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCRVLT-132) Document enhanced document view format

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-132:

Fix Version/s: 3.1.44

> Document enhanced document view format
> --
>
> Key: JCRVLT-132
> URL: https://issues.apache.org/jira/browse/JCRVLT-132
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> FileVault is not using the default JCR document view but rather an enhanced 
> format (supporting types and multi-values and same-name siblings). That 
> deserves a dedicated page in the documentation. The only documentation I 
> could find about that is 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/util/DocViewProperty.html.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JCRVLT-250) Test class "SimpleFileAggregateInPackage" not executed by default in maven-surefire-plugin

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-250.
-
Resolution: Fixed

fixed in r1824280

> Test class "SimpleFileAggregateInPackage" not executed by default in 
> maven-surefire-plugin
> --
>
> Key: JCRVLT-250
> URL: https://issues.apache.org/jira/browse/JCRVLT-250
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 3.1.44
>
>
> The testclass 
> {{org.apache.jackrabbit.vault.packaging.integration.SimpleFileAggregateInPackage}}
>  (being committed in the context of JCRVLT-177) is by default not executed by 
> Maven Surefire, as the class name does not follow the default pattern for 
> includes 
> (http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes).
>  Please rename this class to something like 
> {{TestSimpleFileAggregateInPackage}} to make sure it is being executed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JCRVLT-132) Document enhanced document view format

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-132.
-
Resolution: Fixed

fixed in r1824281



> Document enhanced document view format
> --
>
> Key: JCRVLT-132
> URL: https://issues.apache.org/jira/browse/JCRVLT-132
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> FileVault is not using the default JCR document view but rather an enhanced 
> format (supporting types and multi-values and same-name siblings). That 
> deserves a dedicated page in the documentation. The only documentation I 
> could find about that is 
> https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/util/DocViewProperty.html.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (JCRVLT-250) Test class "SimpleFileAggregateInPackage" not executed by default in maven-surefire-plugin

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-250:
---

Assignee: Tobias Bocanegra

> Test class "SimpleFileAggregateInPackage" not executed by default in 
> maven-surefire-plugin
> --
>
> Key: JCRVLT-250
> URL: https://issues.apache.org/jira/browse/JCRVLT-250
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 3.1.44
>
>
> The testclass 
> {{org.apache.jackrabbit.vault.packaging.integration.SimpleFileAggregateInPackage}}
>  (being committed in the context of JCRVLT-177) is by default not executed by 
> Maven Surefire, as the class name does not follow the default pattern for 
> includes 
> (http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes).
>  Please rename this class to something like 
> {{TestSimpleFileAggregateInPackage}} to make sure it is being executed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JCRVLT-270) Use Jackrabbit 2.16.1

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-270.
-
Resolution: Fixed

fixed in r1824279

> Use Jackrabbit 2.16.1
> -
>
> Key: JCRVLT-270
> URL: https://issues.apache.org/jira/browse/JCRVLT-270
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> Jackrabbit 2.16.1 has updated versions of its dependencies and should be 
> bundled with vault cli.
> http://www.apache.org/dist/jackrabbit/2.16.1/RELEASE-NOTES.txt



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JCRVLT-251) Child nodes mentioned in parent node's docview xml are not cleared correctly during installation

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-251.
-
Resolution: Won't Fix

I estimate the potential backward compatibility risk as too high to change this 
behaviour.
I added it to the documentation via JCRVLT-132

> Child nodes mentioned in parent node's docview xml are not cleared correctly 
> during installation
> 
>
> Key: JCRVLT-251
> URL: https://issues.apache.org/jira/browse/JCRVLT-251
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.1.44
>
>
> If a repository contains the following structure
> {code}
> + testroot [nt:unstructured]
>   + testchild [nt:unstructured]
>  - property: value (String)
> {code}
> And a package is being installed there containing a {{.content.xml}} file 
> below folder {{/testroot}} with the following content only
> {code}
> 
> http://sling.apache.org/jcr/sling/1.0; 
> xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:rep="internal"
> jcr:primaryType="nt:unstructured">
> 
> 
> {code}
> and a {{filter.xml}} like this
> {code}
> 
> 
> 
> 
> {code}
> and apart from that no further files/folders, the repository child node at 
> {{/testroot/testchild}} is not correctly cleared, i.e. the property with name 
> "property" and value "value" is still there after installation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JCRVLT-255) ImportModes act on file serialization level not on node level

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-255:

Fix Version/s: (was: 3.1.44)
   3.2

I looked into the issue and it seems that MERGE is only supported for generic 
artifacts of authorizable and policy nodes. it also supports merging of entire 
files.

- but not for file artifacts with content; eg: image.png.dir/.content.xml
- but not for all generic artifacts

since this change would be a bit more complicated and need extensive test and 
has potentially backward compatibility implications, I decided to more this to 
the 3.2 release and document  the current behaviour.

> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.2
>
>
> When reading the docs at 
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that 
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of 
> the actual serialization format). Unfortunately this is not the case: If I 
> have a serialized docview {{.content.xml}} file covering the current node and 
> three levels below the merging is not done if the entry node level does 
> already exist in the repository, although not all child nodes are in the 
> repository yet.
> This is due to the guard in 
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
>  which prevents the DocViewSAXImporter from kicking in, although there are 
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at 
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it 
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes 
> and subtrees...
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

BUILD FAILURE: Jackrabbit Oak - Build # 1249 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #1249)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1249/ to 
view the results.

Changes:
No changes
 

Test results:
All tests passed

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.20

[Davide Giannella]

[X] +1 Release this package as Apache Jackrabbit Oak 1.4.20
D.

Re: change node ownership

[Angela Schreiber]

Hi Marco

It depends a bit on how you originally setup the 'ownership' in the first
place.
- if you have granted permissions to userA _on_ that very node, you can
simply remove the entries and create new ones for the new owner.
- if you have granted permissions to userA on a _parent_ node you can
either fix the entries at the parent or add a denying entry at the target.
- if permissions are inherited from other principals (e.g. through group
membership) you can either 'fix' the set of principals that is add to the
Subject upon login (e.g. through changes of group membership) or again
through an explicit deny.
Which variant (and there might be some more) is the best one, depends on
your requirements.
Also note that for modification of the permission setup your session not
only requires regular write privileges but read/modify access control
privileges.

See the Oak documentation for additional details in particular
http://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
You may also want to take a look at the oak-exercise module which comes
with quite some training material for the default authorisation model.

Hope that helps
Angela
 

On 13/02/18 18:36, "Marco Piovesana"  wrote:

>Hi all,
>is it possible to change the owner of a node? What I'm trying to do is
>move
>a node created by userA from its original folder to another place. After
>the node is moved I want to revoke all permission to userA on that node.
>
>Marco.

Re: change node ownership

[Marco Piovesana]

Hi Angela,
thanks for the answer. I thought (and I was wrong) that the user that
created a node would have had complete control on it (and not just the
permissions explicitly granted to him). That's why my question... thanks
again for the clarification.

Marco.


On Wed, Feb 14, 2018 at 9:47 AM Angela Schreiber 
wrote:

> Hi Marco
>
> It depends a bit on how you originally setup the 'ownership' in the first
> place.
> - if you have granted permissions to userA _on_ that very node, you can
> simply remove the entries and create new ones for the new owner.
> - if you have granted permissions to userA on a _parent_ node you can
> either fix the entries at the parent or add a denying entry at the target.
> - if permissions are inherited from other principals (e.g. through group
> membership) you can either 'fix' the set of principals that is add to the
> Subject upon login (e.g. through changes of group membership) or again
> through an explicit deny.
> Which variant (and there might be some more) is the best one, depends on
> your requirements.
> Also note that for modification of the permission setup your session not
> only requires regular write privileges but read/modify access control
> privileges.
>
> See the Oak documentation for additional details in particular
> http://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
> You may also want to take a look at the oak-exercise module which comes
> with quite some training material for the default authorisation model.
>
> Hope that helps
> Angela
>
>
> On 13/02/18 18:36, "Marco Piovesana"  wrote:
>
> >Hi all,
> >is it possible to change the owner of a node? What I'm trying to do is
> >move
> >a node created by userA from its original folder to another place. After
> >the node is moved I want to revoke all permission to userA on that node.
> >
> >Marco.
>
>

Re: change node ownership

[Angela Schreiber]

Hi Marco

Yeah... no, that's not how the default authorisation model works :-)

But obviously you would be able to write and deploy your own authorisation
model that just behaves as you expected it to work.
Some hints can be found at
http://jackrabbit.apache.org/oak/docs/security/introduction.html

I still didn't have time to write a dedicated training session for the
customize-authorization topic but it's on my TODOs.

Kind regards
Angela


On 14/02/18 10:37, "Marco Piovesana"  wrote:

>Hi Angela,
>thanks for the answer. I thought (and I was wrong) that the user that
>created a node would have had complete control on it (and not just the
>permissions explicitly granted to him). That's why my question... thanks
>again for the clarification.
>
>Marco.
>
>
>On Wed, Feb 14, 2018 at 9:47 AM Angela Schreiber
>
>wrote:
>
>> Hi Marco
>>
>> It depends a bit on how you originally setup the 'ownership' in the
>>first
>> place.
>> - if you have granted permissions to userA _on_ that very node, you can
>> simply remove the entries and create new ones for the new owner.
>> - if you have granted permissions to userA on a _parent_ node you can
>> either fix the entries at the parent or add a denying entry at the
>>target.
>> - if permissions are inherited from other principals (e.g. through group
>> membership) you can either 'fix' the set of principals that is add to
>>the
>> Subject upon login (e.g. through changes of group membership) or again
>> through an explicit deny.
>> Which variant (and there might be some more) is the best one, depends on
>> your requirements.
>> Also note that for modification of the permission setup your session not
>> only requires regular write privileges but read/modify access control
>> privileges.
>>
>> See the Oak documentation for additional details in particular
>> 
>>http://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
>> You may also want to take a look at the oak-exercise module which comes
>> with quite some training material for the default authorisation model.
>>
>> Hope that helps
>> Angela
>>
>>
>> On 13/02/18 18:36, "Marco Piovesana"  wrote:
>>
>> >Hi all,
>> >is it possible to change the owner of a node? What I'm trying to do is
>> >move
>> >a node created by userA from its original folder to another place.
>>After
>> >the node is moved I want to revoke all permission to userA on that
>>node.
>> >
>> >Marco.
>>
>>

BUILD FAILURE: Jackrabbit Oak - Build # 1248 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #1248)

Status: Failure

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1248/ to 
view the results.

Changes:
No changes
 

Test results:
No tests ran.

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.20

[Andrei Dulceanu]

[X] +1 Release this package as Apache Jackrabbit Oak 1.4.20

with

[INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T10:58:13+03:00)
[INFO] OS name: "mac os x", version: "10.13.3", arch: "x86_64", family:
"mac"
[INFO] Java version: 1.8.0_65, vendor: Oracle Corporation

Andrei

2018-02-14 12:51 GMT+02:00 Davide Giannella :

> [X] +1 Release this package as Apache Jackrabbit Oak 1.4.20
> D.
>