Map Users to Groups
Moderator: crythias
-
- Znuny newbie
- Posts: 4
- Joined: 05 Aug 2021, 15:34
- Znuny Version: 6.0
- Real Name: John Penrod
- Company: Transcend Networks, Inc
Map Users to Groups
In the same manner that you map agents to only see certain queues, I'd love to see the ability to map agents to see only certain customers.
We have instances where we have agents dedicated to a certain queue and they can still see other customers.
Any chance this is coming in the future?
Thanks!
We have instances where we have agents dedicated to a certain queue and they can still see other customers.
Any chance this is coming in the future?
Thanks!
-
- Znuny newbie
- Posts: 22
- Joined: 20 May 2021, 17:14
- Znuny Version: 6.4.2
- Real Name: Othmar Wigger
- Company: terreActive AG
- Location: Aarau, Switzerland
- Contact:
Re: Map Users to Groups
I guess we have the same problem. But let me first be clear about what exactly you need. My situation is
- 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, D.
- B, C, 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
@PenrodCC if this is also your requirement, we might be able to work out a solution.
- 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, D.
- B, C, 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
@PenrodCC if this is also your requirement, we might be able to work out a solution.
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Map Users to Groups
John,
What exactly do you mean by "see other customers"? Other customers' tickets or are they able to see the customer when selecting a customer user?
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
-
- Znuny newbie
- Posts: 4
- Joined: 05 Aug 2021, 15:34
- Znuny Version: 6.0
- Real Name: John Penrod
- Company: Transcend Networks, Inc
Re: Map Users to Groups
Mine is a bit simpler but the same in needs.
I am the owner of the ZNUNY deployment.
I have customers A,B,C & D.
I need to create an agent that works 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 four companies.
Just like we limit Agents to Groups to Queues, I'd like to limit customers to groups to users.
Maybe this already exists but does not seem to be so.
I am the owner of the ZNUNY deployment.
I have customers A,B,C & D.
I need to create an agent that works 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 four companies.
Just like we limit Agents to Groups to Queues, I'd like to limit customers to groups to users.
Maybe this already exists but does not seem to be so.
owi wrote: ↑29 Sep 2022, 09:49 I guess we have the same problem. But let me first be clear about what exactly you need. My situation is
- 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, D.
- B, C, 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
@PenrodCC if this is also your requirement, we might be able to work out a solution.
-
- Znuny newbie
- Posts: 4
- Joined: 05 Aug 2021, 15:34
- Znuny Version: 6.0
- Real Name: John Penrod
- Company: Transcend Networks, Inc
Re: Map Users to Groups
-
- Znuny newbie
- Posts: 22
- Joined: 20 May 2021, 17:14
- Znuny Version: 6.4.2
- Real Name: Othmar Wigger
- Company: terreActive AG
- Location: Aarau, Switzerland
- Contact:
Re: Map Users to Groups
Right. And the agent that works for A must not see customers B, C, D. I.e. ist must not see their tickets, nor the fact that they exist on your server. - That's the same requirement as mine. When I asked Shawn Beasley a few months ago, he answered: "That's not possible. OTRS is not meant to work this way."PenrodCC wrote: ↑30 Sep 2022, 17:44 Mine is a bit simpler but the same in needs.
I am the owner of the ZNUNY deployment.
I have customers A,B,C & D.
I need to create an agent that works 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 four companies.
Just like we limit Agents to Groups to Queues, I'd like to limit customers to groups to users.
Sad
![Sad :(](./images/smilies/icon_sad.gif)
However, I implemented it anyway
![Very Happy :D](./images/smilies/icon_biggrin.gif)
It's GPL code, so use it at your own risk. Additionally:
- this is work in progress
- it contains bugs
- it did not pass any OTRS coding style checks
- it has no unit tests
- it's only for the latest Znuny feature version
- it changes often
- it must be adapted to each new Znuny release
... but it works for me!
Enjoy!
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Map Users to Groups
John,
Znuny has an add-on for support customers which restricts the access to the different customer/customer user configurations per group/per role. The only limitation is that is only handles the 11 possible backends and not more.
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
-
- Znuny newbie
- Posts: 4
- Joined: 05 Aug 2021, 15:34
- Znuny Version: 6.0
- Real Name: John Penrod
- Company: Transcend Networks, Inc
Re: Map Users to Groups
Roy, what is the add-on called?
I don't see it listed: https://www.znuny.com/en/add-ons/price:support
JP
I don't see it listed: https://www.znuny.com/en/add-ons/price:support
JP
-
- Administrator
- Posts: 3968
- Joined: 18 Dec 2007, 12:23
- Znuny Version: Znuny and Znuny LTS
- Real Name: Roy Kaldung
- Company: Znuny
- Contact:
Re: Map Users to Groups
We haven't them all listedPenrodCC wrote: ↑30 Sep 2022, 19:12 Roy, what is the add-on called?
I don't see it listed: https://www.znuny.com/en/add-ons/price:support
![Wink ;-)](./images/smilies/icon_wink.gif)
- Roy
Znuny and Znuny LTS running on CentOS / RHEL / Debian / SLES / MySQL / PostgreSQL / Oracle / OpenLDAP / Active Directory / SSO
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
Use a test system - always.
Do you need professional services? Check out https://www.znuny.com/
Do you want to contribute or want to know where it goes ?
-
- Znuny newbie
- Posts: 22
- Joined: 20 May 2021, 17:14
- Znuny Version: 6.4.2
- Real Name: Othmar Wigger
- Company: terreActive AG
- Location: Aarau, Switzerland
- Contact:
Re: Map Users to Groups
@PensrodCC asked
Roy then suggested to use "a (Znuny) add-on for support customers which restricts the access to the different customer/customer user configurations per group/per role. The only limitation is that is only handles the 11 possible backends and not more".
Now it is not obvious what the problem has to do with backends. The OP clearly wanted to use a single Customer backend, probably DB, but subdivide these customers into groups of different visibility. Are you suggesting to write a different Backend for each visibility group (i.e. queue)? What a waste! And the number of groups would be limited to 11 anyway. This is a dead end.
I'd like to advertise again my MultiTenancy solution (https://github.com/terreActive/OTRS_MultiTenancy). I want to discuss why this was not built into OTRS from the start. In my opinion, it makes no sense that an agent can assign a customer user to a ticket of a queue he is not even allowed to see. The selection of possible customers and customer users should be filtered to those that make sense.
@root asked backWe have instances where we have agents dedicated to a certain queue and they can still see other customers.
Nobody answered this question, but from the further discussion it became clear that we mean "able to see the customer when selecting a customer user".What exactly do you mean by "see other customers"? Other customers' tickets or are they able to see the customer when selecting a customer user?
Roy then suggested to use "a (Znuny) add-on for support customers which restricts the access to the different customer/customer user configurations per group/per role. The only limitation is that is only handles the 11 possible backends and not more".
Now it is not obvious what the problem has to do with backends. The OP clearly wanted to use a single Customer backend, probably DB, but subdivide these customers into groups of different visibility. Are you suggesting to write a different Backend for each visibility group (i.e. queue)? What a waste! And the number of groups would be limited to 11 anyway. This is a dead end.
I'd like to advertise again my MultiTenancy solution (https://github.com/terreActive/OTRS_MultiTenancy). I want to discuss why this was not built into OTRS from the start. In my opinion, it makes no sense that an agent can assign a customer user to a ticket of a queue he is not even allowed to see. The selection of possible customers and customer users should be filtered to those that make sense.
-
- Moderator
- Posts: 393
- Joined: 30 Jan 2008, 02:26
- Znuny Version: All of them ^^
- Real Name: Hannes
- Company: Znuny|OTTERHUB
Re: Map Users to Groups
Hi Othmar,
One of the main reasons why this is not implemented is that companies often do not have this information available in one database.
If you have all your customers in one database, you need to "group them" , so a software is capable of hiding / showing them. This maybe your use case, but I would bet that the most of our users are not capable of providing those information.
And even if they would have, to restrict the customer list by user attribute, you need to fetch all customer users first. Not ideal.
Thats why the addon uses restrictions on backends. The basic idea that a backend which provides customer user information is assigned to a specific group / has a specific property. This is what Roys proposed addon includes. It blocks the access to the backends you are not allowed to see.
It is a Pre app module which is capable of filtering customer user results, based on the configuration.
The limit of 11 backends, which we usually exceed only in very rare cases, can be easily adjusted and will be dropped in future versions.
It's a relict from the past.
Maybe you can explain your solution a bit more in detail, starting with your use case and your solution. But I would like to see this in developer forum, not in a user thread in the support section. You can link to it, but those discussions miss the original post and lead to more confusion than the solution.
Regards
Johannes
The answer to your question is simple. It was not needed, so it is not implemented. No one can think of every possible use case. The basic implementation was made decades ago. It is as simple as that. Not saying that this could be added somewhere upstream, but this is the answer to your question.I want to discuss why this was not built into OTRS from the start.
One of the main reasons why this is not implemented is that companies often do not have this information available in one database.
If you have all your customers in one database, you need to "group them" , so a software is capable of hiding / showing them. This maybe your use case, but I would bet that the most of our users are not capable of providing those information.
And even if they would have, to restrict the customer list by user attribute, you need to fetch all customer users first. Not ideal.
Thats why the addon uses restrictions on backends. The basic idea that a backend which provides customer user information is assigned to a specific group / has a specific property. This is what Roys proposed addon includes. It blocks the access to the backends you are not allowed to see.
It is a Pre app module which is capable of filtering customer user results, based on the configuration.
The limit of 11 backends, which we usually exceed only in very rare cases, can be easily adjusted and will be dropped in future versions.
It's a relict from the past.
OK. I have one. A classic case for a "profit call center". They just create tickets and after the creation they are not able to see them again. Just hired agents which creates tickets (often on the phone) for other companies. Or a helpdesk which need to move tickets to other departments.... and I'm sure there are many more.The selection of possible customers and customer users should be filtered to those that make sense.
Maybe you can explain your solution a bit more in detail, starting with your use case and your solution. But I would like to see this in developer forum, not in a user thread in the support section. You can link to it, but those discussions miss the original post and lead to more confusion than the solution.
Regards
Johannes