Author Topic: Groups and Parent Groups  (Read 1241 times)

0 Members and 1 Guest are viewing this topic.

mscherst

  • Full Member
  • ***
  • Posts: 6
Groups and Parent Groups
« on: July 02, 2019, 04:03:17 PM »
I'm trying to apply Mibew to our particular case, and I'm just looking for some confirmation that I'm understanding everything correctly, and maybe some advice on how to proceed.

We answer chats for multiple clients.  Those clients are grouped into queues based on common skills required by the operators.  So, eg, one queue might be for Dentists and another for Lawyers.  Operators trained on dental procedures would be assigned to that queue and then handle chats for all different Dentists.

At first glance it looks like groups and parent groups would work for this, but I think it's not really set up that way.  I could set up a group called "Dentists," and then create multiple groups named "Dr. A", "Dr. B", etc, with "Dentists" listed as the parent groups.  However, assigning an operator to "Dentists" will not assign them to the child groups.  Additionally, it looks like the main purpose of parent groups is to assign one company name, logo, etc.  This isn't necessary for our purposes, because from the perspective of the visitor they are completely unrelated.

So I'm wondering what the best way to move forward is.  I can imagine a plugin that does the following tasks:
  • On creation of a new group, find all operators assigned to the parent group and assign them to the new child group
  • On assignment of an operator to a parent group, find all child groups and assign operator to those as well

Does this look like a reasonable solution?  Are there pitfalls you would expect from this?

On the other hand, if it would be troublesome to re-purpose the groups feature for this, a similar feature could be added called "queues" that would leave the groups functionality intact as it is.  I think this would involve at least the following:
  • Add Queues page to administrative console
  • Allow queue assignment to group edit page
  • Allow agent assignment to queues
  • Allow reporting by queue

I'm sure there are more things I would think of.  If it doesn't cause issues, I think re-purposing parent groups would be the ideal solution, but I look forward to hearing any feedback.

Thanks


faf

  • Mibew Staff Member
  • Native
  • *****
  • Posts: 858
    • Mibew Messenger
Re: Groups and Parent Groups
« Reply #1 on: July 02, 2019, 07:38:19 PM »
Maybe I don't get the whole picture, but as far as I can see, you can use "Groups" for your typical use case as is, without any special plugins and/or tweaks. Of course, unless you've enabled the 'Group isolation' option.

An operator doesn't have to be a member of any particular group to transfer the chat to that group. Moreover, you don't need that group to be a child of the group you've generated a button for.

mscherst

  • Full Member
  • ***
  • Posts: 6
Re: Groups and Parent Groups
« Reply #2 on: July 03, 2019, 07:26:09 PM »
Thanks for the reply.  I'm playing around with it in the demo at demo2.mibew.org, if you want to check out what I mean there.

The button code would be generated only for the child groups, and we would never be making a button for the parent groups.  I see that an operator can see visitors listed at /operator/users for any group, and can invite them into a chat, and that an operator handling a chat can transfer it to any other agent or group.

The behavior I'm looking for is the alert that comes up when a user starts a chat in one of the operators groups.  This only happens when the operator is assigned to that group, so I'm just looking for a way to make that happen when an operator has been assigned to a parent of that group.

faf

  • Mibew Staff Member
  • Native
  • *****
  • Posts: 858
    • Mibew Messenger
Re: Groups and Parent Groups
« Reply #3 on: July 03, 2019, 07:58:32 PM »
Don't you want to separate visitors after initial chat with the first line support? And if you do, what's the point of using the whole concept of parent and child groups for that use case? And what's the point of generating different buttons for child groups if you want appropriate chats to be initially handled by operators from the parent group?  :o

One can make a group for operators of the first line support and generate the button for that group. Then one can also make several separated groups for the second line support. Visitors initially will chat with the first line (and operators in the appropriate group will be notified), and then will be manually transfered to one of the second line groups. Either it's what you're looking for, or I'm still don't understand your goal.