Capture Customer-User demographics, and update?

[Linwood]

I fell like I am swimming up stream a bit, so maybe I am approaching this incorrectly.

I am implementing this for a municipality, so their customer base is ever changing and large (meaning the vast majority of the tickets are a first-time ticket for a customer-user).

It is easy to capture customer-user information (phone, address, etc.) from a phone-ticket entry by a human talking to the customer-user.

I see how to change the signup (registration) page to capture it also, and have done it as proof of concept, though I still need to get all the right validations (etc.).

But it would seem that a customer-user should somehow be able to update their own demographics, at least optionally. I don't see any obvious hooks to do that, short of creating a whole new feature (something I was hoping not to have to figure out -- unless there is a good example somewhere?). My first thought was to add to the preferences screen, but it does not seem adaptable (at least easily) for that.

Is there a better approach to this? It just seems natural that, with a certain level of self-service around tickets, (optionally) providing the ability to self-enter, and self-update demographics is appropriate as well.

Is it in there somewhere and I just haven't stumbled on it? I saw some screen shots on the web that almost implied this was built in? Is it perhaps a commercial not free feature?

[Linwood]

No one?

I noticed the default setup lacks "state" but has "zip", strangely us-centric without being complete, so obviously people are intended to customize the actual fields. And that appears pretty straightforward.

But customizing the CustomerLogin.tt is strangely difficult. It has a (apparently) hard coded height of 260px (coded way off in a CSS file for #Slider) that scrolls (but doesn't) so multiple panels are on the same screen, there's no room for a straightforward fix of listing all the address fields, and they are there explicitly rather than (as in the admin customer-user screen) iterating over the actual fields in the database definition.

It's just surprisingly a combination of arcane (the hidden panels), hard coded, and seems to lack a good hook for modifications. It just seems to shout "self service registration is not really here -- look elsewhere".

Do most people write their own?

Are there some out there I haven't found?

Some option I'm missing?

Or do I just expect too much?

I'm going to take a shot at adding State, then rearranging the panels to fit into the 260px (tried changing it and can see part of the other panel - so there are other places that need changing also), and go from there. But that still doesn't allow self-update of registration information.

[crythias]

The available fields are in the CustomerUser Map, which is default in Defaults.pm. To add "State", you'll need to alter the database to include that field, then add State to the Map (Copy from Defaults.pm to Config.pm and modify there.)

[Linwood]

The available fields are in the CustomerUser Map, which is default in Defaults.pm. To add "State", you'll need to alter the database to include that field, then add State to the Map (Copy from Defaults.pm to Config.pm and modify there.)

Yeah, I have that. Sorry, that was probably a tangent, my point being the CustomerLogin.tt was hard coded for these fields, not dynamic. Forget that.

My basic question is that the self registration seems incomplete, in that it does not allow the customer to modify their setup once entered.

It also seems rather incomplete in the hard coding sense.

Is there a different self registration feature most people use? Do people using write their own from scratch (including update), or modify this?

[crythias]

Unfortunately, no, there hasn't (as far as I can tell) been a way to have a user self-update his demographics. This is primarily because most environments handle demographic information separately from ticket information: Active Directory, CRM, etc. That is to say, the idea is generally that the customers are actually known to the service provider prior to the Customer randomly creating a ticket. Admittedly, not always the case, but even in a municipality, it seems somewhat reasonable (?) that the customer information would be of a public and reasonably static nature. OK, maybe that's just going a bit too far, but, yes, this ticketing system is not optimal for transient data of walk-up/dial-up/self-service customers.

[Linwood]

Unfortunately, no, there hasn't (as far as I can tell) been a way to have a user self-update his demographics.

Thanks. Knowing the absence is very helpful, keeps me from endlessly looking.

...but even in a municipality, it seems somewhat reasonable (?) that the customer information would be of a public and reasonably static nature.

You'd think. I suspect if I really pushed hard I would find out the issue is there are a dozen databases with such information, none coordinated with each other, and needing an act of congress (perhaps literally) to make them available. I'll ask again, but seems unlikely.

Trying now to work through the customizations. I'm a bit hazy on one aspect if you can tolerate another question: if I want to change the

Code: Select all

/opt/otrs/var/httpd/htdocs/skins/Customer/default/css/Core.Login.css

file, do I need to create a new skin, or use the Custom directory (I did the latter but so far it does not seem to "see" the css):

Code: Select all

Did this>>> /opt/otrs/Custom/var/httpd/htdocs/skins/Customer/default/css/Core.Login.css
Not this>> /opt/otrs/var/httpd/htdocs/skins/Customer/NewSkin/css/Core.Login.css

I reset permissions and restarted apache, and it still seems to be taking the one from the original directory. But I'd prefer not to have to create a new skin.

I'm equally a bit puzzled about themes -- I did create new theme to get the area to customize the .tt files, but there is other documentation that recommends that .dtl (which I see preceded .tt) should go in a ./Custom tree instead. Is that ./Custom now gone in favor of skins and themes, but still documented in the README there?

[Linwood]

Actually I just ended up hard coding style overrides in the div and input statements I needed to change; bad practice really if there are ever skins for other media. I found postings on deleting the css cache and turning off the css loader but neither made a difference, I just don't think the /custom approach works for css?