Non-trivial rights scheme stopped to work after upgrade 3.1.9->3.5.7

[onetimecontributor]

Please advise how to understand why the following rights scheme stopped to work after upgrade 3.1.9->3.5.7 and how to fix/re-do it.

I've took a look at the changelog but couldn't spot the related change.

The setup is basically a cloud-less serverless contacts and calendars sharing among small group of Android users. Contrary to radicale's wiki for shared contacts and calendars, it doesn't require to do on-device soft-linking, as sharing settings are setup via rights file and enforced by one-way sync in Syncthing. That I believe is a simpler way that, unfortunately, had stopped to work.

It's setup in a way that admins have rw access to all users and common collections, restricted users have access rw only to it's own collections and read-only to common collections, there is also a pseudo-user that represents common collections.

Environment: radicale v3 (3.5.7) running via Termux on individual's smartphones accompanied by DAVx5 android app.
Users: a (admin), b (co-admin), c (restricted) and pseudo-user d (used for common contacts, events, etc). For the sake of example, number of users is reduced to 3 (+1 pseudo).
Each user has standardized username (adav, bdav) and individual pwd (user A doesn't host "users" file of user B etc)
Cal/Card data: Collection folder structure is rather standard "collection-root/[abcd]dav/[abcd]calendarfolder", typically its acalpriv, acalshared, acardpriv, acardshared etc. Example is after the description.
Syncthing is used to sync content of "collection-root" between individual's smartphones in a way that user doesn't (physically) have calendars or address books that he doesn't have read-only access to.

"Linked/shared folder" approach seemed to be less scalable comparing to a "perfect/imaginary" one, so I'm trying to handle access only via sophisticated rights file.

The problem: before the upgrade, if I login to web interface using bdav, I saw all the expected cal/cards from all collections (respecting read-only, etc), now it's only content of bdav itself. Files themselves (+cdav, +ddav) are still present on the disk.
I have attached logs that represent snippet of refreshing bdav collections via davx5.
debug2 (12).txt

On smartphones running 3.1.9 everything still works (though can't enable advanced logging re rights_rule_doesnt_match_on_debug...)

Please help me to understand if the below is supposed to work at all in 3.5.7+ and please help me to spot the error.
Turning debug on doesn't show that content/collections of cdav (cdav/ccardpriv, cdav/ccalpriv) is matched for bdav user (upon refresh in davx5), though I thought it should be matched by rules [calcar-adm-other] and [calcar-all] for example
Dumb guess - may it be because ddav doesn't have records for adav, bdav and cdav in it's "users" file? or is it something with the wrong order?

Folders structure of user a:

...
  └─[d] /radicale.data
    └─[d] /config
    └─[d] /collection-root
        ├─[d] /adav
        │ ├─[d] mycalendar1 (Collection)
        │ ├─[d] myaddressbook1 (Collection)
        ├─[d] /cdav
        │ ├─[d] mycalendar1 (Collection)
        │ ├─[d] myaddressbook1 (Collection)

Folders structure of user c:

...
  └─[d] /radicale.data
    └─[d] /config
    └─[d] /collection-root
        ├─[d] /cdav
        │ ├─[d] mycalendar1 (Collection)
        │ ├─[d] myaddressbook1 (Collection)

Rights file is as follows (identical for all users):

# Allow only reading principal collection (same as username) for C user
[root-restr-own]
user: [c]dav
collection: {user}
permissions: R

# Adm: RW for own collections
[root-adm-own]
user: [ab]dav
collection: {user}
permissions: RW

# Adm: RW of restricted collections
[root-adm-other]
user: adav
collection: [cd]dav
permissions: RW

# Allow reading root collection for authenticated users
[root-auth]
user: .+
collection:
permissions: R

# Adm: rw to c/d collections
[calcar-adm-other]
user: [ab]dav
collection: [cd]dav/[^/]+
permissions: rw

# Restr: r-o to special collections
[calcar-resrt-r]
user: [c]dav
collection: {user}/[c]calROrestricted
permissions: r

# Restr: rw only to private collections
#[calcar-resrt-rw]
#user: [c]dav
#collection: {user}/[^/]+
#permissions: rw

# Adm: rw to own collections
[calcar-own]
user: .+
collection: {user}/[^/]+
permissions: rw

# Auth: ro to all available collections (including non-owned)
[calcar-all]
user: .+
collection: .+?/[^/]+
permissions: r

INI is as follows:

[auth]
type = htpasswd
htpasswd_filename = users
htpasswd_encryption = md5

[rights]
type = from_file
file = config/rights

[server]
hosts = localhost:5232

[storage]
filesystem_folder = .
type=multifilesystem_nolock

debug2 (12).txt

[pbiering]

@onetimecontributor - can you somehow also document your file system layout in a minimal way like here https://github.com/Kozea/Radicale/wiki/Sharing-Collections

[onetimecontributor]

I've edited the description, added the structure

[onetimecontributor]

I have also attached logs that represent snippet of refreshing bdav collections via davx5.

[pbiering]

Interesting storage and usage scenario, unfortunatly I have no time to investigate. To trace this further on your side I would expect you have to enable trace mode in debugging and place some additional trace log statements into the code to narrow down, where the root cause is located that it will no longer work.

[onetimecontributor]

Understood, thank you. Meanwhile, will I be able to "downgrade" radicale by uninstalling 3.5.7 and re-installing 3.1.9? Will 3.1.9 re-build artifacts (database, files, if any) that aren't backward-compartible?

[pbiering]

only the cache file content changed meanwhile, but this should be automatically updated on next item read by Radicale.

[onetimecontributor]

Interesting storage and usage scenario

It's basically a cloud-less serverless contacts and calendars sharing among small group of Android users. Contrary to radicale's wiki for shared contacts and calendars, it doesn't require to do on-device soft-linking, as sharing settings are setup via rights file and enforced by one-way sync in Syncthing.

I had to set it up as I haven't found any file-based (vcf, ics) solution for Android that doesn't require Terminal/Termux.
There is 39aldo39/DecSyncCC#87, but it's not run on human-readable files