External backend - using a legacy customer user table

[setecastronomy]

I'm new to OTRS and I'm making some tests with release 3.3.7.
This question is the translation of the one I posted in the italian board, where I didn't get any answer. If this is not compatible with the forum policy please forgive me, I don't have any idea where is the best place to seek help.

In the admin book in chapter 4.5 "Using external backends" I read how to use a different Customer_user table, it looks very simple, but I have the same problems described here as the third point.

According to the admin book there are only 3 required fields (User login, Email address,Customer ID): create_time and change_time which are present in the default customer_user table are never mentioned nor mapped, but if my personalized customer table lacks those fields I get an empty list of customers.
Somebody suggested to try ForeignDB => 1 but it seems it is not supported for customer user data.

Am I missing something ?

Besides I don't know how to debug OTRS and in the effort to understand why my configuration was not working I used a network sniffer.
I'm very worried by the number of queries sent to the db. Don't know if it depends on poor configuration, but in order to fill the list of customers I noticed a first query to get all the Customer ID and then lots of query in order to get the details of each customer. It doesn't scale !

Thanks
Filippo

[crythias]

Is it possible to restate your post as a question to be solved?

[setecastronomy]

The main question is:
can I use a legacy table as customer user table if it doesn't have create_time and change_time fields ?

From the documentation it is possible, but other people and I were not successful.

Thanks
Filippo

[reneeb]

Yes this is possible (at least as Readonly). If you want to add CustomerUsers, the table needs those columns (IMHO this is a bug).

[setecastronomy]

Yes this is possible (at least as Readonly).

How can I do ?

At the moment I'm making tests, so what I called a 'legacy table' is in reality a test table. In the configuration mapping I wrote I don't have create_time and change_time . Anyway if they are fields in the table I get a list of customer, otherwise, if I remove these two fields, I get an empty list.

As stated above I'm using OTRS 3.3.7

Thanks
Filippo

[reneeb]

Please show us your configuration (please replace password and username with something else).

[reneeb]

Ok, I just discovered that this is a bug solely in the version you are using: https://github.com/OTRS/otrs/commit/c3a ... 4294367d2e

So please upgrade to OTRS 3.3.8

[setecastronomy]

It is a bit sad when you find a bug during one of the first evaluation tests.
You really wonder if it worth to go further or it is better change software...Don't know...
At least the OTRS team has proven to be responsive...

[reneeb]

Every single piece of software has bugs. Most bugs (in any software) will stay hidden for you as you do not use the buggy feature. You have to decide yourself whether you stick with OTRS or not. If it fits your needs (beside this bug), *I* would stick with it. As it is Open Source it's easy to fix the bug. If other software fits your needs better, use that software.

[setecastronomy]

I have just moved to OTRS 3.3.8 and now create_time and change_time are no longer needed to list the customers.

If you want to add CustomerUsers, the table needs those columns (IMHO this is a bug).

It is still true. Here is the error message I got after trying to add a customer:

Code: Select all

SQL: 'INSERT INTO persone ( Nome, Cognome, CodiceFiscale, email, ID_persona, Telefono, Cellulare, Via_Piazza, Cap, Localita, Note, create_time, create_by, change_time, change_by) VALUES ( 'piro', 'bello', 'piro12', 'piro@tin.it', 'pprtt90jk', '', '', '', '', '', '', '2014-07-17 10:08:06' , 1, '2014-07-17 10:08:06' , 1)' 

So create_time, create_by, change_time, change_by are needed in a writable Customer table.
You said that from your point of view this is a bug: do you know if there are plans to fix it ?

[reneeb]

In the repository this is already fixed: https://github.com/OTRS/otrs/commit/211 ... f2f9ca2ef3 This will be included in OTRS 3.4