[SOLVED - sort of]Customer-Users with no email and workflow

[Linwood]

I've searched but it is a bit hard to find "no email" reliably, so apologies if this is well discussed elsewhere...

It would appear a basic design function of otrs is that all customer-users will have email. It is most importantly built in otherwise very helpful automation, such as email replies on ticket close, which agents will almost certainly come to rely upon (i.e. recommendations to "always communicate with the customer-user by phone or some other mechanism" will soon be ignored and they will reply on email.

For an I.T. organization it is reasonable to presume everyone has email (though of course the Dilbert situation of a ticket for "my email doesn't work" may still apply).

But I am setting up for an municipality where citizens are the customers, and it is very possible some just don't do email. And government can't very well require email to provide services.

I can easily set up a email "sink" for messages, tell people to put in a dummy email. But I KNOW that downstream, agents will thoughtfully type an external reply, and close tickets, and expect them all to be communicated. And in doing so drop the ball. Picture some aggressive reporter then with the story "98 year old lady told to buy a computer in order to get potholes fixed", over understandable confusion.

OK... maybe not that bad. But ... Are there documents that provide guidance in how to approach the "no email" scenario while allowing the system to be nicely automated otherwise?

What I really want is a few intercepts in the workflow, for example if one tries to do an external email reply to a non-address (or placeholder) the system stops the agent and says "you can't do that, contact them some other way". Numerous places this becomes important.

I'm new to OTRS but in a few intense periods of looking around it appears the presumption of email availability is pretty deeply buried in the normal activities.

Am I missing a feature somewhere perhaps? Or just not seeing an obvious approach?

[crythias]

No email, no sms, and ... what? How are you going to communicate? Phone? snail mail?

If phone, it's possible to use phonenumber+salt@mailinator.com for email address. (salt=random spurious letters).
Assuming the agents can eyeball the email address being mailinator.com, (or create a Dynamic Field/No Email address) it seems reasonable to handle the correspondence logging as New Phone ticket and Inbound/Outbound phone call attachments to mail.

[Linwood]

No email, no sms, and ... what? How are you going to communicate? Phone? snail mail?

This is for government, so they have to be prepared for anything -- the person might only do telephone, or snail mail. They might be handicapped and require some special communications. Governments don't have the ability to even appear to refuse services due to one's situation.

Now that said, they may use otrs for years before the subject actually comes up in practice. But it's being discussed as an issue prior to deployment.

If phone, it's possible to use phonenumber+salt@mailinator.com for email address. (salt=random spurious letters).
Assuming the agents can eyeball the email address being mailinator.com, (or create a Dynamic Field/No Email address) it seems reasonable to handle the correspondence logging as New Phone ticket and Inbound/Outbound phone call attachments to mail.

That sort of thing was my first suggestion but I'm getting push back that agents may not notice the email, may not pay attention enough if the system does not help.

From my tentative research it would appear to me that the system, other than showing the email address, does not react to it's (pseudo) lack -- there is no concept of an email-less ticket built into the logic of the system, so that the workflow would change automatically.

Is that correct?

It is quite possible they decide to live with that situation, depend on their agents. But before that, I promised to look thoroughly to see what options I may have missed.

[crythias]

It's really a training issue. If you assume that nobody has email address, then work from that angle. It's a bit tough to get software to make a human change behavior patterns.

[Linwood]

It's really a training issue. If you assume that nobody has email address, then work from that angle. It's a bit tough to get software to make a human change behavior patterns.

I get it. The main goal was to make sure I didn't miss something, like a setting that makes email optional and changes system behavior. Sounds like there is not.

The real issue is that, from long and painful experience, I know it is usually easier to change a computer's behavior consistently than a human's.

One option that comes to mind is use of an identifiable pattern on the dummy email, then do some reporting on a periodic basis to let people review the (few) tickets that lack email and ensure there is indication of proper non-email followup. What we can't automate, we should at least monitor.

[Linwood]

Here is what I ended up doing in case it is helpful toothers.

First, I set up postfix on the machine, and set it to be an email sink, as described here: http://wiki.otterhub.org/index.php?titl ... mail_Users

I elected to set the regular expression for mail in this form:

Code: Select all

/.*@nomail.*/  absorbmail@localhost

That matches anything with a leading portion of the right said of nomail, and I used "absorbmail" as the local alias instead, but otherwise pretty much as in the wiki.

Aside: I also had changed, and it is documented here somewhere, the AdminCustomerUser.tt to auto-populate the CustomerID and Login fields from the email.

I added to that screen:

Code: Select all

# Custom changes to enforce email to other fields
<script type="text/javascript">
function MailBlurFunction() {
    document.getElementById("UserLogin").value = document.getElementById("UserEmail").value;
    document.getElementById("UserCustomerID").value = document.getElementById("UserEmail").value;
}
function PhoneBlurFunction() {
    if(document.getElementById("UserEmail").value == "" && document.getElementById("UserPhone").value != "" ) {
        document.getElementById("UserLogin").value      = document.getElementById("UserPhone").value + "@nomail";
        document.getElementById("UserCustomerID").value = document.getElementById("UserPhone").value + "@nomail";
        document.getElementById("UserEmail").value      = document.getElementById("UserPhone").value + "@nomail";
    }
}
</script>

The top piece is copying the email address to the other fields when needed, the bottom piece looks and when BOTH the email is blank, AND the Phone is not blank, it copies the phone number in and forms an email address of:

Code: Select all

312-555-12345@nomail

This gets propagated by the other function into the other fields, so now the ID of this user in all three fields is unique (well, assuming the phone is) and the email will get absorbed and not go out.

Up where the fields are displayed I have this, which is a combination of the two settings to tag those fields with the appropriate function (and mark read-only customer-id and login, which in our case will always be email, this is not true for those using the Customer (aka "Company") aspect of course).

Code: Select all

# customize: For duplicative fields make them read only and skipped, for email copy to these two
                            <input type="text" [% IF (Data.Name == 'UserEmail') %] onblur="MailBlurFunction();"
                                               [% ELSIF (Data.Name == 'UserPhone') %] onblur="PhoneBlurFunction();"
                                               [% ELSIF ( (Data.Name == 'UserCustomerID') || (Data.Name == 'UserLogin') ) %] readonly tabIndex="-1"
                                               [% ELSE %] [% END %]
                                     id="[% Data.Name | html %]" name="[% Data.Name | html %]" class="W50pc [% Data.RequiredClass | html %] [% Data.InvalidField | html %]" value="[% Data.Value | html %]" [% Data.ReadOnlyType | html %]/>

# customize: For duplicative fields make them read only and skipped, for email copy to these two
<input type="text" [% IF (Data.Name == 'UserEmail') %] onblur="MailBlurFunction();" [% ELSIF (Data.Name == 'UserPhone') %] onblur="PhoneBlurFunction();" [% ELSIF ( (Data.Name == 'UserCustomerI$

Then under sysconfig, admin, Framework, Core, CheckEmailValidAddress add nomail as follows:

Code: Select all

^(root@localhost|admin@localhost|.*@nomail)$

This keeps the mx check and syntax check from rejecting mails in this format. Be sure to restart postfix.

Missing from this -- and I'll have to find something suitable later -- is some kind of monitoring to ensure that people without emails actually get a human contact, so maybe some kind of search to see if these tickets are closed with the last non-automated contact of email, and flag them out. Or maybe I can figure out how to remove the email oriented replies from being possible with these kinds of emails. But that's secondary - this gives a structured way to handle it.

To me given the nature of otrs and how email centric it is, this is as close as I think I can get. Contrary advice welcomed.