This comes out of a thread started in the General board. The initial request was
More precisely:
A similar scenario is:
- I am the owner of the Znuny deployment.
- I have customers A, B, C
- I need to create agents that work for company A so they can work tickets within their company.
- But, I only want them to see users within company A. As it stands now, they can click "Customers" --> "Customer User Info" and start typing a name and see customers in all customer companies.
- Just like we limit Agents to Groups to Queues, I'd like to limit customers to groups to users.
This "agent to customer mapping" or "multi tenancy" feature seems to be missing from both, stock OTRS and Znuny.
- The OTRS server is owned and managed by company A
- Customers are from companies x, y, z
- Some Agents are from company A
- Other Agents are from companies B, C, or D.
- B, C, and D are subcontractors of A, but they don't know each other.
- Each subcontractor B, C, D is in charge of a subset of Customers x, y, z.
- let B be in charge of x only, then B must not see y, and z
- by "must not see* we mean: must not be able to deduce a business relationship between y, z, and A
Consider the following solution:
Every time an Agent searches for Customers or Customer Users, it is checked whether the Agent and the Customer User share a common group. Customer users that have no common group with the Agent are hidden. Similarly, Customers that have no common group with the Agent are hidden.
There is a danger of "accidental matches" for groups that have nothing to do with agent-to-customer mapping. However, it turns out that in practice all groups are used either for agents only, or for customers only.
This modification can be applied centrally in
Code: Select all
Kernel/System/CustomerUser/DB.pm
Kernel/System/CustomerCompany/DB.pm
See https://github.com/terreActive/OTRS_MultiTenancy for the Znuny-6.4.3 version.
The required SQL query looks impressive. Instead of one simple "SELECT ... FROM customer_users WHERE Login LIKE ...", I wrote a query with 8 clauses and 7 joins. Testing with 180 customers and 900 customer users showed no noticeable slowdown on PostgreSQL nor MySQL.
Agent roles are respected. Secondary customer user to customer company assignments are respected.
Unfortunately, I had to add a new required parameter UserID to the functions Kernel::System::CustomerUser::CustomerSearch() and Kernel::System::CustomerCompany::CustomerCompanyList(). This accounts for one-line changes in 29 other modules, and I may have missed some.
I defined a configuration setting MultiTenancy that lets me switch off the feature and fall back to the default behavior.
CustomerGroupSupport must be enabled.
This is experimental code, and lacking in many respects. It works for me. I present it here for discussion:
- Is CustomerSearch() and CustomerCompanyList() the correct place to implement the change?
- Is my assumption correct that restricted agents are not capable of seeing foreign customers/customer users?
- Does the community wish such a feature?
- Is it susceptible to inclusion into the main Znuny code (disabled by default)?
- Do we also need an implementation for the LDAP backend?
- Othmar