JCRVLT-522 check effect of filter rules on ACLs

[kwin]

No description provided.

[kwin]

I fail to reproduce installation of ACLs not contained in the filter. @anchela Can you come up with a test case?

[kwin]

@tripodsan In general filter rules seem to be followed except for one edge case. What is the idea of Importer.postFilter (

jackrabbit-filevault/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java

Line 518 in 61e920f

private TxInfo postFilter(TxInfo root) {

)? Is that supposed to filter out everything on an artifact level not contained in a filter and the DocViewSAXImporter only does the filtering on sub artifact level?

If so do you consider Importer.postFilter errorneous as it does not correctly filter out artifacts which are below a contained node (but excluded)?

[tripodsan]

@tripodsan In general filter rules seem to be followed except for one edge case. What is the idea of Importer.postFilter (

jackrabbit-filevault/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/Importer.java

Line 518 in 61e920f

private TxInfo postFilter(TxInfo root) {

)? Is that supposed to filter out everything on an artifact level not contained in a filter and the DocViewSAXImporter only does the filtering on sub artifact level?

I think it is used to find the TXInfo hierarchy that is covered by the filter.... maybe :-)

If so do you consider Importer.postFilter errorneous as it does not correctly filter out artifacts which are below a contained node (but excluded)?

I don't think this will lead to errors. AFAIR, this is only the preliminary scan. the nodes are filtered again when traversing. but I might be wrong. it was a long time ago, when this code was created :-)

[kwin]

Look at the test case: It leads to some ACLs being applied although outside the filter, because no subsequent filtering happens. Bug or Feature?

[tripodsan]

Look at the test case: It leads to some ACLs being applied although outside the filter, because no subsequent filtering happens. Bug or Feature?

I would say, if the effective ACL on one of the items included in the filter is affected, then the ACL should be applied.
i.e. in general, all ACLs not included in the filter but that are ancestors of the filtered items should be applied.

all ACLs that are not covered in the filter and do not affect the items in the covered tree should not be modified.

[kwin]

all ACLs not included in the filter but that are ancestors of the filtered items should be applied.

I can follow your argument, but this is not how it works right now. I would like to first clarify how to deal with row 2 in the description table of https://issues.apache.org/jira/browse/JCRVLT-522, before thinking about installing ACLs for more cases not contained in the filter.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[kwin]

@reschke Do we again need to introduce a flag for backwards-compatibility where ACLs are applied in some edge cases despite not being contained in the filter?

[kwin]

If there is no further concern I would go ahead and merge at the end of this week.