Customer user search based on groups

[ivit]

Is it possible to have a search in customer portal, that will list all tickets belonging to Queues where customer has access. CustomerGroupSupport is enabled. I have configured queue to have access by several customers belonging to different customer companies.

Basically, I have queues which needs to be access by several companies, so CUSTOMER_ID is not the same, and listing all "Company tickets" can not help.
I have found solution in FAQ "How can a customer see tickets of multiple companies", however that does not solve my requirements.

Thanks.

[crythias]

At a certain point, I wonder if you might not just give the customer an Agent login with read-only access to their queues.

[ivit]

At this moment, I can see the proposed solution as the only one. However, I would like to avoid giving Agent login to any customer.

Thanks.

[crythias]

I should make note that "internal" notes will then be exposed, which may not be in your favor.

I point out that I've said before that customers should be generally oblivious to queues... Queues should be categories of tickets for groups of agents, not so much per customer or company. Reading this topic seems to indicate the reverse of this.
{rant on}
Queues should mean absolutely nothing specific to a company or customer, except for a type of request: sales/support/printing that is generic, or that is specific to a customer service rep (Agent) that deals with that company.
{end rant}

I didn't exactly understand your case for doing what you requested in the first place. Customers already see all the tickets in all the queues that THEY or Company (CustomerID?) submitted. Are you saying that there are companies that want to see tickets of other companies? or that customers are employees of multiple companies?

[ivit]

Scenario is little bit complex one, but I will try to explain:

We have 2 or 3 (or more) customers - "big companies":
Big1
Big2
...

There are a lot of "small companies", who are working as subcontractors of "Big companies":
Small1
Small2
Small3
Small4
...

There are many contracts between our company and "Big companies", and subcontractors "small companies" will work under mentioned contracts.

For each contract I will have Contract Queue and subqueue representing "Small company" tickets for that contact:

BIG1_contract
Small1
Small2

BIG2_contract
Small1
Small3
Small4

CustomerGroups support is enabled and I have created groups for each company. For each subqueue I have assigned the relevant company group.

Customer from BIG1 should be able to have ro access to:
BIG1_contract
Small1
Small2

Customer from BIG2 should be able to have ro access to:
BIG2_contract
Small1
Small3
Small4

However, with the following restrictions:
-BIG1 should not have access to BIG2_contract:Small1, and BIG2 should not have access to BIG1_contract:Small1
-Each small company should have access to all its tickets, e.g. Small1 customer should have access to both BIG1_contract:Small1 and BIG2_contract:Small1. This is feasible by using same CUSTOMER_ID and all tickets that have the same customer_id will be available as company tickets in whatever queue are located.

I hope that the scenario is little bit clarified.

Thanks

[crythias]

So you're saying BIG1 should have access to small1's, small2's tickets? but only for tickets that apply to small1, small2 working for BIG1? (and, therefore, the queues...)

Should this be a live access thing or would a periodic report be acceptable?

Yeah, I'm almost wondering why you have to deal with this, because my first thought on this (please understand, this is me rambling, and not that any of it makes sense...) is why isn't small1 and small2 (for instance) running their own instance of OTRS ...

Then again, what other filter would I use? I'd consider using a FreeText field that holds BIG1 ... this isn't unreasonable and a Generic Agent could probably do this. Then, I'd try to create a Kernel/System/Ticket/CustomerPermission/FreeText6Check.pm (arbitrary choice of FreeText#) or CustomerPermission/QueueCheck.pm (if you REALLY want to provide access based upon Queue.)

It's beyond the scope of my thought process to dump finished code here right now, but cursory checking says I'd copy say, GroupCheck.pm and modify it...
Original code

Code: Select all

package Kernel::System::Ticket::CustomerPermission::GroupCheck;


    # return access if customer is in group
    return 1 if $GroupIDs{$GroupID};

Change it to something... again, this is random from my head Psuedocode...
(if the Queue name contains the Group Name (like BIG1), then the ticket is ok...)

Code: Select all

package Kernel::System::Ticket::CustomerPermission::QueueCheck;

return 1 if ($Self->{QueueObject}->QueueLookup( Queue => $QueueID, ); =~ $GroupObject->GroupLookup(GroupID => $GroupID));

I can't really verify if what I'm saying is correct, or that it will work at all, but maybe someone else can point you on the right track. If there's no relevance between the Queue name and the Group name, then it won't work, obviously. But, since the group structure is all internal, those changes are/should be? easy enough to make. I may have made a perl coding mistake, and it may break Customer ticket lookup (bad customer experience) if the code isn't right, but I don't have your infrastructure to test it, even if it didn't break on my system.

[crythias]

It's interesting that http://lists.otrs.org/pipermail/dev/201 ... 02342.html seems to somewhat have the same type of goal...

[ivit]

Thanks for all the tips.

I will try to figure out how to change Search for customer portal to include all tickets based on group belonging, but to leave "Company tickets" list for only the tickets submitted by users with the same CustomerID.

Thank,
Igor

[ivit]

Here I am again... never worked with Perl, but I have tried some code changes.

I tried to do the following:
in \Kernel\Modules\CustomerTicketSearch.pm I have tried to change Run function in line 96. to exclude using CustomerID

