for each replica acls method seems to return available permissions about python-irodsclient

[trel]

yes, i would think unique by data_id - has nothing to do with status.

[trel]

agreed - should be fine - but could be less efficient / heavyweight when there are lots of objects to investigate/report.

workaround for 2.1.0 fixes the bug.

[trel]

i think the set -> list thing is fine. we'll make it better later - let's just fix the bug now and make a new issue for optimization.

[trel]

Permissions are per object - not per replica - so on first glance, I agree this double listing looks like a bug.

[d-w-moore]

Indeed, seems like we perhaps need to make the ACLs query more "distinct", or hit the database for the replica with good status only, by default.

[korydraughn]

Seems the PRC should follow the same pattern as the filesystem library.

• https://github.com/irods/irods/blob/e4b4e8a7266360bb38ee97d7f2eda69249567dff/lib/filesystem/src/filesystem.cpp#L125-L182

Notice the fetching of ACLs for a collection is handled via a specific query on L158 - ShowCollAcls.

I'm pretty sure the filesystem logic was derived partly from the implementation of ils.

[trel]

the filesystem logic was derived partly from the implementation of ils.

i remember this as well.

[d-w-moore]

Seems the PRC should follow the same pattern as the filesystem library.

• https://github.com/irods/irods/blob/e4b4e8a7266360bb38ee97d7f2eda69249567dff/lib/filesystem/src/filesystem.cpp#L125-L182

Notice the fetching of ACLs for a collection is handled via a specific query on L158 - ShowCollAcls.

I'm pretty sure the filesystem logic was derived partly from the implementation of ils.

Agreed, both should use the same logic. Switching over to use of a specific query is an extensive change however, so maybe a milestone of v3.0.0 for that, and make a different issue for it ? I've got a workable solution here that should be fine for v2.1.0, for the meantime.

[d-w-moore]

agreed - should be fine - but could be less efficient / heavyweight when there are lots of objects to investigate/report.

workaround for 2.1.0 fixes the bug.

That's true. Another of many ways in which PRC (in current form) isn't optimal for efficiency. But at least the O(n) complexity is linear!

[d-w-moore]

agreed - should be fine - but could be less efficient / heavyweight when there are lots of objects to investigate/report.

workaround for 2.1.0 fixes the bug.

There's another approach that might work better for efficiency, and that's to order_by replica number and only process ACLs reported within the first set of rows, ie sharing the common replica number. Thoughts @trel @alanking @korydraughn ?

[korydraughn]

That sounds reasonable for now.

Switching over to use of a specific query is an extensive change however, so maybe a milestone of v3.0.0 for that, and make a different issue for it ?

What makes the switch an extensive change?
Is the retrieval of ACLs complicated?

[d-w-moore]

That sounds reasonable for now.

Switching over to use of a specific query is an extensive change however, so maybe a milestone of v3.0.0 for that, and make a different issue for it ?

What makes the switch an extensive change? Is the retrieval of ACLs complicated?

Just that so far the bulk of the machinery is GenQuery based. A lot of code would change, was my meaning. In principle, no , the retrieval of the string fields from the DB rows is all that's necessary under the hood.

[korydraughn]

Got it.