[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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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()));
[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:
[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
[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
[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.
>
[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=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=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=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=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=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=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=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=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=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=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)
