extend and improve the permission system

[Raynes]

Right now, all we can do with the permission system is declare users to be either admin or regular user. We need to expand this out and improve it so that we can have an extensible system capable of very specific permissions. This way we can have sets of permissions for users that plugins can add to and check for as well as two basic permissions:

• user: for regular users
• admin: for administrators who are trusted with the scariest commands.

The idea is that it would be possible to give certain non-admin users more dangerous and specialized permissions. For example, a plugin foo could check for its own special permission, like permission foo.

[alvaro-cuesta]

I'm willing to work on this issue if you don't mind. What's your idea about the implementation specifics? Something along these lines?

• Plugin authors can check for namespace-qualified permissions (e.g., ::permission, this will help with name clashes and be clearer in config files, IMHO.)
• In config :users, :perms is a set of permissions.
• Global permissions like :admin/:user could stay as :lazybot/admin and :lazybot/user if suitable.

What about allowing for finer-grained permission control over commands instead of preset permissions? This would be messier, although more powerful for users. Perhaps permission groups (like :admin right now) and assigning users to these groups could fix the mess and allow the fine-grain permission control. Allowing plugin-wide (instead of per-command) permissions could be cool too.

[Raynes]

The bullet points sound spot on, but I'm not following the finer-grained permission control proposal. Could you elaborate a bit more on what that would look like and how it would work?

Also, thanks for taking interest in this one. :)

[alvaro-cuesta]

You're welcome! I'm glad to contribute. In fact you should expect me getting involved in more issues sooner :P

---

After a bit of thought this idea for finer-grained permissions came to my mind. Plugin-set permissions could still rely on namespace-qualified keywords, but command-based finer-grained permissions can be set referencing the commands themselves. Mockup syntax:

;; These let bindings could be considered as permission groups, to avoid polluting users with lots of complex permissions
(let [voicer-perms #{'operator/voice 'operator/devoice}   ; Per-command permissions (note these are not keywords)
      admin-perms (into #{:lazybot/admin, ; Global permission
                          'operator},     ; Namespace/plugin-wide permission
                        voicer-perms)]    ; group composition
  {...
   :default-perms [:github/list-commits]  ; Perms for all users (including :user)
   :users {"Jen" {:pass "123", :perms admin-perms}
           "Jack" {:pass "456", :perms voicer-perms}}
   ...}

The ugly thing with command-permissions is, either:

• once a permission is set it MUST BE hooked and non-permission users are banned from the command (which is not very straightforward because, well, why setting a permission in a user would ban others from it?) Notice how admin needs permission to the whole operator just not to be banned from voice/devoice.
• or, they should be blacklists instead of permissions (as opposed to common permissions, which are really permissions.) I do really dislike this.

And there's a problem: commands ARE NOT fns, so some heavy magic with symbols might be involved.

This is the cleanest syntax I could come up with. This Gist features the first alternative that came off the top of my head, but it's rather complex and I'm not sure I like it. It's probably wise to stick with the simple plugin-set permissions, but I think that per-command permissions is a legitimate (although quite complex) use case (e.g. the operator-but-only-voice-group could be useful for some people.)