Hi, I'm also looking into solving the "customer's support contract is in trouble => reduce / cut his access to OTRS" problem, *without* changing code shipped with OTRS (no HTML mods, no PL script tweaks, etc.) and in a manner that can be automated (integrated with our contract management system)
= My conclusions so far = - Disabling a customer account is excessive as a 1st response to a problem with his support contract. It would result in him being unable to login and OTRS just saying "Login failed! Your user name or password was entered incorrectly." without an option to transmit additional info such as "... your account has been disabled because ...". There's another problem with disabling a customer account and that's OTRS leaving his existing sessions operational. Thus, the customer can still interact with OTRS for quite some time after his account was disabled if he had an active session before disabling occurred. It's non-obvious how session-killing-on-account-disable can happen because the provided "otrs.DeleteSessionIDs.pl" can't delete specific user session(s). It can either delete all active sessions or only those that have expired. I haven't yet investigated what happens if an account is disabled and the customer responds to an issue via email. That may yield other surprises. - Ideally, when a problem with his support contract occurs, the customer would have his access changed to a "read-only" mode until the problem is fixed. The only way I've found to do that is to change his permissions in "Customers <-> Groups" from "rw" to "ro". The trouble with this approach is that it requires manual intervention and remembering exactly for which groups you downgraded the rights (on some groups the customer may have permanent "ro" rights so when the support contract problem is fixed you need to know for which groups the access should be switched back to "rw" and for which groups it should be left to "ro"). - There is no mechanism provisioned in OTRS to show a message to certain customers in the customer interface. Something like "There is a problem with your support contract!!!". Ideally, something like this would manifest itself in about the same manner as messages for admins do when they show up in the admin interface announcing "do not use root account for operational work" or "scheduler is not running". - There is no way to add dynamic fields to anything except tickets and articles. So you can't easily mark a customer account as being "in trouble" unless you use some convention and write something in his "Comment" field, which would be a fragile solution, or if you use a different/additional customer backend which is way more complicated than what I'm confident to explore at this time. Even if you do mark a customer account as being "in trouble", OTRS doesn't make it in any way easier for you to reduce his access to the system. = Solution I'm playing with = 1. Create a queue that all customers can access, dedicated to handling customer support contract problems. 2. When such a problem occurs for customer X, automatically post a ticket in this queue and assign it to customer X (via OTRS web services, generic interface, etc.) and, in the OTRS database, "group_customer_user" table, set permission_value to 0 for customer X (by user_id) where permission_key is "rw", except for the group related to the queue from step 1. It is possible that an entry in this table doesn't exist for "ro" permissions (depending on how the "rw" permission was created from UI). If it doesn't exist, create it. OTRS doesn't set permission_value to 0, it just deletes the row. So by looking for 0 on that column when it comes to restore customer X's access rights, you'll know you'll find entries modified by this mechanism. 3. From now on, customer X has read-only access to all his previous tickets and he can only interact with the tickets related to support contract troubles. 4. When the support contract trouble is solved, update the table from step 2 by setting permission_value to 1 where it is 0 for the targeted customer. There are more issues to take under consideration (I haven't finished elaborating the whole solution) such as: - How will agents know, just by working normally, that a ticket belongs to a customer who's support contract is in trouble. A possible solution would be to add a dynamic field to tickets that is automatically updated at step 2 for all non-closed tickets. I hope I was clear and if you or anyone else has some feedback I would warmly welcome it. /bogdan On Thu, Oct 11, 2012 at 10:21 AM, Adrià García-Alzórriz < adria.garcia-alzor...@adam.es> wrote: > Hi there, > > I'm interested in adding more fields in Customer details. It can be > possible with OTRS? I think that Dynamic Fields are available only in > Tickets or Articles. > > I try to keep helpdesk offers support if a customer didn't pay his > previous bill, so a *visible* message (such pop-up, custom HTML) would > be great. > > Disabling customers or add text comments into customer's profile are > insufficient for us beacause in first case the agent can't find the > customer when opens a phone ticket; in the second one, if customer > creates a ticket via mail it can be difficult to notice these kind of > administrative messages. > > Do you have any ideas? > Many thanks! > > -- > Adrià García-Alzórriz <adria.garcia-alzor...@adam.es> > > --------------------------------------------------------------------- > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs