When the user system was designed and implemented, an internal IT support solution was in mind. It was a very simple role-based system with Users, Support, and Admins. Each role was stored into a single user bucket, with the roles only thing differentiating them. The initial implementation (4 years ago) all tickets were routed to a single IT support bucket. Any IT agent with the support role could create, edit, or delete tickets as they saw fit. As the project grew this model quickly caused more and more issues.
Its simple; the entire user and group system have to be redesigned and re-implemented.
The new design
Users will remain users. (end users linked to Customer Groups)
Support & Admin Roles will become Agents with their default permissions set respectivly.
Admins can have permissions set to be active Agents
Agents will group together through Teams
Teams will group together through Departments
Departments are assigned access to Customer Groups
This will pave the way for features such as automatically routing tickets to departments, customized ticket forms based on ticket types, and more granular control over users/agents.
With this change, comes a new customer portal. Deployments can have a front end area for users to submit, login or quickly check the status of an existing ticket. To maintain an SSO (single sign-on) implementation, users and agents will use the same login page with routing done accordingly.
How does this affect existing deployments
With these breaking changes comes a lot of database modifications for existing deployments.
The migration will convert any
users marked as
Admins to agents. Agents with
mod role get assigned the default role of
support agent and
admins the default role of
admin with the agent flag
Due to the number of changes required for the new system, implementation will happen in phases.
Any feedback or suggestions from the community is highly encouraged.