Sessions are by default (SysConfig Framework->Core::Session) 57600 seconds/16 hours while actually in use and 21600 seconds/6 hours when idle. BI> I haven't yet investigated what happens if an account is disabled and the customer responds to an issue via email. The ticket gets created. It gets created as if it's a random user, but not connected to the account that you've disabled (unless perhaps the CustomerID is email address...
There's a hack to PostMaster/NewTicket.pm to fix this. http://forums.otterhub.org/viewtopic.php?f=60&t=6586 talks about where to hack such things in PostMaster/NewTicket.pm, but it's prevention of unsolicited email tickets, not rejection of disabled users, but concepts should similarly apply. (specifically, if you put an "x" in front of the user's email address, for instance, the sender's email no longer exists in the database, so further email tickets from the user are unsolicited.) If you further hack this to test if removing the x matches the email address, you can use that as a flag to send an email to the sender (see the subsequent post by MichaelR in that thread). The above can effectively handle the email part of this. As for the user interface part, whatever "x" is in your case will be prepended to the email address. it could be "suspended-em...@address.tld". This would be very obvious. Of course, if the information is in LDAP, you would need to modify this at the LDAP side. This handles Agent knowledge. What's left? Notification to customers via web interface and set read-only. You've a basic handling of this. I don't know if you've done this, but you may simplify by having a positive membership CREATE TICKETS group and READ TICKETS group and add all customers to both. Then procedure to click the checkbox for CREATE TICKETS membership when removing the SUSPENDED- part of the email address. To provide the notification: Probably a bit more hacking, but this is because it's a special case for your business. I may have some other thoughts on this if I have time. One in particular is to invoke the Error Message of the Login. Another would be to use a version of the CustomerAccept module rewritten for specific CustomerGroup membership. This would be a copy of CustomerAccept, implemented via Framework->Frontend::Customer with the CustomerAccept InfoKey and InfoFile set up. The *copy/mod* of CustomerAccept.pm would survive updates.The result would be a popup the user has to accept and you'd have "proof" of acknowledgement. On Thu, Oct 11, 2012 at 6:53 AM, Bogdan Iosif <bogdan.io...@gmail.com>wrote: > 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 >
--------------------------------------------------------------------- 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
