Schedule not working

[Ilkein]

Hi,

schedule shows next occurrence at January 01 1970 1:00 am

Today, I've installed all from scratch. The applied software is: Debian Stretch 9.6 osTicket 1.10.5 php-7.0 multildap-auth 1.22

I attach some screenshots for your reference

As I've realized no more than one syncronization has been done:

More, I can login with AD user and user is created correctly, although mappings of fields are not working...

Best regards

[philbertphotos]

Ok have to check why to does that

Sent from my iPhone

On Feb 14, 2019, at 2:04 PM, Ilkein notifications@github.com wrote:

Hi,

schedule shows next occurrence at January 01 1970 1:00 am

Today, I've installed all from scratch. The applied software is: Debian Stretch 9.6 osTicket 1.10.5 php-7.0 multildap-auth 1.22

I attach some screenshots for your reference

Best regards

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[niphint]

I had a similar problem. 1970 for next sync... Problem was, that in table config the "sync_data" wasn't there for the plugin, so i added it on the database

Now it will sync.

[Ilkein]

I had a similar problem. 1970 for next sync... Problem was, that in table config the "sync_data" wasn't there for the plugin, so i added it on the database

Now it will sync.

Hi niphint, thanks for your kind reply.

I've done what you recommend and it seems not to work escribe ost_config; +-----------+------------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------+------------------+------+-----+-------------------+----------------+ | id | int(11) unsigned | NO | PRI | NULL | auto_increment | | namespace | varchar(64) | NO | MUL | NULL | | | key | varchar(64) | NO | | NULL | | | value | text | NO | | NULL | | | updated | timestamp | NO | | CURRENT_TIMESTAMP | | | sync_data | date | YES | | NULL | | +-----------+------------------+------+-----+-------------------+----------------+

Is this table the one that you mentioned?

[niphint]

Is this table the one that you mentioned?

yes, after i have inserted the key "sync_data" the value column is populated with schedule and lastrun.

so the scheduling works now... however he still doesn't create customers, but thats another story.

[Ilkein]

I had a similar problem. 1970 for next sync... Problem was, that in table config the "sync_data" wasn't there for the plugin, so i added it on the database Now it will sync.

Hi niphint, thanks for your kind reply.

I've done what you recommend and it seems not to work escribe ost_config; +-----------+------------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------+------------------+------+-----+-------------------+----------------+ | id | int(11) unsigned | NO | PRI | NULL | auto_increment | | namespace | varchar(64) | NO | MUL | NULL | | | key | varchar(64) | NO | | NULL | | | value | text | NO | | NULL | | | updated | timestamp | NO | | CURRENT_TIMESTAMP | | | sync_data | date | YES | | NULL | | +-----------+------------------+------+-----+-------------------+----------------+

Is this table the one that you mentioned?

Is this table the one that you mentioned?

yes, after i have inserted the key "sync_data" the value column is populated with schedule and lastrun.

so the scheduling works now... however he still doesn't create customers, but thats another story.

Hi again niphint,

I misunderstood you. I thought I had to add a new column to the table. But the action had to be insert new row to the table.

Triying to do that I faced other problems: the SQL statement complained continuosly, because some of the column names, sadly, are mysql reserved words (key and value).

Pay attention, in this example my database is called osticketDB: SELECT * FROM osticketDB.ost_config;

Once you get all the rows, take care of what is the last number in the column 'id'. In my case it was 128. And the LDAP plugin "magical" number. In this exemple, 'plugin.2'.

So, the SQL stament is:

Note the accent `` and comas '' in order to bypass mysql keywords.

Logged into osTicket SCP and whoa!:

[Ilkein]

Ok have to check why to does that … Sent from my iPhone On Feb 14, 2019, at 2:04 PM, Ilkein @.***> wrote: Hi, schedule shows next occurrence at January 01 1970 1:00 am Today, I've installed all from scratch. The applied software is: Debian Stretch 9.6 osTicket 1.10.5 php-7.0 multildap-auth 1.22 I attach some screenshots for your reference Best regards — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Maybe the cause are the column reserved words as stated?

[philbertphotos]

Will be creating a fix later today. On Tue, Feb 19, 2019 at 05:41 AM, "Ilkein" wrote: Ok have to check why to does that … (#) Sent from my iPhone On Feb 14, 2019, at 2:04 PM, Ilkein @.***> wrote: Hi, schedule shows next occurrence at January 01 1970 1:00 am Today, I've installed all from scratch. The applied software is: Debian Stretch 9.6 osTicket 1.10.5 php-7.0 multildap-auth 1.22 I attach some screenshots for your reference Best regards — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. Maybe the cause are the column reserved words as stated? — You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://github.com/philbertphotos/osticket-multildap-auth/issues/26#issuecomment-465059698), or mute the thread (https://github.com/notifications/unsubscribe-auth/ACwiulcN5cPzCaDbXfpOpfzzwbqhHtwxks5vO8bMgaJpZM4a8JGS).

[philbertphotos]

Fixed.