[jira] [Commented] (OAK-6412) Consider upgrading to newer Lucene versions
[ https://issues.apache.org/jira/browse/OAK-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514499#comment-17514499 ] Marco Piovesana commented on OAK-6412: -- Hi, there is any plan for updating lucene version? As mentioned [here|https://nvd.nist.gov/vuln/detail/CVE-2017-12629] the version currently used has critical vulnerabilites. Marco. > Consider upgrading to newer Lucene versions > --- > > Key: OAK-6412 > URL: https://issues.apache.org/jira/browse/OAK-6412 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > > An year ago I had started prototyping the upgrade to Lucene 5 [1], in the > meantime version 6 (and 7 soon) has come out. > I think it'd be very nice to upgrade Lucene version to the latest, this would > give us improvements in space consumption and runtime performance. > In case we want to upgrade to 6.0 or later we need to consider upgrade > scenarios because Lucene Codecs are backward compatible with the previous > major release, so Lucene 6 can read Lucene 5 but not Lucene 4.x (4.7 in our > case) therefore we would need to detect that when reading an index and > trigger reindexing using the new format. > Related to that there's also a patch to upgrade Solr index to version 5 (see > OAK-4318). > [1] : https://github.com/tteofili/jackrabbit-oak/tree/lucene5 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (OAK-9706) Waiting for cluster node lease after mongo repository restart
[ https://issues.apache.org/jira/browse/OAK-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana resolved OAK-9706. -- Resolution: Not A Problem > Waiting for cluster node lease after mongo repository restart > - > > Key: OAK-9706 > URL: https://issues.apache.org/jira/browse/OAK-9706 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Affects Versions: 1.40.0 > Environment: Apache Oak 1.40.0 with mongo 4.4.12 >Reporter: Marco Piovesana >Priority: Major > > I have a repository configured with a mongo document store. When I stop the > repository and restart it I get the message "Waiting for cluster node 1's > lease to expire". The application is able to connect to mongo only after the > lease expires. > The shutdown process does call the _dispose_ method of the > {_}DocumentNodeStore{_}, as specified in the doc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (OAK-9706) Waiting for cluster node lease after mongo repository restart
Marco Piovesana created OAK-9706: Summary: Waiting for cluster node lease after mongo repository restart Key: OAK-9706 URL: https://issues.apache.org/jira/browse/OAK-9706 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Affects Versions: 1.40.0 Environment: Apache Oak 1.40.0 with mongo 4.4.12 Reporter: Marco Piovesana I have a repository configured with a mongo document store. When I stop the repository and restart it I get the message "Waiting for cluster node 1's lease to expire". The application is able to connect to mongo only after the lease expires. The shutdown process does call the _dispose_ method of the {_}DocumentNodeStore{_}, as specified in the doc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OAK-8717) Remove deprecated Guava-based APIs
[ https://issues.apache.org/jira/browse/OAK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448561#comment-17448561 ] Marco Piovesana commented on OAK-8717: -- Hi, has anyone had time to check if is ok to merge this patch and close the issue? Marco. > Remove deprecated Guava-based APIs > -- > > Key: OAK-8717 > URL: https://issues.apache.org/jira/browse/OAK-8717 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-8717-remove-guava-deprecated-usages.patch, > OAK-8717.diff > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (OAK-8717) Remove deprecated Guava-based APIs
[ https://issues.apache.org/jira/browse/OAK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435887#comment-17435887 ] Marco Piovesana commented on OAK-8717: -- Hi, I've attached a patch, it contains the changes required to remove all usages of the guava deprecated methods that I found. Marco. [^OAK-8717-remove-guava-deprecated-usages.patch] > Remove deprecated Guava-based APIs > -- > > Key: OAK-8717 > URL: https://issues.apache.org/jira/browse/OAK-8717 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-8717-remove-guava-deprecated-usages.patch, > OAK-8717.diff > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8717) Remove deprecated Guava-based APIs
[ https://issues.apache.org/jira/browse/OAK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-8717: - Attachment: OAK-8717-remove-guava-deprecated-usages.patch > Remove deprecated Guava-based APIs > -- > > Key: OAK-8717 > URL: https://issues.apache.org/jira/browse/OAK-8717 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-8717-remove-guava-deprecated-usages.patch, > OAK-8717.diff > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9607) Test fails when build with empty maven cache
[ https://issues.apache.org/jira/browse/OAK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-9607: - Summary: Test fails when build with empty maven cache (was: Test fails un build with empty maven cache) > Test fails when build with empty maven cache > > > Key: OAK-9607 > URL: https://issues.apache.org/jira/browse/OAK-9607 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Affects Versions: 1.40.0 >Reporter: Marco Piovesana >Priority: Minor > > I cloned the Oak repo yesterday (28th of october) and, if I run the build > command (_mvn clean install_), I have the following failing test: > _PersistentDiskCacheTest.cleanupTest:126 Segment(s) not cleaned up in cache > expected:<0> but was:<2>_ > > if I run again the build it will eventually complete correctly. I tried on > two different machines, one linux and one macos, and it did happen on both > after cleaning the maven cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9607) Test fails un build with empty maven cache
Marco Piovesana created OAK-9607: Summary: Test fails un build with empty maven cache Key: OAK-9607 URL: https://issues.apache.org/jira/browse/OAK-9607 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Affects Versions: 1.40.0 Reporter: Marco Piovesana I cloned the Oak repo yesterday (28th of october) and, if I run the build command (_mvn clean install_), I have the following failing test: _PersistentDiskCacheTest.cleanupTest:126 Segment(s) not cleaned up in cache expected:<0> but was:<2>_ if I run again the build it will eventually complete correctly. I tried on two different machines, one linux and one macos, and it did happen on both after cleaning the maven cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432552#comment-17432552 ] Marco Piovesana commented on OAK-7182: -- [~reschke] I was trying to understand what needs to be done for OAK-8717. I've seen that it does already contain a patch, it hasn't been merged because it was only part of the required work? Or should I completely ignore its content? One more thing, if I may: some changes were made to the modules _pom.xml_. Most of the time was about the _Embed-Dependency_ of the _maven-bundle-plugin_. That I find it hard to understand, and I feel it goes beyond my current knowledge of the code. > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431277#comment-17431277 ] Marco Piovesana commented on OAK-7182: -- I'll do that then, thanks [~reschke] > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431184#comment-17431184 ] Marco Piovesana commented on OAK-7182: -- Hi [~angela], that will definitely work for me. Since I have little experience with the code, do you think there's something I should start from to get familiar with the architecture? Is there anything that conflicts with the issue in progress? > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431117#comment-17431117 ] Marco Piovesana commented on OAK-7182: -- Hi guys, is it possible to help in any way with the remaining work required to complete this issue? It's getting really hard for us to work around this in our application. Marco. > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388525#comment-17388525 ] Marco Piovesana commented on OAK-8048: -- Hi guys, it this on hold or do you already have an idea of when it will be fixed? thanks, Marco. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Assignee: Manfred Baedke >Priority: Major > Attachments: OAK-8048-test.diff, OAK-8048.diff, fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-134): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8945) Cannot apply node restrictions without checking-out the node
Marco Piovesana created OAK-8945: Summary: Cannot apply node restrictions without checking-out the node Key: OAK-8945 URL: https://issues.apache.org/jira/browse/OAK-8945 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.22.1, 1.14.0 Reporter: Marco Piovesana The node _rep:restrictions_ is not marked as _IGNORED_ while it's parent, the _ACE_ it is. This makes it possible to modify the access control list without having to check-out the node only when no restrictions are defined. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8929) Missing configuration steps to define a custom LoginModule in a non-OSGi environment
Marco Piovesana created OAK-8929: Summary: Missing configuration steps to define a custom LoginModule in a non-OSGi environment Key: OAK-8929 URL: https://issues.apache.org/jira/browse/OAK-8929 Project: Jackrabbit Oak Issue Type: Documentation Components: core Affects Versions: 1.22.1, 1.8.20 Reporter: Marco Piovesana Documentation isn't clear about how to configure an additional LoginModule or replace an existing one in a non-OSGi environment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039741#comment-17039741 ] Marco Piovesana commented on OAK-8048: -- Sure, no problem.. thanks! > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: OAK-8048-test.diff, fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-134): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039605#comment-17039605 ] Marco Piovesana edited comment on OAK-8048 at 2/19/20 1:14 AM: --- Hi Julian, yes I did. With the fix I proposed that test passes, so I thought it was another test case that had to be added to validate the patch, and that I had to wait until approval. Have I misunderstood your comment? was (Author: iosonomarco): Hi Julian, yes I did. With the fix I proposed that test passes, so I thought it was another test case that had to be added to validate the patch, and that I had to wait until approval. Am I misunderstood your comment? > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: OAK-8048-test.diff, fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-134): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039605#comment-17039605 ] Marco Piovesana commented on OAK-8048: -- Hi Julian, yes I did. With the fix I proposed that test passes, so I thought it was another test case that had to be added to validate the patch, and that I had to wait until approval. Am I misunderstood your comment? > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: OAK-8048-test.diff, fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-134): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038840#comment-17038840 ] Marco Piovesana commented on OAK-8048: -- Hi guys, I know you might all very busy, but it's been a while since I've submitted the patch and I was wondering if it was going to be considered for any of the future releases. I have use cases where users create big versioned files that are useful only for a specific amount of time. Those files are deleted, but because of this bug, their base version remains there filling up the disk with unnecessary information. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: OAK-8048-test.diff, fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-134): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823911#comment-16823911 ] Marco Piovesana commented on OAK-8048: -- Yes Julian, my bad I meant JCR-134 and not JCR-34. Marco. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806689#comment-16806689 ] Marco Piovesana commented on OAK-8048: -- forgot to say that the patch is made from branch 1.10 and not 1.8. Marco. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806165#comment-16806165 ] Marco Piovesana commented on OAK-8048: -- Hi all, I would like to propose a solution for this bug (attached patch). I saw that the class responsible for checking whether or not to remove the history is the {{OrphanedVersionCleaner}}, but I thought that was better to add the logic directly into {{ReadWriteVersionManager}} for three reasons: # All the logic used within the {{leave}} method works for nodes and not versions # The {{OrphanedVersionCleaner.leave}} method is called much more often than the {{ReadWriteVersionManager.removeVersion}}, that is called only when a version is removed # The class {{ReadWriteVersionManager}} contains already all the logic to check if the history is empty and remove it let me know if the proposed solution if ok, or what can I do to make it better. thanks, Marco.[^fix-OAK-8048.patch] > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-8048: - Attachment: fix-OAK-8048.patch > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > Attachments: fix-OAK-8048.patch > > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772067#comment-16772067 ] Marco Piovesana commented on OAK-8048: -- For now, to force the history removal, do I have to delete the Tree object (like in the \{{ReadOnlyVersionManagerTest}}) or there's another way? Marco. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771670#comment-16771670 ] Marco Piovesana commented on OAK-8048: -- Hi Marcel, here the code snippet: {code:java} @Test public void shouldDeleteNodeHistory() throws IOException, InvalidFileStoreVersionException, RepositoryException { File root = new File(System.getProperty("java.io.tmpdir"), "oakTest"); File repo = new File(root, "content"); FileDataStore fileDataStore = new FileDataStore(); fileDataStore.init(repo.getAbsolutePath()); DataStoreBlobStore dataStoreBlobStore = new DataStoreBlobStore(fileDataStore); FileStore fileStore = FileStoreBuilder.fileStoreBuilder(repo).withBlobStore(dataStoreBlobStore).build(); SegmentNodeStore nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); Oak oak = new Oak(nodeStore); Jcr jcrRepo = new Jcr(oak); Repository repository = jcrRepo.createRepository(); try { Session adminSession = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); adminSession.save(); Node myFolder = JcrUtils.getOrAddNode(adminSession.getRootNode(), "my node", JcrConstants.NT_UNSTRUCTURED); myFolder.addMixin(JcrConstants.MIX_VERSIONABLE); myFolder.addMixin(AccessControlConstants.MIX_REP_ACCESS_CONTROLLABLE); adminSession.save(); adminSession.getWorkspace().getVersionManager().checkout(myFolder.getPath()); adminSession.getWorkspace().getVersionManager().checkin(myFolder.getPath()); adminSession.getWorkspace().getVersionManager().checkout(myFolder.getPath()); adminSession.getWorkspace().getVersionManager().checkin(myFolder.getPath()); VersionHistory versionHistory = adminSession.getWorkspace().getVersionManager().getVersionHistory(myFolder.getPath()); String historyNodePath = versionHistory.getPath(); VersionIterator allVersions = versionHistory.getAllVersions(); myFolder.remove(); adminSession.save(); while (allVersions.hasNext()) { Version version = allVersions.nextVersion(); if (!version.getName().equals(JcrConstants.JCR_ROOTVERSION)) { versionHistory.removeVersion(version.getName()); } } adminSession.save(); boolean historyExists = adminSession.itemExists(historyNodePath); adminSession.logout(); assertFalse(historyExists); } finally { fileStore.close(); ((JackrabbitRepository) repository).shutdown(); } } {code} > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8048) VersionHistory not removed when removing node and all its versions
[ https://issues.apache.org/jira/browse/OAK-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-8048: - Description: Hi all, I'm trying to delete a node and all its versions, but the version history is not removed. I'm doing the following steps (as described in OAK-4370 and JCR-34): # retrieve the version history # delete the node and save the session # delete all versions except for the base version # save the session The versions are all gone but the versionHistory node, and the base version node, are still there. Am I doing something wrong? The only test related to this that I found is {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. It does work, but uses Oak related classes and not the JCR interface. was: Hi all, I'm trying to delete a node and all its versions, but the version history is not removed. I'm doing the following steps (as described in OAK-4370 and JCR-34): # retrieve the version history # delete the node and save the session # delete all versions except for the base version # save the session The versions are all gone but the versionHistory node is still there. Am I doing something wrong? The only test related to this that I found is {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. It does work, but uses Oak related classes and not the JCR interface. > VersionHistory not removed when removing node and all its versions > -- > > Key: OAK-8048 > URL: https://issues.apache.org/jira/browse/OAK-8048 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.9 >Reporter: Marco Piovesana >Priority: Major > > Hi all, > I'm trying to delete a node and all its versions, but the version history is > not removed. I'm doing the following steps (as described in OAK-4370 and > JCR-34): > # retrieve the version history > # delete the node and save the session > # delete all versions except for the base version > # save the session > The versions are all gone but the versionHistory node, and the base version > node, are still there. Am I doing something wrong? > The only test related to this that I found is > {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. > It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8048) VersionHistory not removed when removing node and all its versions
Marco Piovesana created OAK-8048: Summary: VersionHistory not removed when removing node and all its versions Key: OAK-8048 URL: https://issues.apache.org/jira/browse/OAK-8048 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.8.9 Reporter: Marco Piovesana Hi all, I'm trying to delete a node and all its versions, but the version history is not removed. I'm doing the following steps (as described in OAK-4370 and JCR-34): # retrieve the version history # delete the node and save the session # delete all versions except for the base version # save the session The versions are all gone but the versionHistory node is still there. Am I doing something wrong? The only test related to this that I found is {{ReadOnlyVersionManagerTest.testRemoveEmptyHistoryAfterRemovingVersionable}}. It does work, but uses Oak related classes and not the JCR interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7890) Cannot restore node version
Marco Piovesana created OAK-7890: Summary: Cannot restore node version Key: OAK-7890 URL: https://issues.apache.org/jira/browse/OAK-7890 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 1.8.0 Reporter: Marco Piovesana If have a versionable node created without the mixin "rep:AccessControllable". The node has multiple versions and some ACEs added to it. When I try to restore the node state to one of the previous versions I get the error: "_ConstraintViolationException: No matching node definition found for rep:policy_" However, if I create the node specifying the "rep:AccessControllable" mixin, then I can restore the node without any error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-7879) ACL can be modified on versioned node without having to check-out the node first
[ https://issues.apache.org/jira/browse/OAK-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673411#comment-16673411 ] Marco Piovesana edited comment on OAK-7879 at 11/2/18 4:59 PM: --- Hi Angela, yep sorry, I saw your reply after creating the issue. Marco. was (Author: iosonomarco): Hi Angela, yep sorry, I saw your replay after creating the issue. Marco. > ACL can be modified on versioned node without having to check-out the node > first > > > Key: OAK-7879 > URL: https://issues.apache.org/jira/browse/OAK-7879 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.8.8 >Reporter: Marco Piovesana >Priority: Minor > > If I create the first version of a node *after* adding an ACE to it, then I > can add or remove other ACE without having to checkout the node. > > If I create the first version of the node *before* adding the first ACE, then > I get the error (_OakVersion0001: Cannot change property jcr:mixinTypes on > checked in node_) whenever i try to modify the node permissions without > checking it out first. > > Following a code snippet showing the first case: > > {code:java} > Session adminSession = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((JackrabbitSession) > adminSession).getUserManager(); > User firstUser = userManager.createUser("firstUser", "firstUser", > new PrincipalImpl("firstUser"), null); > Principal firstUserPrincipal = firstUser.getPrincipal(); > adminSession.save(); > Node myFolder = JcrUtils.getOrAddNode(adminSession.getRootNode(), > "my folder", "nt:folder"); > myFolder.addMixin(JcrConstants.MIX_VERSIONABLE); > AccessControlUtils.addAccessControlEntry(adminSession, > myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_ALL}, > true); > adminSession.save(); > VersionManager versionManager = > adminSession.getWorkspace().getVersionManager(); > versionManager.checkout(myFolder.getPath()); > versionManager.checkin(myFolder.getPath()); > AccessControlUtils.clear(myFolder, firstUserPrincipal.getName()); > AccessControlUtils.addAccessControlEntry(adminSession, > myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_READ}, > true); > adminSession.save(); > adminSession.logout(); > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7879) ACL can be modified on versioned node without having to check-out the node first
[ https://issues.apache.org/jira/browse/OAK-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673411#comment-16673411 ] Marco Piovesana commented on OAK-7879: -- Hi Angela, yep sorry, I saw your replay after creating the issue. Marco. > ACL can be modified on versioned node without having to check-out the node > first > > > Key: OAK-7879 > URL: https://issues.apache.org/jira/browse/OAK-7879 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.8.8 >Reporter: Marco Piovesana >Priority: Minor > > If I create the first version of a node *after* adding an ACE to it, then I > can add or remove other ACE without having to checkout the node. > > If I create the first version of the node *before* adding the first ACE, then > I get the error (_OakVersion0001: Cannot change property jcr:mixinTypes on > checked in node_) whenever i try to modify the node permissions without > checking it out first. > > Following a code snippet showing the first case: > > {code:java} > Session adminSession = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((JackrabbitSession) > adminSession).getUserManager(); > User firstUser = userManager.createUser("firstUser", "firstUser", > new PrincipalImpl("firstUser"), null); > Principal firstUserPrincipal = firstUser.getPrincipal(); > adminSession.save(); > Node myFolder = JcrUtils.getOrAddNode(adminSession.getRootNode(), > "my folder", "nt:folder"); > myFolder.addMixin(JcrConstants.MIX_VERSIONABLE); > AccessControlUtils.addAccessControlEntry(adminSession, > myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_ALL}, > true); > adminSession.save(); > VersionManager versionManager = > adminSession.getWorkspace().getVersionManager(); > versionManager.checkout(myFolder.getPath()); > versionManager.checkin(myFolder.getPath()); > AccessControlUtils.clear(myFolder, firstUserPrincipal.getName()); > AccessControlUtils.addAccessControlEntry(adminSession, > myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_READ}, > true); > adminSession.save(); > adminSession.logout(); > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7879) ACL can be modified on versioned node without having to check-out the node first
Marco Piovesana created OAK-7879: Summary: ACL can be modified on versioned node without having to check-out the node first Key: OAK-7879 URL: https://issues.apache.org/jira/browse/OAK-7879 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 1.8.8 Reporter: Marco Piovesana If I create the first version of a node *after* adding an ACE to it, then I can add or remove other ACE without having to checkout the node. If I create the first version of the node *before* adding the first ACE, then I get the error (_OakVersion0001: Cannot change property jcr:mixinTypes on checked in node_) whenever i try to modify the node permissions without checking it out first. Following a code snippet showing the first case: {code:java} Session adminSession = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((JackrabbitSession) adminSession).getUserManager(); User firstUser = userManager.createUser("firstUser", "firstUser", new PrincipalImpl("firstUser"), null); Principal firstUserPrincipal = firstUser.getPrincipal(); adminSession.save(); Node myFolder = JcrUtils.getOrAddNode(adminSession.getRootNode(), "my folder", "nt:folder"); myFolder.addMixin(JcrConstants.MIX_VERSIONABLE); AccessControlUtils.addAccessControlEntry(adminSession, myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_ALL}, true); adminSession.save(); VersionManager versionManager = adminSession.getWorkspace().getVersionManager(); versionManager.checkout(myFolder.getPath()); versionManager.checkin(myFolder.getPath()); AccessControlUtils.clear(myFolder, firstUserPrincipal.getName()); AccessControlUtils.addAccessControlEntry(adminSession, myFolder.getPath(), firstUserPrincipal, new String[]{Privilege.JCR_READ}, true); adminSession.save(); adminSession.logout(); {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7481) onParentVersion IGNORE is respected also for unstructured nodes
Marco Piovesana created OAK-7481: Summary: onParentVersion IGNORE is respected also for unstructured nodes Key: OAK-7481 URL: https://issues.apache.org/jira/browse/OAK-7481 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.8.1 Reporter: Marco Piovesana When versioning an unstructured node, a property with onParentVersion=IGNORE is not copied in the frozen node: {code:java} NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); nt.setName("custom:runtime"); nt.setMixin(true); PropertyDefinitionTemplate opt = nodeTypeManager.createPropertyDefinitionTemplate(); opt.setMandatory(false); opt.setName("custom:runtimeTest"); opt.setRequiredType(PropertyType.LONG); opt.setOnParentVersion(OnParentVersionAction.IGNORE); List pdt = nt.getPropertyDefinitionTemplates(); pdt.add(opt); nodeTypeManager.registerNodeType(nt, true); session.save(); Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); mynode.addMixin(JcrConstants.MIX_VERSIONABLE); mynode.addMixin("custom:runtime"); session.save(); mynode.setProperty("custom:runtimeTest", "my test value"); session.save(); session.save(); VersionManager versionManager = session.getWorkspace().getVersionManager(); versionManager.checkout(mynode.getPath()); Version version = versionManager.checkin(mynode.getPath()); {code} the frozen node connected to the created version does not contain the property "custom:runtimeTest" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7479) custom property does not respect type
[ https://issues.apache.org/jira/browse/OAK-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465640#comment-16465640 ] Marco Piovesana commented on OAK-7479: -- Sure, so is not possible to have version-independent properties in unstructured nodes? > custom property does not respect type > -- > > Key: OAK-7479 > URL: https://issues.apache.org/jira/browse/OAK-7479 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.1, 1.8.1 > Environment: The repository is file system based: > {code:java} > File driveFile = new File(directory, "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); > fileStore = > FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); > nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); > Jcr jcr = new Jcr(nodeStore); > repository = jcr.createRepository(); > {code} >Reporter: Marco Piovesana >Priority: Major > Attachments: oakRunImage.png > > > I've defined a custom mixin with s single *long* property. When I add that > mixin to a node I can set a value of a different type (e.g. *string*) without > any error. Same behaviour if I define the mixin using the {{customCND}} or > using the {{NodeTypeTemplate.}} > Here the code example: > {code:java} > NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); > NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); > nt.setName("custom:runtime"); > nt.setMixin(true); > PropertyDefinitionTemplate opt = > nodeTypeManager.createPropertyDefinitionTemplate(); > opt.setMandatory(false); > opt.setName("custom:runtimeTest"); > opt.setRequiredType(PropertyType.LONG); > opt.setOnParentVersion(OnParentVersionAction.COPY); > List pdt = nt.getPropertyDefinitionTemplates(); > pdt.add(opt); > nodeTypeManager.registerNodeType(nt, true); > session.save(); > Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); > mynode.addMixin("custom:runtime"); > session.save(); > mynode.setProperty("custom:runtimeTest", "my test value"); > session.save();{code} > If I open the repository using oak-run the property {{custom:runtimeTest}} > has type STRING and not LONG (attached image) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7479) custom property does not respect type
[ https://issues.apache.org/jira/browse/OAK-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465567#comment-16465567 ] Marco Piovesana commented on OAK-7479: -- Hi Marcel, thanks for the clarification, but then I have another question: if I set the "onParentVersion" to IGNORE the property is not copied in the frozen node, why it does respect that constraint but not the type? > custom property does not respect type > -- > > Key: OAK-7479 > URL: https://issues.apache.org/jira/browse/OAK-7479 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.1, 1.8.1 > Environment: The repository is file system based: > {code:java} > File driveFile = new File(directory, "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); > fileStore = > FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); > nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); > Jcr jcr = new Jcr(nodeStore); > repository = jcr.createRepository(); > {code} >Reporter: Marco Piovesana >Priority: Major > Attachments: oakRunImage.png > > > I've defined a custom mixin with s single *long* property. When I add that > mixin to a node I can set a value of a different type (e.g. *string*) without > any error. Same behaviour if I define the mixin using the {{customCND}} or > using the {{NodeTypeTemplate.}} > Here the code example: > {code:java} > NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); > NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); > nt.setName("custom:runtime"); > nt.setMixin(true); > PropertyDefinitionTemplate opt = > nodeTypeManager.createPropertyDefinitionTemplate(); > opt.setMandatory(false); > opt.setName("custom:runtimeTest"); > opt.setRequiredType(PropertyType.LONG); > opt.setOnParentVersion(OnParentVersionAction.COPY); > List pdt = nt.getPropertyDefinitionTemplates(); > pdt.add(opt); > nodeTypeManager.registerNodeType(nt, true); > session.save(); > Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); > mynode.addMixin("custom:runtime"); > session.save(); > mynode.setProperty("custom:runtimeTest", "my test value"); > session.save();{code} > If I open the repository using oak-run the property {{custom:runtimeTest}} > has type STRING and not LONG (attached image) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7479) custom property does not respect type
[ https://issues.apache.org/jira/browse/OAK-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-7479: - Description: I've defined a custom mixin with s single *long* property. When I add that mixin to a node I can set a value of a different type (e.g. *string*) without any error. Same behaviour if I define the mixin using the {{customCND}} or using the {{NodeTypeTemplate.}} Here the code example: {code:java} NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); nt.setName("custom:runtime"); nt.setMixin(true); PropertyDefinitionTemplate opt = nodeTypeManager.createPropertyDefinitionTemplate(); opt.setMandatory(false); opt.setName("custom:runtimeTest"); opt.setRequiredType(PropertyType.LONG); opt.setOnParentVersion(OnParentVersionAction.COPY); List pdt = nt.getPropertyDefinitionTemplates(); pdt.add(opt); nodeTypeManager.registerNodeType(nt, true); session.save(); Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); mynode.addMixin("custom:runtime"); session.save(); mynode.setProperty("custom:runtimeTest", "my test value"); session.save();{code} If I open the repository using oak-run the property {{custom:runtimeTest}} has type STRING and not LONG (attached image) was: I've defined a custom mixin with s single *long* property. When I add that mixing to a node I can set a value of a different type (e.g. *string*) without any error. Same behaviour if I define the mixin using the {{customCND}} or using the {{NodeTypeTemplate.}} Here the code example: {code:java} NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); nt.setName("custom:runtime"); nt.setMixin(true); PropertyDefinitionTemplate opt = nodeTypeManager.createPropertyDefinitionTemplate(); opt.setMandatory(false); opt.setName("custom:runtimeTest"); opt.setRequiredType(PropertyType.LONG); opt.setOnParentVersion(OnParentVersionAction.COPY); List pdt = nt.getPropertyDefinitionTemplates(); pdt.add(opt); nodeTypeManager.registerNodeType(nt, true); session.save(); Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); mynode.addMixin("custom:runtime"); session.save(); mynode.setProperty("custom:runtimeTest", "my test value"); session.save();{code} If I open the repository using oak-run the property {{custom:runtimeTest}} has type STRING and not LONG (attached image) > custom property does not respect type > -- > > Key: OAK-7479 > URL: https://issues.apache.org/jira/browse/OAK-7479 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.1, 1.8.1 > Environment: The repository is file system based: > {code:java} > File driveFile = new File(directory, "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); > fileStore = > FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); > nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); > Jcr jcr = new Jcr(nodeStore); > repository = jcr.createRepository(); > {code} >Reporter: Marco Piovesana >Priority: Major > Attachments: oakRunImage.png > > > I've defined a custom mixin with s single *long* property. When I add that > mixin to a node I can set a value of a different type (e.g. *string*) without > any error. Same behaviour if I define the mixin using the {{customCND}} or > using the {{NodeTypeTemplate.}} > Here the code example: > {code:java} > NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); > NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); > nt.setName("custom:runtime"); > nt.setMixin(true); > PropertyDefinitionTemplate opt = > nodeTypeManager.createPropertyDefinitionTemplate(); > opt.setMandatory(false); > opt.setName("custom:runtimeTest"); > opt.setRequiredType(PropertyType.LONG); > opt.setOnParentVersion(OnParentVersionAction.COPY); > List pdt = nt.getPropertyDefinitionTemplates(); > pdt.add(opt); > nodeTypeManager.registerNodeType(nt, true); > session.save(); > Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); > mynode.addMixin("custom:runtime"); > session.save(); > mynode.setProperty("custom:runtimeTest", "my test value"); > session.save();{code} > If I open the repository using oak-run the property {{custom:runtimeTest}} > has type STRING and not LONG (attached image) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7479) custom property does not respect type
[ https://issues.apache.org/jira/browse/OAK-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463834#comment-16463834 ] Marco Piovesana commented on OAK-7479: -- The issue seems similar to OAK-3621 that was closed in version 1.4 > custom property does not respect type > -- > > Key: OAK-7479 > URL: https://issues.apache.org/jira/browse/OAK-7479 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.1, 1.8.1 > Environment: The repository is file system based: > {code:java} > File driveFile = new File(directory, "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); > fileStore = > FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); > nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); > Jcr jcr = new Jcr(nodeStore); > repository = jcr.createRepository(); > {code} >Reporter: Marco Piovesana >Priority: Major > Attachments: oakRunImage.png > > > I've defined a custom mixin with s single *long* property. When I add that > mixing to a node I can set a value of a different type (e.g. *string*) > without any error. Same behaviour if I define the mixin using the > {{customCND}} or using the {{NodeTypeTemplate.}} > Here the code example: > {code:java} > NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); > NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); > nt.setName("custom:runtime"); > nt.setMixin(true); > PropertyDefinitionTemplate opt = > nodeTypeManager.createPropertyDefinitionTemplate(); > opt.setMandatory(false); > opt.setName("custom:runtimeTest"); > opt.setRequiredType(PropertyType.LONG); > opt.setOnParentVersion(OnParentVersionAction.COPY); > List pdt = nt.getPropertyDefinitionTemplates(); > pdt.add(opt); > nodeTypeManager.registerNodeType(nt, true); > session.save(); > Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); > mynode.addMixin("custom:runtime"); > session.save(); > mynode.setProperty("custom:runtimeTest", "my test value"); > session.save();{code} > If I open the repository using oak-run the property {{custom:runtimeTest}} > has type STRING and not LONG (attached image) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7479) custom property does not respect type
Marco Piovesana created OAK-7479: Summary: custom property does not respect type Key: OAK-7479 URL: https://issues.apache.org/jira/browse/OAK-7479 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.8.1, 1.6.1 Environment: The repository is file system based: {code:java} File driveFile = new File(directory, "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); fileStore = FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); nodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); Jcr jcr = new Jcr(nodeStore); repository = jcr.createRepository(); {code} Reporter: Marco Piovesana Attachments: oakRunImage.png I've defined a custom mixin with s single *long* property. When I add that mixing to a node I can set a value of a different type (e.g. *string*) without any error. Same behaviour if I define the mixin using the {{customCND}} or using the {{NodeTypeTemplate.}} Here the code example: {code:java} NodeTypeManager nodeTypeManager = session.getWorkspace().getNodeTypeManager(); NodeTypeTemplate nt = nodeTypeManager.createNodeTypeTemplate(); nt.setName("custom:runtime"); nt.setMixin(true); PropertyDefinitionTemplate opt = nodeTypeManager.createPropertyDefinitionTemplate(); opt.setMandatory(false); opt.setName("custom:runtimeTest"); opt.setRequiredType(PropertyType.LONG); opt.setOnParentVersion(OnParentVersionAction.COPY); List pdt = nt.getPropertyDefinitionTemplates(); pdt.add(opt); nodeTypeManager.registerNodeType(nt, true); session.save(); Node mynode = JcrUtils.getOrAddNode(session.getRootNode(), "mynode"); mynode.addMixin("custom:runtime"); session.save(); mynode.setProperty("custom:runtimeTest", "my test value"); session.save();{code} If I open the repository using oak-run the property {{custom:runtimeTest}} has type STRING and not LONG (attached image) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6418) CONTAINS SQL2 parameter does not work
[ https://issues.apache.org/jira/browse/OAK-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074839#comment-16074839 ] Marco Piovesana commented on OAK-6418: -- Hi Davide, yes I did read the documentation about the query engine. But I'm not sure that I get your point: do you mean that without a fulltext index the "_CONTAINS_" operator does not work? Isn't this in contrast with what's written in the query engine documentation? (??If there is no index for a specific query, then the repository will be traversed. That is, the query will still work but probably be very slow??). Marco. > CONTAINS SQL2 parameter does not work > - > > Key: OAK-6418 > URL: https://issues.apache.org/jira/browse/OAK-6418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.6.1 >Reporter: Marco Piovesana > > Query result is wrong when using the "CONTAINS" operator. See the following > test example: > {code:borderStyle=solid} > @Test > public void shouldFindOneElement() throws Exception { > File driveFile = new File("/tmp/oakTest", "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new > FileBlobStore(dataStoreFile.getAbsolutePath()); > FileStore fileStore = > FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); > SegmentNodeStore segmentNodeStore = > SegmentNodeStoreBuilders.builder(fileStore).build(); > Jcr jcr = new Jcr(segmentNodeStore).with(new > InitialContent()).with(new SecurityProviderImpl()); > Repository repository = jcr.createRepository(); > Session session = repository.login(ADMIN_CREDENTIALS); > Node myNode = session.getRootNode().addNode("myNode"); > myNode.setProperty("text", "hello_world"); > session.save(); > QueryManager qm = session.getWorkspace().getQueryManager(); > Query q = qm.createQuery("select * from [nt:base] where > CONTAINS([text],'hello_world')", Query.JCR_SQL2); > QueryResult execute = q.execute(); > long foundNodes = execute.getNodes().getSize(); > session.logout(); > fileStore.close(); > ((JackrabbitRepository) repository).shutdown(); > assertEquals(1L, foundNodes); > } > {code} > The test fails because the query return 0 results while it should return 1. > It works fine if instead of executing: > {code} select * from [nt:base] where CONTAINS([text],'hello_world') {code} > I run it using the LIKE operator: > {code} select * from [nt:base] where [text] LIKE 'hello_world' {code} > I also tried to run the same test inside the > _org.apache.jackrabbit.oak.jcr.query.QueryTest.java_, but there it works > fine. Here the test i run: > {code} > @Test > public void shouldFindNodeUsingContainsOperator() throws > RepositoryException { > Session session = getAdminSession(); > Node hello = session.getRootNode().addNode("hello"); > hello.setProperty("text", "hello_world"); > session.save(); > QueryManager qm = session.getWorkspace().getQueryManager(); > Query q = qm.createQuery("select * from [nt:base] where > CONTAINS([text],'hello_world')", Query.JCR_SQL2); > QueryResult r = q.execute(); > NodeIterator nodes = r.getNodes(); > assertEquals(1, nodes.getSize()); > } > {code} > Marco. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6418) CONTAINS SQL2 parameter does not work
Marco Piovesana created OAK-6418: Summary: CONTAINS SQL2 parameter does not work Key: OAK-6418 URL: https://issues.apache.org/jira/browse/OAK-6418 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 1.6.1 Reporter: Marco Piovesana Query result is wrong when using the "CONTAINS" operator. See the following test example: {code:borderStyle=solid} @Test public void shouldFindOneElement() throws Exception { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore fileStore = FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); SegmentNodeStore segmentNodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); Jcr jcr = new Jcr(segmentNodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(ADMIN_CREDENTIALS); Node myNode = session.getRootNode().addNode("myNode"); myNode.setProperty("text", "hello_world"); session.save(); QueryManager qm = session.getWorkspace().getQueryManager(); Query q = qm.createQuery("select * from [nt:base] where CONTAINS([text],'hello_world')", Query.JCR_SQL2); QueryResult execute = q.execute(); long foundNodes = execute.getNodes().getSize(); session.logout(); fileStore.close(); ((JackrabbitRepository) repository).shutdown(); assertEquals(1L, foundNodes); } {code} The test fails because the query return 0 results while it should return 1. It works fine if instead of executing: {code} select * from [nt:base] where CONTAINS([text],'hello_world') {code} I run it using the LIKE operator: {code} select * from [nt:base] where [text] LIKE 'hello_world' {code} I also tried to run the same test inside the _org.apache.jackrabbit.oak.jcr.query.QueryTest.java_, but there it works fine. Here the test i run: {code} @Test public void shouldFindNodeUsingContainsOperator() throws RepositoryException { Session session = getAdminSession(); Node hello = session.getRootNode().addNode("hello"); hello.setProperty("text", "hello_world"); session.save(); QueryManager qm = session.getWorkspace().getQueryManager(); Query q = qm.createQuery("select * from [nt:base] where CONTAINS([text],'hello_world')", Query.JCR_SQL2); QueryResult r = q.execute(); NodeIterator nodes = r.getNodes(); assertEquals(1, nodes.getSize()); } {code} Marco. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[ https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-6015: - Description: On a versione node _nodeA_ i can do: {{AccessControlUtils.clear(nodeA, userPrincipal)}} without having to checkout the node. After saving the session I tried to login as _userPrincipal_ and I couldn't find _nodeA_, so it seems that the clear operation did work even if the node was checked-in. was: On a versione node _nodeA_ i can do: {{AccessControlUtils.clear(nodeA, userPrincipal)}} without having to checkout the node. After saving the session I tried to login as _userPrincipal_ and I couldn't find _nodeA_, so it seems that the clear operation did work even if the node was checkedin. > ACL of versioned node can be modified without checking out the node > --- > > Key: OAK-6015 > URL: https://issues.apache.org/jira/browse/OAK-6015 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > On a versione node _nodeA_ i can do: > {{AccessControlUtils.clear(nodeA, userPrincipal)}} > without having to checkout the node. > After saving the session I tried to login as _userPrincipal_ and I couldn't > find _nodeA_, so it seems that the clear operation did work even if the node > was checked-in. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6015) ACL of versioned node can be modified without checking in the node
[ https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953206#comment-15953206 ] Marco Piovesana commented on OAK-6015: -- Yes I'm sorry, I wrote checkin instead of checkout. I'm updating title and description right away. Marco. > ACL of versioned node can be modified without checking in the node > -- > > Key: OAK-6015 > URL: https://issues.apache.org/jira/browse/OAK-6015 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > On a versione node _nodeA_ i can do: > {{AccessControlUtils.clear(nodeA, userPrincipal)}} > without having to checkin the node. > After saving the session I tried to login as _userPrincipal_ and I couldn't > find _nodeA_, so it seems that the clear operation did work even if the node > was checked-out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[ https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-6015: - Description: On a versione node _nodeA_ i can do: {{AccessControlUtils.clear(nodeA, userPrincipal)}} without having to checkout the node. After saving the session I tried to login as _userPrincipal_ and I couldn't find _nodeA_, so it seems that the clear operation did work even if the node was checkedin. was: On a versione node _nodeA_ i can do: {{AccessControlUtils.clear(nodeA, userPrincipal)}} without having to checkin the node. After saving the session I tried to login as _userPrincipal_ and I couldn't find _nodeA_, so it seems that the clear operation did work even if the node was checked-out. > ACL of versioned node can be modified without checking out the node > --- > > Key: OAK-6015 > URL: https://issues.apache.org/jira/browse/OAK-6015 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > On a versione node _nodeA_ i can do: > {{AccessControlUtils.clear(nodeA, userPrincipal)}} > without having to checkout the node. > After saving the session I tried to login as _userPrincipal_ and I couldn't > find _nodeA_, so it seems that the clear operation did work even if the node > was checkedin. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[ https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-6015: - Summary: ACL of versioned node can be modified without checking out the node (was: ACL of versioned node can be modified without checking in the node) > ACL of versioned node can be modified without checking out the node > --- > > Key: OAK-6015 > URL: https://issues.apache.org/jira/browse/OAK-6015 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > On a versione node _nodeA_ i can do: > {{AccessControlUtils.clear(nodeA, userPrincipal)}} > without having to checkin the node. > After saving the session I tried to login as _userPrincipal_ and I couldn't > find _nodeA_, so it seems that the clear operation did work even if the node > was checked-out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6015) ACL of versioned node can be modified without checking in the node
[ https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953102#comment-15953102 ] Marco Piovesana commented on OAK-6015: -- Sure, in the test I first grant to "testUser" some privileges and then i try to clear them without checking out the node: {code:title=ACLErrorTest.java|borderStyle=solid} @Test(expected = VersionException.class) public void shouldFailWhenTryingToChangeNodeSharestOnCheckedOutNode() throws IOException, RepositoryException, InvalidFileStoreVersionException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore fileStore = FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build(); SegmentNodeStore segmentNodeStore = SegmentNodeStoreBuilders.builder(fileStore).build(); Jcr jcr = new Jcr(segmentNodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(ADMIN_CREDENTIALS); User user = ((JackrabbitSession) session).getUserManager().createUser("testUser", "testUser", new PrincipalImpl("testUser"), null); session.save(); VersionManager versionManager = session.getWorkspace().getVersionManager(); Node testFolder = JcrUtils.getOrAddNode(session.getRootNode(), "myfile", JcrConstants.NT_FOLDER); testFolder.addMixin(JcrConstants.MIX_VERSIONABLE); session.save(); versionManager.checkout(testFolder.getPath()); versionManager.checkin(testFolder.getPath()); versionManager.checkout(testFolder.getPath()); AccessControlUtils.addAccessControlEntry(testFolder.getSession(), testFolder.getPath(), user.getPrincipal(), new String[]{Privilege.JCR_ALL}, true); session.save(); versionManager.checkin(testFolder.getPath()); AccessControlUtils.clear(testFolder, user.getPrincipal().getName()); session.save(); session.logout(); repositoryStore.close(); ((JackrabbitRepository) repository).shutdown(); } {code} > ACL of versioned node can be modified without checking in the node > -- > > Key: OAK-6015 > URL: https://issues.apache.org/jira/browse/OAK-6015 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > On a versione node _nodeA_ i can do: > {{AccessControlUtils.clear(nodeA, userPrincipal)}} > without having to checkin the node. > After saving the session I tried to login as _userPrincipal_ and I couldn't > find _nodeA_, so it seems that the clear operation did work even if the node > was checked-out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6015) ACL of versioned node can be modified without checking in the node
Marco Piovesana created OAK-6015: Summary: ACL of versioned node can be modified without checking in the node Key: OAK-6015 URL: https://issues.apache.org/jira/browse/OAK-6015 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.6.0 Reporter: Marco Piovesana On a versione node _nodeA_ i can do: {{AccessControlUtils.clear(nodeA, userPrincipal)}} without having to checkin the node. After saving the session I tried to login as _userPrincipal_ and I couldn't find _nodeA_, so it seems that the clear operation did work even if the node was checked-out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-5919) Discrepancy between addAccessControlEntry and clear on versioned node
[ https://issues.apache.org/jira/browse/OAK-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936737#comment-15936737 ] Marco Piovesana edited comment on OAK-5919 at 3/22/17 5:36 PM: --- Hi Angela, my bad for also asking also a question inside the issue. However, isn't the different behaviour between {{clear}} and {{addAccessControlEntry}} a bug? Marco. was (Author: iosonomarco): Hi Angela, my bad for also asking a question inside the issue. However, isn't the different behaviour between {{clear}} and {{addAccessControlEntry}} a bug? Marco. > Discrepancy between addAccessControlEntry and clear on versioned node > - > > Key: OAK-5919 > URL: https://issues.apache.org/jira/browse/OAK-5919 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > I was trying to change the permissions on a *versioned* node and i found two > things that I don't quite understand: > 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got > an error if the node in not checked-out (and this seems consistent with what > written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). > However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? > Aren't they both changing the ACL? > 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that > i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked > in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node > was already versionable. > One last question: if I want to change the permissions without having to > check-out the node what I have to do? (I can do that by setting the > _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5919) Discrepancy between addAccessControlEntry and clear on versioned node
[ https://issues.apache.org/jira/browse/OAK-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936737#comment-15936737 ] Marco Piovesana commented on OAK-5919: -- Hi Angela, my bad for also asking a question inside the issue. However, isn't the different behaviour between {{clear}} and {{addAccessControlEntry}} a bug? Marco. > Discrepancy between addAccessControlEntry and clear on versioned node > - > > Key: OAK-5919 > URL: https://issues.apache.org/jira/browse/OAK-5919 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > I was trying to change the permissions on a *versioned* node and i found two > things that I don't quite understand: > 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got > an error if the node in not checked-out (and this seems consistent with what > written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). > However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? > Aren't they both changing the ACL? > 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that > i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked > in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node > was already versionable. > One last question: if I want to change the permissions without having to > check-out the node what I have to do? (I can do that by setting the > _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5919) Discrepancy between addAccessControlEntry and clear on versioned node
[ https://issues.apache.org/jira/browse/OAK-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933055#comment-15933055 ] Marco Piovesana commented on OAK-5919: -- Does anybody have any hint about this? > Discrepancy between addAccessControlEntry and clear on versioned node > - > > Key: OAK-5919 > URL: https://issues.apache.org/jira/browse/OAK-5919 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > I was trying to change the permissions on a *versioned* node and i found two > things that I don't quite understand: > 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got > an error if the node in not checked-out (and this seems consistent with what > written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). > However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? > Aren't they both changing the ACL? > 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that > i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked > in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node > was already versionable. > One last question: if I want to change the permissions without having to > check-out the node what I have to do? (I can do that by setting the > _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5919) Discrepancy between addAccessControlEntry and clear on versioned node
[ https://issues.apache.org/jira/browse/OAK-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-5919: - Description: I was trying to change the permissions on a *versioned* node and i found two things that I don't quite understand: 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got an error if the node in not checked-out (and this seems consistent with what written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? Aren't they both changing the ACL? 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node was already versionable. One last question: if I want to change the permissions without having to check-out the node what I have to do? (I can do that by setting the _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) was: I was trying to change the permissions on a *versioned* node and i found two things that don't quite understand: 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got an error if the node in not checked-out (and this seems consistent with what written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? Aren't they both changing the ACL? 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node was already versionable. One last question: if I want to change the permissions without having to check-out the node what I have to do? (I can do that by setting the _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) > Discrepancy between addAccessControlEntry and clear on versioned node > - > > Key: OAK-5919 > URL: https://issues.apache.org/jira/browse/OAK-5919 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Marco Piovesana > > I was trying to change the permissions on a *versioned* node and i found two > things that I don't quite understand: > 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got > an error if the node in not checked-out (and this seems consistent with what > written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). > However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? > Aren't they both changing the ACL? > 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that > i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked > in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node > was already versionable. > One last question: if I want to change the permissions without having to > check-out the node what I have to do? (I can do that by setting the > _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-5919) Discrepancy between addAccessControlEntry and clear on versioned node
Marco Piovesana created OAK-5919: Summary: Discrepancy between addAccessControlEntry and clear on versioned node Key: OAK-5919 URL: https://issues.apache.org/jira/browse/OAK-5919 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 1.6.0 Reporter: Marco Piovesana I was trying to change the permissions on a *versioned* node and i found two things that don't quite understand: 1) If i try to do an {{AccessControlUtils.addAccessControlEntry(...)}} i got an error if the node in not checked-out (and this seems consistent with what written on [JCR-1639|https://issues.apache.org/jira/browse/JCR-1639]). However I can do an {{AccessControlUtils.clear(...)}} without any error. Why? Aren't they both changing the ACL? 2) When I do {{AccessControlUtils.addAccessControlEntry(...)}} the error that i receive is: _OakVersion0001: Cannot add property jcr:mixinTypes on checked in node_. Why a change on the ACL should change the _jcr:mixinTypes_? My node was already versionable. One last question: if I want to change the permissions without having to check-out the node what I have to do? (I can do that by setting the _jcr:mixinTypes_ to _IGNORE_ but i don't think is the right way... or not?) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15745594#comment-15745594 ] Marco Piovesana commented on OAK-3328: -- Hi Marcel, do you know, more less, how long does it take to know if the patch is accepted or rejected? thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328-updated.patch, > proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: proposed_fix_for_OAK_3328-updated.patch Sorry, i thought i had restored the format for all the files. Now it should be ok. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328-updated.patch, > proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: proposed_fix_for_OAK_3328.patch Sorry, I had to modify the patch file because my editor changed the formatting style. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: (was: proposed_fix_for_OAK_3328.patch) > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: proposed_fix_for_OAK_3328.patch Hi Marcel, I think I've got a solution for the bug with the relative tests. I've attached it to the issue, is it ok? What should I do to propose it? Let me know if the solution looks ok for you guys. thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Comment: was deleted (was: Hi Marcel, I think I've got a solution for the bug with the relative tests. I've attached it to the issue, is it ok? What should I do to propose it? Let me know if the solution looks ok for you guys. thanks, Marco.) > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: (was: proposed_fix_for_OAK_3328.patch) > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Attachment: proposed_fix_for_OAK_3328.patch > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15686235#comment-15686235 ] Marco Piovesana commented on OAK-3328: -- Hi Marcel, I think I've got a solution for the bug with the relative tests. I've attached it to the issue, is it ok? What should I do to propose it? Let me know if the solution looks ok for you guys. thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > Attachments: proposed_fix_for_OAK_3328.patch > > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-3328: - Comment: was deleted (was: I tried, this is what i did: {code:java} Tree parentTree = TreeFactory.createTree(this.parent.node); Tree nodeTree = TreeFactory.createTree(this.node); this.vMgr.getNodeTypeManager().getDefinition(parentTree, nodeTree); {code} but it fails because the generated _nodeTree_ has an empty value per the field "name". If I call _getDefinition_ using the node name (the string instead of the tree) it does work though. How can i get the node name from the _NodeState_ without casting it to _SegmentNodeState_ ?) > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15683183#comment-15683183 ] Marco Piovesana edited comment on OAK-3328 at 11/21/16 10:49 AM: - I tried, this is what i did: {code:java} Tree parentTree = TreeFactory.createTree(this.parent.node); Tree nodeTree = TreeFactory.createTree(this.node); this.vMgr.getNodeTypeManager().getDefinition(parentTree, nodeTree); {code} but it fails because the generated _nodeTree_ has an empty value per the field "name". If I call _getDefinition_ using the node name (the string instead of the tree) it does work though. How can i get the node name from the _NodeState_ without casting it to _SegmentNodeState_ ? was (Author: iosonomarco): I tried, this is what i did: {code:java} Tree parentTree = TreeFactory.createTree(this.parent.node); Tree nodeTree = TreeFactory.createTree(this.node); this.vMgr.getNodeTypeManager().getDefinition(parentTree, nodeTree); {code} but it fails because the generated _nodeTree_ has an empty value per the field "name". If I call _getDefinition_ using the node name it does work though. How can i get the node name from the _NodeState_ without casting it to _SegmentNodeState_ ? > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15683183#comment-15683183 ] Marco Piovesana commented on OAK-3328: -- I tried, this is what i did: {code:java} Tree parentTree = TreeFactory.createTree(this.parent.node); Tree nodeTree = TreeFactory.createTree(this.node); this.vMgr.getNodeTypeManager().getDefinition(parentTree, nodeTree); {code} but it fails because the generated _nodeTree_ has an empty value per the field "name". If I call _getDefinition_ using the node name it does work though. How can i get the node name from the _NodeState_ without casting it to _SegmentNodeState_ ? > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674325#comment-15674325 ] Marco Piovesana edited comment on OAK-3328 at 11/19/16 6:25 PM: Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} Is possible to extract the NodeDefinition from the NodeState (to check weather the node has the "IGNORE" property or not)? I tried but I don't seem to find a way to do it. This way i can modify the method that defines the value for the _isReadOnly_ property. By the way, is that the right thing to do? Marco. was (Author: iosonomarco): Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} Is possible to extract the NodeDefinition from the NodeState (to check weather the node has the "IGNORE" property or not)? I tried but I don't seem to find a way to do it. This way i can modify the method that defines the value for the _readOnly_ property. By the way, is that the right thing to do? Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674325#comment-15674325 ] Marco Piovesana edited comment on OAK-3328 at 11/19/16 6:25 PM: Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} Is possible to extract the NodeDefinition from the NodeState (to check weather the node has the "IGNORE" property or not)? I tried but I don't seem to find a way to do it. This way i can modify the method that defines the value for the _readOnly_ property. By the way, is that the right thing to do? Marco. was (Author: iosonomarco): Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} Is possible to extract the NodeDefinition from the NodeState (to check weather the node has the "IGNORE" property or not)? Is that the right thing to do? Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674325#comment-15674325 ] Marco Piovesana edited comment on OAK-3328 at 11/19/16 6:22 PM: Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} Is possible to extract the NodeDefinition from the NodeState (to check weather the node has the "IGNORE" property or not)? Is that the right thing to do? Marco. was (Author: iosonomarco): Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} do you know how can i check the OPV settings of this property (or its parent node) to see if is set to "IGNORE"? Is that the right thing to do? Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674325#comment-15674325 ] Marco Piovesana commented on OAK-3328: -- Hi Marcel, thanks for the hint. I did try to look at the patch and modify _checkPrecondition_ method. I was able to modify the property but i still get an error when trying to save the session. It fails inside the class _VersionEditor_ because of this check: {code:java} public void propertyChanged(PropertyState before, PropertyState after) throws CommitFailedException { if(!this.isVersionable()) { if(!this.isVersionProperty(after) && this.isReadOnly) { throwCheckedIn("Cannot change property " + after.getName() + " on checked in node"); } {code} do you know how can i check the OPV settings of this property (or its parent node) to see if is set to "IGNORE"? Is that the right thing to do? Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674020#comment-15674020 ] Marco Piovesana edited comment on OAK-3328 at 11/17/16 3:44 PM: Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find where to fix it, but I haven't been able to find a complete solution.. thanks, Marco. was (Author: iosonomarco): Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674020#comment-15674020 ] Marco Piovesana edited comment on OAK-3328 at 11/17/16 3:44 PM: Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find how to fix it, but I haven't been able to find a complete solution.. thanks, Marco. was (Author: iosonomarco): Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? I also tried to find where to fix it, but I haven't been able to find a complete solution.. thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3328) checked-in state should only affect properties with OPV!=IGNORE
[ https://issues.apache.org/jira/browse/OAK-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674020#comment-15674020 ] Marco Piovesana commented on OAK-3328: -- Hi all, i'm using oak to implement a functionality that relies on this behaviour. Is there any plan to resolve this bug in the near future? thanks, Marco. > checked-in state should only affect properties with OPV!=IGNORE > --- > > Key: OAK-3328 > URL: https://issues.apache.org/jira/browse/OAK-3328 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Julian Reschke > > We currently (as of OAK-3310) protect all properties from changes when the > node is checked-in. According to the spec > (http://www.day.com/specs/jcr/2.0/15_Versioning.html#15.2.2%20Read-Only%20on%20Check-In), > this should only be the case when on-parent-version is != "IGNORE". > (It seems this doesn't have TCK coverage) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4646) How can i remove a registered custom privilege
[ https://issues.apache.org/jira/browse/OAK-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4646: - Description: I did register a custom privilege: {code} PrivilegeManager privilegeManager = ((JackrabbitWorkspace) session.getWorkspace()).getPrivilegeManager(); Privilege privilege = privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new String[0]); {code} How can i delete it? There's an automated way to specify all my custom privileges (like the file _*.config_ for the custom node types)? was: I did register a custom privilege: {code} PrivilegeManager privilegeManager = ((JackrabbitWorkspace) session.getWorkspace()).getPrivilegeManager(); Privilege privilege = privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new String[0]); {code} How can i delete it? There's an automated way to specify all my custom privileges(like the file _*.config_ for the custom node types)? > How can i remove a registered custom privilege > -- > > Key: OAK-4646 > URL: https://issues.apache.org/jira/browse/OAK-4646 > Project: Jackrabbit Oak > Issue Type: Wish > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I did register a custom privilege: > {code} > PrivilegeManager privilegeManager = ((JackrabbitWorkspace) > session.getWorkspace()).getPrivilegeManager(); > Privilege privilege = > privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new > String[0]); > {code} > How can i delete it? There's an automated way to specify all my custom > privileges (like the file _*.config_ for the custom node types)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4646) How can i remove a registered custom privilege
Marco Piovesana created OAK-4646: Summary: How can i remove a registered custom privilege Key: OAK-4646 URL: https://issues.apache.org/jira/browse/OAK-4646 Project: Jackrabbit Oak Issue Type: Wish Components: core Affects Versions: 1.4.5 Reporter: Marco Piovesana I did register a custom privilege: {code} PrivilegeManager privilegeManager = ((JackrabbitWorkspace) session.getWorkspace()).getPrivilegeManager(); Privilege privilege = privilegeManager.registerPrivilege("custom:mycustomprivilege", false, new String[0]); {code} How can i delete it? There's an automated way to specify all my custom privileges(like the file _*.config_ for the custom node types)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4632) remove node management
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana resolved OAK-4632. -- Resolution: Not A Bug there was a mistake in my code > remove node management > -- > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder and gives JCR_READ privilege to _userA_. When > _userA_ tries to delete the folder no exception is thrown and the folder is > deleted. _admin_ however can still view the node. > If i give to _userA_ the privilege to remove the node: > {code:java} > AccessControlUtils.addAccessControlEntry(session, folder.getPath(), > userA.getPrincipal(), new String[]{Privilege.JCR_REMOVE_CHILD_NODES}, true); > AccessControlUtils.addAccessControlEntry(session, > otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ, > Privilege.JCR_REMOVE_NODE}, true); > {code} > nothing changes. > Is this the expected behaviour? How can i give to _userA_ the privilege to > completely remove the node (remove it also for _admin_)? > {code:title=DeleteTest.java|borderStyle=solid} > public void deleteWithoutPermission() throws IOException, RepositoryException > { > File driveFile = new File("/tmp/oakTest", "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new > FileBlobStore(dataStoreFile.getAbsolutePath()); > FileStore repositoryStore = > FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); > NodeStore nodeStore = > SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); > Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new > SecurityProviderImpl()); > Repository repository = jcr.createRepository(); > Session session = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((SessionImpl) session).getUserManager(); > User userA = userManager.createUser("userA", "userA", new > UserPrincipal("userA"), null); > session.save(); > Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), > "myfolder"); > folder.addMixin(JcrConstants.MIX_SHAREABLE); > Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); > otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); > session.save(); > String path = otherFolder.getPath(); > AccessControlUtils.addAccessControlEntry(session, > otherFolder.getPath(), userA.getPrincipal(), new > String[]{Privilege.JCR_READ}, true); > session.save(); > session.logout(); > session = repository.login(new SimpleCredentials("userA", > "userA".toCharArray())); > Node node = session.getNode(path); > node.remove(); > boolean exist = session.itemExists(path); > session.logout(); > session = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > boolean adminExists = session.itemExists(path); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4632) remove node management
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Description: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node: {code:java} AccessControlUtils.addAccessControlEntry(session, folder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_REMOVE_CHILD_NODES}, true); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ, Privilege.JCR_REMOVE_NODE}, true); {code} nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} was: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node (_Privilege.JCR_REMOVE_NODE_) nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node
[jira] [Updated] (OAK-4632) User with with just JCR_READ privilege can delete a node
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Description: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node (_Privilege.JCR_REMOVE_NODE_) nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} was: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} > User with with just JCR_READ privilege can delete a node > > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4
[jira] [Updated] (OAK-4632) remove node management
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Description: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node: {code:java} AccessControlUtils.addAccessControlEntry(session, folder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_REMOVE_CHILD_NODES}, true); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ, Privilege.JCR_REMOVE_NODE}, true); {code} nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); session.logout(); session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); boolean adminExists = session.itemExists(path); } {code} was: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node: {code:java} AccessControlUtils.addAccessControlEntry(session, folder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_REMOVE_CHILD_NODES}, true); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ, Privilege.JCR_REMOVE_NODE}, true); {code} nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFo
[jira] [Updated] (OAK-4632) remove node management
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Summary: remove node management (was: give a user the privilege to remove a node) > remove node management > -- > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder and gives JCR_READ privilege to _userA_. When > _userA_ tries to delete the folder no exception is thrown and the folder is > deleted. _admin_ however can still view the node. > If i give to _userA_ the privilege to remove the node > (_Privilege.JCR_REMOVE_NODE_) nothing changes. > Is this the expected behaviour? How can i give to _userA_ the privilege to > completely remove the node (remove it also for _admin_)? > {code:title=DeleteTest.java|borderStyle=solid} > public void deleteWithoutPermission() throws IOException, RepositoryException > { > File driveFile = new File("/tmp/oakTest", "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new > FileBlobStore(dataStoreFile.getAbsolutePath()); > FileStore repositoryStore = > FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); > NodeStore nodeStore = > SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); > Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new > SecurityProviderImpl()); > Repository repository = jcr.createRepository(); > Session session = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((SessionImpl) session).getUserManager(); > User userA = userManager.createUser("userA", "userA", new > UserPrincipal("userA"), null); > session.save(); > Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), > "myfolder"); > folder.addMixin(JcrConstants.MIX_SHAREABLE); > Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); > otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); > session.save(); > String path = otherFolder.getPath(); > AccessControlUtils.addAccessControlEntry(session, > otherFolder.getPath(), userA.getPrincipal(), new > String[]{Privilege.JCR_READ}, true); > session.save(); > session.logout(); > session = repository.login(new SimpleCredentials("userA", > "userA".toCharArray())); > Node node = session.getNode(path); > node.remove(); > boolean exist = session.itemExists(path); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4632) give a user the privilege to remove a node
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Summary: give a user the privilege to remove a node (was: remove node behaviour) > give a user the privilege to remove a node > -- > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder and gives JCR_READ privilege to _userA_. When > _userA_ tries to delete the folder no exception is thrown and the folder is > deleted. _admin_ however can still view the node. > If i give to _userA_ the privilege to remove the node > (_Privilege.JCR_REMOVE_NODE_) nothing changes. > Is this the expected behaviour? How can i give to _userA_ the privilege to > completely remove the node (remove it also for _admin_)? > {code:title=DeleteTest.java|borderStyle=solid} > public void deleteWithoutPermission() throws IOException, RepositoryException > { > File driveFile = new File("/tmp/oakTest", "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new > FileBlobStore(dataStoreFile.getAbsolutePath()); > FileStore repositoryStore = > FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); > NodeStore nodeStore = > SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); > Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new > SecurityProviderImpl()); > Repository repository = jcr.createRepository(); > Session session = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((SessionImpl) session).getUserManager(); > User userA = userManager.createUser("userA", "userA", new > UserPrincipal("userA"), null); > session.save(); > Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), > "myfolder"); > folder.addMixin(JcrConstants.MIX_SHAREABLE); > Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); > otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); > session.save(); > String path = otherFolder.getPath(); > AccessControlUtils.addAccessControlEntry(session, > otherFolder.getPath(), userA.getPrincipal(), new > String[]{Privilege.JCR_READ}, true); > session.save(); > session.logout(); > session = repository.login(new SimpleCredentials("userA", > "userA".toCharArray())); > Node node = session.getNode(path); > node.remove(); > boolean exist = session.itemExists(path); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4632) remove node behaviour
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Summary: remove node behaviour (was: User with with just JCR_READ privilege can delete a node) > remove node behaviour > - > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder and gives JCR_READ privilege to _userA_. When > _userA_ tries to delete the folder no exception is thrown and the folder is > deleted. _admin_ however can still view the node. > If i give to _userA_ the privilege to remove the node > (_Privilege.JCR_REMOVE_NODE_) nothing changes. > Is this the expected behaviour? How can i give to _userA_ the privilege to > completely remove the node (remove it also for _admin_)? > {code:title=DeleteTest.java|borderStyle=solid} > public void deleteWithoutPermission() throws IOException, RepositoryException > { > File driveFile = new File("/tmp/oakTest", "oakrepo"); > File repositoryFile = new File(driveFile, "repository"); > File dataStoreFile = new File(driveFile, "datastore"); > BlobStore blobStore = new > FileBlobStore(dataStoreFile.getAbsolutePath()); > FileStore repositoryStore = > FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); > NodeStore nodeStore = > SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); > Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new > SecurityProviderImpl()); > Repository repository = jcr.createRepository(); > Session session = repository.login(new SimpleCredentials("admin", > "admin".toCharArray())); > UserManager userManager = ((SessionImpl) session).getUserManager(); > User userA = userManager.createUser("userA", "userA", new > UserPrincipal("userA"), null); > session.save(); > Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), > "myfolder"); > folder.addMixin(JcrConstants.MIX_SHAREABLE); > Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); > otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); > session.save(); > String path = otherFolder.getPath(); > AccessControlUtils.addAccessControlEntry(session, > otherFolder.getPath(), userA.getPrincipal(), new > String[]{Privilege.JCR_READ}, true); > session.save(); > session.logout(); > session = repository.login(new SimpleCredentials("userA", > "userA".toCharArray())); > Node node = session.getNode(path); > node.remove(); > boolean exist = session.itemExists(path); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4632) User with with just JCR_READ privilege can delete a node
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Description: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. If i give to _userA_ the privilege to remove the node nothing changes. Is this the expected behaviour? How can i give to _userA_ the privilege to completely remove the node (remove it also for _admin_)? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} was: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} > User with with just JCR_READ privilege can delete a node > > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder
[jira] [Updated] (OAK-4632) User with with just JCR_READ privilege can delete a node
[ https://issues.apache.org/jira/browse/OAK-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4632: - Description: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. _admin_ however can still view the node. {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} was: I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. Am I doing something wrong? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} > User with with just JCR_READ privilege can delete a node > > > Key: OAK-4632 > URL: https://issues.apache.org/jira/browse/OAK-4632 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.5 >Reporter: Marco Piovesana > > I have tow users: _admin_ and _userA_. > _admin_ creates a folder and gives JCR_READ privilege to _userA_. When > _userA_ tries to delete the folder no exception is thrown and the folder is > deleted. _admin_ however can still view the node. > {code:title=DeleteTest.java|borderSt
[jira] [Created] (OAK-4632) User with with just JCR_READ privilege can delete a node
Marco Piovesana created OAK-4632: Summary: User with with just JCR_READ privilege can delete a node Key: OAK-4632 URL: https://issues.apache.org/jira/browse/OAK-4632 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.4.5 Reporter: Marco Piovesana I have tow users: _admin_ and _userA_. _admin_ creates a folder and gives JCR_READ privilege to _userA_. When _userA_ tries to delete the folder no exception is thrown and the folder is deleted. Am I doing something wrong? {code:title=DeleteTest.java|borderStyle=solid} public void deleteWithoutPermission() throws IOException, RepositoryException { File driveFile = new File("/tmp/oakTest", "oakrepo"); File repositoryFile = new File(driveFile, "repository"); File dataStoreFile = new File(driveFile, "datastore"); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); Session session = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) session).getUserManager(); User userA = userManager.createUser("userA", "userA", new UserPrincipal("userA"), null); session.save(); Node folder = JcrUtils.getOrAddFolder(session.getRootNode(), "myfolder"); folder.addMixin(JcrConstants.MIX_SHAREABLE); Node otherFolder = JcrUtils.getOrAddFolder(folder, "otherFolder"); otherFolder.addMixin(JcrConstants.MIX_SHAREABLE); session.save(); String path = otherFolder.getPath(); AccessControlUtils.addAccessControlEntry(session, otherFolder.getPath(), userA.getPrincipal(), new String[]{Privilege.JCR_READ}, true); session.save(); session.logout(); session = repository.login(new SimpleCredentials("userA", "userA".toCharArray())); Node node = session.getNode(path); node.remove(); boolean exist = session.itemExists(path); } {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4530) Session modification discarded when repository closed too soon
[ https://issues.apache.org/jira/browse/OAK-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361471#comment-15361471 ] Marco Piovesana commented on OAK-4530: -- I was writing the test and i found what the problem was. I was using a FileStore without closing it before shutting down the repository. Here how i was creating the repository: {code:borderStyle=solid} FileStore repositoryStore = null; File rootPath = new File("/tmp/testoak"); File driveFile = new File(rootPath, DRIVE); File repositoryFile = new File(driveFile, REPOSITORY); File dataStoreFile = new File(driveFile, DATASTORE); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); repositoryStore.flush(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); {code} And what I was missing (i believe) was _repositoryStore.close()_ before _((JackrabbitRepository) repository).shutdown()_. No error message was thrown during the shutdown so i did not see it before. thanks, Marco. > Session modification discarded when repository closed too soon > -- > > Key: OAK-4530 > URL: https://issues.apache.org/jira/browse/OAK-4530 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.4.4 >Reporter: Marco Piovesana > > If I close the repository right after creating a new group (and saving the > session) the modification is not persisted. > {code: borderStyle=solid} > UserManager userManager = ((SessionImpl)adminSession).getUserManager(); > Group group = userManager.createGroup("myGroup"); > adminSession.save(); > adminSession.logout(); > ((JackrabbitRepository) repository).shutdown(); > {code} > When i restart the repository the group "myGroup" does not exist but no error > is logged anywhere. However, if i put a _Thread.sleep(3000l)_ before shutting > down the repository, the group is persisted. > Am I doing something wrong? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4530) Session modification discarded when repository closed too soon
Marco Piovesana created OAK-4530: Summary: Session modification discarded when repository closed too soon Key: OAK-4530 URL: https://issues.apache.org/jira/browse/OAK-4530 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.4.4 Reporter: Marco Piovesana If I close the repository right after creating a new group (and saving the session) the modification is not persisted. {code: borderStyle=solid} UserManager userManager = ((SessionImpl)adminSession).getUserManager(); Group group = userManager.createGroup("myGroup"); adminSession.save(); adminSession.logout(); ((JackrabbitRepository) repository).shutdown(); {code} When i restart the repository the group "myGroup" does not exist but no error is logged anywhere. However, if i put a _Thread.sleep(3000l)_ before shutting down the repository, the group is persisted. Am I doing something wrong? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4098) Implementation of clone function for shareable nodes
[ https://issues.apache.org/jira/browse/OAK-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360947#comment-15360947 ] Marco Piovesana commented on OAK-4098: -- Any news about the implementation of this functionality? Will it be supported again? Marco. > Implementation of clone function for shareable nodes > > > Key: OAK-4098 > URL: https://issues.apache.org/jira/browse/OAK-4098 > Project: Jackrabbit Oak > Issue Type: Wish > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > is there any plan to support the _shareable node_ feature of JCR? > I'm working on a multiple users repository and this feature fits well the > idea of sharing the same node in different areas of the file system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4422) support cluster for FileBlobStore
[ https://issues.apache.org/jira/browse/OAK-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320593#comment-15320593 ] Marco Piovesana commented on OAK-4422: -- I'll keep that in mind, thanks for your help. Marco. > support cluster for FileBlobStore > - > > Key: OAK-4422 > URL: https://issues.apache.org/jira/browse/OAK-4422 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.4.3 >Reporter: Marco Piovesana > > I'm using Oak in a system where the user can store arbitrary large binary > files and because of that I thought the best option was to use the > FileBlobStore as storage subsystem. > Now I need to port this solution on a cluster environment, but i saw that > clustering is supported only for Mongo and RDBMS storage systems. Is there > any plan to suppor it also for the Blob storage? There's a better option? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4422) support cluster for FileBlobStore
[ https://issues.apache.org/jira/browse/OAK-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318209#comment-15318209 ] Marco Piovesana commented on OAK-4422: -- thanks Davide, yes this helps. I'm quite new to Oak and I was still a bit confused between Datastore and Nodestore. I do have one more question though: how do i specify the dedicated FileBlobStore vs the shared Datastore? I read the oak guide and i tried to find an example on internet but i did not find anything. thanks, Marco. > support cluster for FileBlobStore > - > > Key: OAK-4422 > URL: https://issues.apache.org/jira/browse/OAK-4422 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.4.3 >Reporter: Marco Piovesana > > I'm using Oak in a system where the user can store arbitrary large binary > files and because of that I thought the best option was to use the > FileBlobStore as storage subsystem. > Now I need to port this solution on a cluster environment, but i saw that > clustering is supported only for Mongo and RDBMS storage systems. Is there > any plan to suppor it also for the Blob storage? There's a better option? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4422) support cluster for FileBlobStore
[ https://issues.apache.org/jira/browse/OAK-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316310#comment-15316310 ] Marco Piovesana commented on OAK-4422: -- Yes we use TAR. We have a websphere cluster with a file system shared between all the nodes. In this file system there is the oak node store. This is how we instantiate the repository: {code:title=RepositoryCreation|borderStyle=solid} BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); FileStore repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new SecurityProviderImpl()); Repository repository = jcr.createRepository(); {code} > support cluster for FileBlobStore > - > > Key: OAK-4422 > URL: https://issues.apache.org/jira/browse/OAK-4422 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Affects Versions: 1.4.3 >Reporter: Marco Piovesana > > I'm using Oak in a system where the user can store arbitrary large binary > files and because of that I thought the best option was to use the > FileBlobStore as storage subsystem. > Now I need to port this solution on a cluster environment, but i saw that > clustering is supported only for Mongo and RDBMS storage systems. Is there > any plan to suppor it also for the Blob storage? There's a better option? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4422) support cluster for FileBlobStore
Marco Piovesana created OAK-4422: Summary: support cluster for FileBlobStore Key: OAK-4422 URL: https://issues.apache.org/jira/browse/OAK-4422 Project: Jackrabbit Oak Issue Type: Improvement Components: blob Affects Versions: 1.4.3 Reporter: Marco Piovesana I'm using Oak in a system where the user can store arbitrary large binary files and because of that I thought the best option was to use the FileBlobStore as storage subsystem. Now I need to port this solution on a cluster environment, but i saw that clustering is supported only for Mongo and RDBMS storage systems. Is there any plan to suppor it also for the Blob storage? There's a better option? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4098) Implementation of clone function for shareable nodes
Marco Piovesana created OAK-4098: Summary: Implementation of clone function for shareable nodes Key: OAK-4098 URL: https://issues.apache.org/jira/browse/OAK-4098 Project: Jackrabbit Oak Issue Type: Wish Components: jcr Affects Versions: 1.3.16 Reporter: Marco Piovesana is there any plan to support the _shareable node_ feature of JCR? I'm working on a multiple users repository and this feature fits well the idea of sharing the same node in different areas of the file system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana resolved OAK-4086. -- Resolution: Not A Problem > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > Attachments: OAK-4086.patch, OakUsage.zip > > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177932#comment-15177932 ] Marco Piovesana commented on OAK-4086: -- You're right, the problem is generated by my custom login module. I'm sorry you had to spend time on this and thanks for the help. Marco. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > Attachments: OAK-4086.patch, OakUsage.zip > > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4086: - Attachment: OakUsage.zip Attached is a maven project that reproduces the problem. It contains the custom authentication module I'm using. Marco. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > Attachments: OAK-4086.patch, OakUsage.zip > > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177794#comment-15177794 ] Marco Piovesana edited comment on OAK-4086 at 3/3/16 1:23 PM: -- here is the complete code: {code:java} File rootPath = "/tmp"; File driveFile = new File(rootPath, DRIVE); File repositoryFile = new File(driveFile, REPOSITORY); File dataStoreFile = new File(driveFile, DATASTORE); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); Repository repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new CustomSecurityProviderImpl()); repository = jcr.createRepository(); Session sessionAdmin = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) sessionAdmin).getUserManager(); Node testfolder = sessionAdmin.getRootNode().addNode("/testfolder"); sessionAdmin.save(); Group myTestGroup = userManager.createGroup("MyUsersGroup"); sessionAdmin.save(); User newUser = userManager.createUser("marco", "password", new UserPrincipal("marco"), null); myTestGroup.addMember(newUser); sessionAdmin.save(); boolean allow = AccessControlUtils.allow(testfolder, myTestGroup.getPrincipal().getName(), new String[]{Privilege.JCR_READ}); sessionAdmin.save(); sessionAdmin.logout(); Session userSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = userSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} i did save the changes before logging in as "marco". I'm Sorry that I didn't mention it before. Marco. was (Author: iosonomarco): here is the complete code: {code:java} Session sessionAdmin = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) sessionAdmin).getUserManager(); Node testfolder = sessionAdmin.getRootNode().addNode("/testfolder"); sessionAdmin.save(); Group myTestGroup = userManager.createGroup("MyUsersGroup"); sessionAdmin.save(); User newUser = userManager.createUser("marco", "password", new UserPrincipal("marco"), null); myTestGroup.addMember(newUser); sessionAdmin.save(); boolean allow = AccessControlUtils.allow(testfolder, myTestGroup.getPrincipal().getName(), new String[]{Privilege.JCR_READ}); sessionAdmin.save(); sessionAdmin.logout(); Session userSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = userSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} i did save the changes before logging in as "marco". I'm Sorry that I didn't mention it before. Marco. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177794#comment-15177794 ] Marco Piovesana edited comment on OAK-4086 at 3/3/16 1:23 PM: -- here is the complete code: {code:java} File rootPath = new File("/tmp"); File driveFile = new File(rootPath, DRIVE); File repositoryFile = new File(driveFile, REPOSITORY); File dataStoreFile = new File(driveFile, DATASTORE); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); Repository repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new CustomSecurityProviderImpl()); repository = jcr.createRepository(); Session sessionAdmin = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) sessionAdmin).getUserManager(); Node testfolder = sessionAdmin.getRootNode().addNode("/testfolder"); sessionAdmin.save(); Group myTestGroup = userManager.createGroup("MyUsersGroup"); sessionAdmin.save(); User newUser = userManager.createUser("marco", "password", new UserPrincipal("marco"), null); myTestGroup.addMember(newUser); sessionAdmin.save(); boolean allow = AccessControlUtils.allow(testfolder, myTestGroup.getPrincipal().getName(), new String[]{Privilege.JCR_READ}); sessionAdmin.save(); sessionAdmin.logout(); Session userSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = userSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} i did save the changes before logging in as "marco". I'm Sorry that I didn't mention it before. Marco. was (Author: iosonomarco): here is the complete code: {code:java} File rootPath = "/tmp"; File driveFile = new File(rootPath, DRIVE); File repositoryFile = new File(driveFile, REPOSITORY); File dataStoreFile = new File(driveFile, DATASTORE); BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath()); Repository repositoryStore = FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create(); NodeStore nodeStore = SegmentNodeStore.newSegmentNodeStore(repositoryStore).create(); Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new CustomSecurityProviderImpl()); repository = jcr.createRepository(); Session sessionAdmin = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) sessionAdmin).getUserManager(); Node testfolder = sessionAdmin.getRootNode().addNode("/testfolder"); sessionAdmin.save(); Group myTestGroup = userManager.createGroup("MyUsersGroup"); sessionAdmin.save(); User newUser = userManager.createUser("marco", "password", new UserPrincipal("marco"), null); myTestGroup.addMember(newUser); sessionAdmin.save(); boolean allow = AccessControlUtils.allow(testfolder, myTestGroup.getPrincipal().getName(), new String[]{Privilege.JCR_READ}); sessionAdmin.save(); sessionAdmin.logout(); Session userSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = userSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} i did save the changes before logging in as "marco". I'm Sorry that I didn't mention it before. Marco. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177799#comment-15177799 ] Marco Piovesana commented on OAK-4086: -- I tried the exact same code with jackrabbit 2.12.1 and TransientRepository and it does work correctly. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177794#comment-15177794 ] Marco Piovesana commented on OAK-4086: -- here is the complete code: {code:java} Session sessionAdmin = repository.login(new SimpleCredentials("admin", "admin".toCharArray())); UserManager userManager = ((SessionImpl) sessionAdmin).getUserManager(); Node testfolder = sessionAdmin.getRootNode().addNode("/testfolder"); sessionAdmin.save(); Group myTestGroup = userManager.createGroup("MyUsersGroup"); sessionAdmin.save(); User newUser = userManager.createUser("marco", "password", new UserPrincipal("marco"), null); myTestGroup.addMember(newUser); sessionAdmin.save(); boolean allow = AccessControlUtils.allow(testfolder, myTestGroup.getPrincipal().getName(), new String[]{Privilege.JCR_READ}); sessionAdmin.save(); sessionAdmin.logout(); Session userSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = userSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} i did save the changes before logging in as "marco". I'm Sorry that I didn't mention it before. Marco. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4086) Group membership not verified during permission verification
[ https://issues.apache.org/jira/browse/OAK-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Piovesana updated OAK-4086: - Description: I have a group called "MyUsers" containing a user called "marco". I've created a folder called "testfolder" with admin account and i granted read permission to the "MyUsers" group: {code:java} Node testfolder = adminSession.getNode("/testfolder"); boolean allow = AccessControlUtils.allow(testfolder, myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); {code} When I login as "marco", if i try to find that folder i get an error saying that the folder doesn't exists (user does not have tthe permission to read it). It works only if I grant the READ permission directly to the user. {code:java} Session usrSession = repository.login(new SimpleCredentials("marco", "password".toCharArray())); Node node = usrSession.getNode("/testfolder"); //here the code fails because the node is not found!! {code} was: I have a group called "MyUsers" containing a user called "marco". I've created a folder called "testfolder" with admin account and i granted read permission to the "MyUsers" group: {code:java} Node testfolder = adminSession.getNode("/testfolder"); boolean allow = AccessControlUtils.allow(testfolder, myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); {code} When I login as "marco", if i try to find that folder i get an error saying that the folder doesn't exists (user does not have tthe permission to read it). It works only if I grant the READ permission directly to the user. > Group membership not verified during permission verification > > > Key: OAK-4086 > URL: https://issues.apache.org/jira/browse/OAK-4086 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > I have a group called "MyUsers" containing a user called "marco". I've > created a folder called "testfolder" with admin account and i granted read > permission to the "MyUsers" group: > {code:java} > Node testfolder = adminSession.getNode("/testfolder"); > boolean allow = AccessControlUtils.allow(testfolder, > myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); > {code} > When I login as "marco", if i try to find that folder i get an error saying > that the folder doesn't exists (user does not have tthe permission to read > it). It works only if I grant the READ permission directly to the user. > {code:java} > Session usrSession = repository.login(new SimpleCredentials("marco", > "password".toCharArray())); > Node node = usrSession.getNode("/testfolder"); //here the code fails because > the node is not found!! > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4086) Group membership not verified during permission verification
Marco Piovesana created OAK-4086: Summary: Group membership not verified during permission verification Key: OAK-4086 URL: https://issues.apache.org/jira/browse/OAK-4086 Project: Jackrabbit Oak Issue Type: Bug Components: security Affects Versions: 1.3.16 Reporter: Marco Piovesana I have a group called "MyUsers" containing a user called "marco". I've created a folder called "testfolder" with admin account and i granted read permission to the "MyUsers" group: {code:java} Node testfolder = adminSession.getNode("/testfolder"); boolean allow = AccessControlUtils.allow(testfolder, myUsersGroup.getPrincipal(), new String[]{Privilege.JCR_READ}); {code} When I login as "marco", if i try to find that folder i get an error saying that the folder doesn't exists (user does not have tthe permission to read it). It works only if I grant the READ permission directly to the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)