Collections and admin_channels/access api

Mobile Sync Gateway
1

I’m pretty sure I’m correct but just checking that channels are unique to collections so two collections if the user is assigned a channel of a given name say member_123 to each collection it will be treated as two separate channels which happen to have the same name.

e.g. access to mydb.myscope.collection1 and mydb.myscope.collection2

would require the /mydb/_user/:name to have PUT

...
"collection_access": {
    "myscope": {
      "collection1": {
        "admin_channels": [
          "!",
          "member_123"
        ]
      },
      "collection2": {
        "admin_channels": [
          "!",
          "member_123"
        ]
      }
}
...

E.g. You can’t cascade or wildard access either from the default collection or within a scope.

So if a new collection3 is added there is no default channels added ecxept “!” without explicitly setting them. Correct?

Not a big deal just interested.

2

Yes, your understanding is correct. Each channel name is specific to each collection. The sync function evaluates channels in the context of the collection the document is in to disambiguate.

There’s no convinience APIs/config to do cross-collection or inheritence-style grants right now.

3

Cheers. I thought so.

I will likely have a public record on the default collection, which will contain information of the app itself and that could trigger a call to my own update api to address schema updates, etc. Beats having to loop through each user.

I’m already using a proxy technique to make collection play well with PouchDB

I like the structure of using custom collection as opposed to using prefixed keys and this allows me to use a simple and consistent way to assigning channels to collection records. So this is not a big deal in comparison to one big sync function.