Group Permissions: Limit users to posting interally

[tyler-wright]

Hello Zammad Team,

You have an amazing product here - thanks for open sourcing it. It's been a pleasure to poke around in.

Overview of Proposed Feature

So far I've been evaluating it for a somewhat novel application, and I found a missing feature which is a blocker for me. Competing platforms like Zendesk and even open source competitors like osTicket have the ability to restrict users to only posting internally.

I wasn't able to find this feature in Zammad - the permissions system doesn't seem to dig in a very granular fashion into the functionality that's available. However, you have such a great system for distinguishing between internal/external correspondence. It's all there - so I figured it can't be too hard to build the feature.

The main problem I'm trying to solve is to give access to Agents that shouldn't be able to accidentally send external correspondence. Instead, the Agents are able to assist more senior Agents by creating drafts and internal comments on tickets, subject to group access. The senior Agents can then review and respond using their external access permissions.

I thought the implementation best into Group/Role access permissions, because it means that you can have some Agents with full access to some Groups, but only read or internal access on other Groups. So it adds more flexibility.

See below for a visual guide of what I've changed in this PR.

Role Permissions

There is a new item in the Role Permissions that allows you to select 'External' for a Group.

In this example, this role can post externally for tickets in the Users group but not the Random Group, where they are limited to internal.

Below you can see a Role can be created called 'Internal Agent' where you can configure what groups this Agent has access to. This allows you to setup a role where all access will be internal to every Group, perfect for what I'm after.

Then below you can see what a Limited User's access looks like in the Ticket Zoom overview. It disables the visual buttons to toggle tickets internal/externally, and by default any type of channel will be marked as internal correspondence.

What this PR doesn't address (yet)

1. Tests - I have not written any tests for this code, I could use some guidance on doing so. The testing section in your developer documentation is not terrible, but I haven't yet had time to setup the different front-end and back-end testing suites.
2. API Permissions - I am not sure if the external correspondence can be controlled via the API or whether this needs addressing
3. Use of 'Full' Permissions - I am not 100% certain whether changes in the creates_ticket_articles.rb will be sufficient to cover a case where a User or a Role has 'full' permissions, it might still prevent them from posting externally because authorise!(ticket, :external?) doesn't allow. I've run out of testing time.

Next Steps

It would be great if this feature was implemented. If it's not on the roadmap, I'd be interested in any advice on how to create it as a package/add-on. I haven't yet explored that because I wanted to see if there was genuine interest in merging it into the product.

Thanks for your time!

[dominikklein]

@tyler-wright Thank you very much for the idea, I think we would first need to talk internally if this is a feature that we see in the product, and when we think it's interesting we need to check how this feature could be implemented. Then it would be possible to check together, what needs to be aligned in this PR.
Currently, it's difficult to say how long this will take.

[tyler-wright]

@dominikklein No worries, let me know if I can assist in any way. I may run it in my production instance in the meantime and see how it works out. Currently Ive noticed that even if you set an email to be internal, it still ends to external recipients - so that's a bit counter-intuitive.