Setting Defacs to include D on {acc} is ignored

[ozobken]

Subject of the issue

I want to make it possible for P2P and group users to be able to hard delete messages in the conversation, the docs suggest that on new user creation, in the {acc} you can set a different 'defacs' to allow this. If I try and create a new users with 'defacs' of "JRWSPAD", it's created with "JRWPA"

Also, If I manually update the database to add the 'D' (to the users table, access column), when the P2P channel is subequently created, only one user gets 'D' permission, the other doesn't. Is this expected behaviour? How can we allow 'D' access to P2P for all participants?

(Good news is, after I hack the db, it seems to work as expected for groups - the 'D' gets passed to the group {sub} and if the group was created with 'D' allowed, then it's granted, but it's still not possible to set the defacs for the user with 'D' in the {acc} )

Is this a bug report of a feature request?

• [x] Bug report
• [ ] Feature request

Your environment

Server-side

• [ ] api.tinode.co
• [x] Your own setup:
  • platform: Linux/IOS
  • version of tinode server: v0.16.0-rc1
  • database backend: mysql 107

Client-side

• My IOS Client

Steps to reproduce

Make a new user with {acc} and acc.desc containing defacs.auth of "JRWSPAD"

Expected behaviour

Should set the defacs in the user to "JRWSPAD"

Actual behaviour

Sets the user's access to {"Auth":"JRWPA","Anon":"N"}

Server-side log

2019/06/25 12:24:46 grpc in: acc:<id:"12346" user_id:"new" scheme:"basic" secret:"***" login:true desc:<default_acs:<auth:"JRWSPAD" > > >  9JrMSrkwV3k

Client-side log

message <ClientMsg 0x6000018c8370>: {
    acc {
      id: "12346"
      user_id: "new"
      scheme: "basic"
      secret: "***"
      login: true
      desc {
        default_acs {
          auth: "JRWSPAD"
        }
      }
    }
}

<ServerCtrl 0x6000004e3b80>: {
    id: "12346"
    code: 200
    text: "ok"
    params {
      key: "expires"
      value: "\"2019-07-09T04:48:33.811Z\""
    }
    params {
      key: "authlvl"
      value: "\"auth\""
    }
    params {
      key: "desc"
      value: "{\"created\":\"2019-06-25T04:48:33.556Z\",\"updated\":\"2019-06-25T04:48:33.556Z\",\"defacs\":{\"auth\":\"JRWPA\",\"anon\":\"N\"}}"
    }
    params {
      key: "token"
      value: "\"VjIKKP9+f12hHCRdFAABAAEAEKqomgKtKE48XVzi2bBe6K7I1zmazEZmrjLn88YqTp8=\""
    }
    params {
      key: "user"
      value: "\"usrVjIKKP9-f10\""
    }
}

Even if I hack the database to allow 'D' for both users 'defacs' when the P2P is created, one user gets

message <ClientMsg 0x6000018ec0b0>: {
    sub {
      id: "12348"
      topic: "usr5Ekpuvo9hbI"
      set_query {
        sub {
          mode: "JRWPSD"
        }
      }
      get_query {
        what: "data"
        data {
        }
      }
    }
}

<ServerCtrl 0x6000004c1180>: {
    id: "12348"
    topic: "usr5Ekpuvo9hbI"
    code: 200
    text: "ok"
    params {
      key: "acs"
      value: "{\"want\":\"JRWPA\",\"given\":\"JRWPAD\",\"mode\":\"JRWPA\"}"
    }
}

the other side gets:

message <ClientMsg 0x600000f84160>: {
    sub {
      id: "12348"
      topic: "usrVjIKKP9-f10"
      set_query {
        sub {
          mode: "JRWPSD"
        }
      }
      get_query {
        what: "data"
        data {
          since_id: 3
        }
      }
    }
}

<ServerCtrl 0x6000013a4930>: {
    id: "12348"
    topic: "usrVjIKKP9-f10"
    code: 200
    text: "ok"
    params {
      key: "acs"
      value: "{\"want\":\"JRWPA\",\"given\":\"JRWPA\",\"mode\":\"JRWPA\"}"
    }
}

[or-else]

The D is hard-cleared for p2p topics. This feature has to be coded explicitly.

[ozobken]

Hmm - That's weird - why treat P2P conversations differently to groups? That seems like extra work for the backend. I guess I can work around this by making all conversations groups, but that's much harder to set up

[ozobken]

Independently, though - can D be added to the defacs for a new user, so that it's passed as the default to groups if chosen, since this mechanism already works?

[or-else]

Hmm - That's weird - why treat P2P conversations differently to groups?

Because there is no single owner there.

I guess I can work around this by making all conversations groups.

That probably won't work as expected because you would have to assign one user to be the owner. The other user won't be able to delete the messages.

The idea is to add an option for a user in p2p topics to delete own messages. That's going to take a bit of work through.

[or-else]

can D be added to the defacs for a new user

That's easy to do, but then the user with the D permission will be able to delete messages sent by either user.

[or-else]

The option for a user in p2p topics to delete own messages is not too hard, it's probably a couple of days of my time. I just need to find time.

[ozobken]

That would be cool - I'm integrating message expiry on my app, and I want the first endpoint that is doing the expiry to be able to delete the messages from the backend for a conversation. As an alternative, the backend could implement the expiry :), but that's a separate feature request.

[or-else]

Message expiration is on the road map. It's certainly a very useful feature.

[ozobken]

Just a quick followup - did expiry or these Defacs changes make it in?

[or-else]

No work was done on these features.