BI> you imply the customer account needs to be disabled, I don't confirm this. Changing the email address is sufficient to block incoming mail with the NewTicket hack. I only wanted to expand on your inquiry "what happens if..." By default, random emails create tickets, even if the user is disabled.
Re: The second part ... basically group membership human carried operation, yes. I'm not certain there will be a "SysConfig" able operation for this. Modules can be created, of course, but OTRS by default only obeys what you tell it. The CustomerAccept module is a one-shot popup message module that requires all customers to read and acknowledge the popup message before continuing. The "all customers" bit is what I'd suggest modifying to check CustomerGroup membership (for instance, "Out of Service Contract") before sending. One-shot being a rather loose term. This is like the following: http://www.youtube.com/watch?v=NoJe_6rvVpY<http://www.youtube.com/watch?v=NoJe_6rvVpY&feature=plcp> but applied to Customers. The "error message" may be something that the login might throw if the email address begins with "SUSPENDED". It's a thought, anyway. On Thu, Oct 11, 2012 at 9:20 AM, Bogdan Iosif <bogdan.io...@gmail.com>wrote: > Hi, > > Thanks for the reply. I read through it a couple of times but, because of > out-of-my-league tech refs, my understanding is mediocre. > > Up until "The above can effectively handle the email part of this." I > think I understood well. I hate to admit - because it involves .pm code > changes - but I may need to look into it more. My understanding (please > confirm/infirm) is that you imply the customer account needs to be > disabled, which I do not want for reasons already explained in my initial > reply. However, your whole email filtering proposal may be what I need in > the end because I just tested what happens when I switch all Customer <-> > Groups permissions to read-only. The customer can't interact with tickets > from the customer interface but he can still fully interact with OTRS via > the email interface. New tickets get created and replies to older tickets > have their answers added as new articles. So my idea of making access > read-only is not really complete unless I can somehow block access via the > email interface. (I'm still thinking about integrating somehow the > customer-billing-problem event raised from the contract-management system > with commands sent to the email server to blacklist customer's email > address, just so that I would avoid changing any code in OTRS) > > The 2nd part of your reply I understood poorly. "Then procedure to click > the checkbox..." did you meant human carried operation here? What I'm after > is to integrate OTRS with a contract management system. When someone marks > in that system that there is a billing problem with the customer, in OTRS > the access suspension should occur automagically. Same thing when the > billing problem is solved. > > The last paragraph I haven't understood almost at all because I don't know > what CustomerAccept module is, but this remark "One in particular is to > invoke the Error Message of the Login" peaked my interest even though I > can't imagine how it's done. > > Thanks, > Bogdan > > > > On Thu, Oct 11, 2012 at 3:08 PM, Gerald Young <cryth...@gmail.com> wrote: > >> 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 >> > > > --------------------------------------------------------------------- > 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