Code: Select all

    # get search string params (get submitted params)
    else {
        for (
            qw(TicketNumber From To Cc Subject Body CustomerID ResultForm TimeSearchType StateType
..............
..............

However, nothing has changed.
My idea is to allow customer to search all Queues, if he/she has access. Not to limit his/her search on CustomerID.

Could someone tell me how otrs is performing customer search? Is there a way to change search behavior?

Thanks,
Igor

OTRS 2.4.7

[crythias]

After all this, someone else pointed to the docs that provided this with less hassle (I think?)... http://forums.otrs.org/viewtopic.php?f=61&t=5310 Spoke about http://doc.otrs.org/2.4/en/html/x1801.h ... r-ids-ldap or http://doc.otrs.org/2.4/en/html/x1801.h ... mer-ids-db

The short short:

• Create a customerids field in the customer database (or use a specific "free text" field designated for this purpose in LDAP)
• Add a Map entry into the CustomerAuth Section of Config.pm referencing this new field
• Add companies and customerIDs into the Customer Company Section
• populate the new customerids field in the Customer User section with the customerIDs that they have permissions for, separated by semicolons

[ivit]

Thanks crythias for the help. I have tested several scenarios, and I have evaluated yours (I did not implement it).

However, proposed solution is not fitting my needs, since one user who has companyIDs of many companies will be able to access to all companies tickets that he/she has companyID. And I want customer to be able to access only tickets that belong to specific projects (queues).
Apart from it, adding multiple companyIDs will be overkill for administration, since one customer (supervisor) user belongs to 30 companies.

Bottom line is the following:
Customer user can search his/her own tickets by clicking "MyTickets". This is OK!
Customer user can search his/her company tickets by clicking "CompanyTickets". And this is OK too!
Customer user can search all tickets by clicking on "Search" that belong to the queues that he/she has right to access. This has to be implemented/changed !

Could you please or someone else give some tips where to look for, for the search/permission function to be changed in order to allow customer to retrieve all ticket in search that he/she has access based on the queues?

I am not very familiar with Perl but I am sure this is feasible, since the customer has ability to see the queues when he/she wants to submit the new ticket. During the New ticket creation customer user has to select "To" value which represent queues that he/she has access to.

Thanks a lot for the help.

Regards,
Igor

SMALL UPDATE:
Each queue has its own group, and the customers are placed in appropriate group. Which means that I have to modify customer search to give all tickets based on group/queue membership.
Any hint is really appreciated.

[crythias]

But we keep coming back to the point that queues and queue permissions are agent side, not customer user side. There is no permission level assigned to a user for a queue. In fact, in general, all queues are available (though not always presented) to all users.

[ivit]

But we keep coming back to the point that queues and queue permissions are agent side, not customer user side. There is no permission level assigned to a user for a queue. In fact, in general, all queues are available (though not always presented) to all users.

Hmm... I am afraid that is not true, or I am wrong.

If we do the following:
- Enable customer groups support
- Link customer users to the group1
- Assign group1 to the queue1

Then customer user will be able to submit new tickets only to that queue (queue1). That queue will be the only available value in "To" dropdown in "New Ticket" form.

Am I missing something?

Thanks,
Igor

OTRS 2.4.7

[ivit]

OK. I think I have found appropriate solution.

Solution will be based on multiple company IDs and customer groups. Initial test shows that it will work in that way:
-Each supervisor will have multiple company IDs from child companies.
-Each Queue(project) will have specific group defined which will include supervisor + all child companies participating in that project.
-When supervisor does the search he will not see the tickets from child companies that belong to the queues (projects) that he/she does not have access, i.e. supervisor will only see the tickets from child companies that belong to queues (projects) that he/she has access.
-Child companies will be able to see all their company tickets that belong to them, i.e. to all queues (projects) they have access under different supervisors.

I will do the tests once again, to confirm everything is working as expected.

BTW, max field length is 150 characters (for customer IDs). How it can be expanded to accept more?

I did search in .dtl, but with no luck.

Thanks,
Igor

OTRS 2.4.7

[crythias]

I believe the limit may be from the field itself in the database (though I don't know what field you're using if you're not using the customerids like the docs say).

[ivit]

I believe the limit may be from the field itself in the database (though I don't know what field you're using if you're not using the customerids like the docs say).

In DB, the length is 250, like docs say. However, it seems that all form fields are having limitation in html maxlength="150" in AdminCustomerUserForm.dtl

Code: Select all

<!-- dtl:block:PreferencesGenericInput -->
                <tr>
                  <td width="40%" class="contentkey">
                    $Data{"TableFontStart"}$Text{"$Data{"Item"}"}:$Data{"TableFontStart"}
                    <font color="red" title="$Text{"This values are required."}">$Data{"Required"}</font>
                    <font color="blue" title="$Text{"This values are read only."}">$Data{"ReadOnly"}</font>
                  </td>
                  <td class="contentvalue">
                    <input type="text" name="$QData{"Name"}" value="$QData{"Value"}" size="35" maxlength="150" $QData{"ReadOnlyType"}/>
                  </td>
                </tr>
<!-- dtl:block:PreferencesGenericInput -->

However I don't know what impact changing that value would have on the rest of the fields, since majority of the fields are limited in DB to 150 characters.

Thanks,
Igor

OTRS 2.4.7

[crythias]

I don't know, either, but the worst that can happen (poor user interface, but...) is that anything input into the field longer than the database field size is likely to be clipped without ceremony/notification/error (I think this is by design of MySQL). Considering the type of field it is, this doesn't seem to be a big problem to change the size to 250 from 150.

http://dev.mysql.com/doc/refman/5.1/en/ ... -data.html

For strings, MySQL stores either the empty string or as much of the string as can be stored in the column.