Hi all,

I was not sure where to post this so I'll address both the users and
developers community because I expect both can use this.

As I posted before, I needed some way to initialize some of the Customer
User fields according to some rules I use at my site.

I therefore added an extra column to the Customer User back-end Map table
that allows one to enter a Perl expression or call to a method that will
enforce these rules.
In addition, you can also use this to verify and/or format the contents of
the field that are typed in by the user. I admit, this is something that
probably needs to be handled somewhere in the front-end
(CustomerCreateAccount.dtl ?) but for now this works.

As I am not sure whether I need to post a diff of the standard OTRS code I
modified I thought I better post the complete module (I only changed one
anyway). In addition there are some other files I will describe below:

Kernel::System::DB      The modified OTRS module
Kernel::Config          This is an excerpt of the User configuration file, only use
for reference!
Kernel::System::CustomerUser::Local::Init       Local module containing
initialization and formatting routines.
ReadMe.txt              Describes the whole thing.

If you have any question, please do not hesitate to ask.

Have fun,
Tom Hesp

Attachment: DB.pm
Description: Binary data

Attachment: Config.pm
Description: Binary data

Attachment: Init.pm
Description: Binary data

XX.X.X Customer Field Initialization

It is possible to influence the way Customer User fields are initialized, verified 
and/or formatted.
You can do this by entering a Perl expression or call to your own method in the 
Customer Map table in your
Kernel/Config.pm file (copy the map table from Kernel/Config/Defaults.pm if 
necessary). You may need to take a
look in Kernel/System/DB.pm to see how objects and variables from the map are handled.

Note that the expressions that you enter in the map are not checked for syntactic 
correctness, so make sure you
know what you are doing!

If you want to make use of your own local methods for field initialization, you need 
to define your own module
(see CustomerInitModule setting in the example below). Setting this parameter will 
result in the creation of
the 'LocalCustomerUserObject' object in Kernel::System::DB. Use this object to refer 
to your own initialization
method(s). Refer to the settings in the example Map table below and in the 
Kernel::System::CustomerUser::Local::Init
module.


Example CustomerUser Map:

    $Self->{CustomerUser} = {
        Module => 'Kernel::System::CustomerUser::DB',
        Params => {
            Table => 'customer_user',
        },

        CustomerInitModule => 'Kernel::System::CustomerUser::Local::Init',

        Map => [
            # note: Login, Email and CustomerID needed!
            # var,              frontend,       storage,        shown,  required,      
 storage-type,   http-link,      source
            [ 'UserSalutation', 'Salutation',   'salutation',   1,      0,             
 'var',          '' ],
            [ 'UserFirstname',  'Firstname',    'first_name',   1,      1,             
 'var',          '' ],
            [ 'UserLastname',   'Lastname',     'last_name',    1,      1,             
 'var',          '' ],
            [ 'UserCompany',    'Company',      'company',      1,      0,             
 'var',          '' ],
            [ 'UserAddress',    'Address',      'address',      1,      1,             
 'var',          '' ],
            [ 'UserHousenumber','Housenumber',  'housenumber',  1,      1,             
 'var',          '' ],
            [ 'UserZipcode',    'Zipcode',      'zipcode',      1,      1,             
 'var',          '',             
'$Self->{LocalCustomerUserObject}->VerifyZipcode(Zipcode => $Param{UserZipcode})' ],
            [ 'UserCity',       'City',         'city',         1,      1,             
 'var',          '' ],
            [ 'UserPhone',      'Phone',        'phone',        1,      1,             
 'var',          '' ],
            [ 'UserMobile',     'Mobile',       'mobile',       1,      0,             
 'var',          '' ],
            [ 'UserFax',        'Fax',          'fax',          1,      0,             
 'var',          '' ],
            [ 'UserLogin',      'Login',        'login',        0,      1,             
 'var',          '',             '$Param{UserEmail}' ],
            [ 'UserPassword',   'Password',     'pw',           0,      1,             
 'var',          '',             
'$Self->{LocalCustomerUserObject}->GenerateRandomString(PWLength => 8)' ],
            [ 'UserEmail',      'Email',        'email',        0,      1,             
 'var',          '' ],
            [ 'UserCustomerID', 'CustomerID',   'customer_id',  0,      1,             
 'var',          '',             
'$Self->{LocalCustomerUserObject}->GenerateCustomerID(ZipCode => $Param{UserZipcode}, 
Number => $Param{UserHousenumber})' ],
            [ 'UserComment',    'Comment',      'comment',      1,      0,             
 'var',          '' ],
            [ 'ValidID',        'Valid',        'valid_id',     0,      1,             
 'int',          '' ],
        ],
    };


Note that I did not copy all entries for the CustomerUser back-end definition.

As you can see from the example we defined a local module that defines the methods 
referred to in the map.

We added a number of extra fields to be entered by the user. Some of these fields must 
adhere to the rules as we have
defined at our site, being:

        o Zip Code must be stored in the format 9999AA (Dutch format: Four numerics 
and two uppercase characters).
        o UserLogin is the same as the user's Email address.
        o The UserPassword is a generated 8-character alphanumeric value.
        o The UserCustomerID is generated using a couple of values alreay entered by 
the user.

See the code in the example local Init module on how these rules are enforced.

Some notes on this:

- Formatting and verification of values entered by a user is better done at the 
front-end. However, this would
  require quite some tweaking of java code in several .dtl files while you would also 
want a better format
  definition mechanism then, maybe something for a later date?
- When you define an initialization expression, this will always override values 
entered by the user! If you do not
  want this you need to check/prevent this in your own initialization routines.
- If you initialize the UserPassword field you better pass it as clear-text, if you 
encrypt it it will get encrypted
  a second time by OTRS! (That will get you a very secure system though... :-) ).
- The initialization expressions will only be executed when adding a Customer User! 
They will have no effect to 
  changes on existing customer records as there is a danger that fields are modified 
(for instance 
  CustomerUserID & UserPassword in the example above) unintendedly.
- The Kernel::System::DB module contains a commented-out call to the system log 
module. You can uncomment it to get
  a slightly better idea on what the results of your own initialization expression 
are. 


That's it, have fun.

Tom Hesp
[EMAIL PROTECTED]
_______________________________________________
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
Support oder Consulting für Ihr OTRS System?
=> http://www.otrs.de/

Reply via email to