I’m not doing a formal bug report yet because I assume the problem has more to do with our installation than the plugin itself. However, I’m stuck with a weird problem.
For some reason the plugin isn’t storing the licence key properly. I need to readd it almost daily. When added, it works for some time, but the next day it is usually gone and I have to re-enter the licence key.
I see nothing suspicious in the logfiles except for this line repeating:
[DEBUG] process_order_by: (users.sa_outlook_sync_date) does not have a vardef entry.
Any ideas? I haven’t tried to reinstall and would prefer not to go through all the hassle again, if there was another way to solve this.
I had to focus on other things and the licence key seemed to stay for a few days (longest so far), but then it disappeared again. Having left loglevel to debug and grepping sa_outlook I noticed one thing: Until the point that (I assume) the licence key was lost, on each minute I see the same circle happening:
Fri Oct 23 06:15:03 2020 [10836][1][INFO] Query:UPDATE users SET sa_outlook_sync_date = ‘[xxx]’ WHERE id = ‘[xxx]’
Fri Oct 23 06:16:02 2020 [10855][1][INFO] Query:UPDATE users SET sa_outlook_is_licensed = 1 WHERE deleted=0 AND sa_outlook_is_licensed != 0
Fri Oct 23 06:16:02 2020 [10855][1][INFO] Query:SELECT count(*) AS the_count FROM config WHERE category = ‘sa_outlook’ AND name = ‘settings’
Fri Oct 23 06:16:02 2020 [10855][1][INFO] Query:UPDATE config SET value = ‘[xxx]’ WHERE category = ‘sa_outlook’ AND name = ‘settings’
Fri Oct 23 06:16:03 2020 [10855][1][INFO] Query:UPDATE users SET sa_outlook_is_licensed = 1 WHERE deleted=0 AND sa_outlook_is_licensed != 0
Fri Oct 23 06:16:03 2020 [10855][1][INFO] Query:SELECT count(*) AS the_count FROM config WHERE category = ‘sa_outlook’ AND name = ‘settings’
Fri Oct 23 06:16:03 2020 [10855][1][INFO] Query:UPDATE config SET value = ‘[xxx]’ WHERE category = ‘sa_outlook’ AND name = ‘settings’
Fri Oct 23 06:16:03 2020 [10855][1][DEBUG] get_full_list: order_by = ‘users.sa_outlook_sync_date’ and where = ‘users.sa_outlook_enable AND users.sa_outlook_is_licensed’
Fri Oct 23 06:16:03 2020 [10855][1][DEBUG] process_order_by: (users.sa_outlook_sync_date) does not have a vardef entry.
AND jt0.deleted=0 LEFT JOIN aos_products jt4 ON users_cstm.aos_products_id_c = jt4.id AND jt4.deleted=0 where (users.sa_outlook_enable AND users.sa_outlook_is_licensed) AND users.deleted=0
AND jt0.deleted=0 LEFT JOIN aos_products jt4 ON users_cstm.aos_products_id_c = jt4.id AND jt4.deleted=0 where (users.sa_outlook_enable AND users.sa_outlook_is_licensed) AND users.deleted=0
Fri Oct 23 06:16:03 2020 [10855][1][DEBUG] process_full_list: User([xxx]): sa_outlook_sync_date =[xxx]
Fri Oct 23 06:16:03 2020 [10855][1][DEBUG] process_full_list: User([xxx]): sa_outlook_enable = 1
Fri Oct 23 06:16:03 2020 [10855][1][DEBUG] process_full_list: User([xxx]): sa_outlook_is_licensed = 1
Fri Oct 23 06:16:03 2020 [10855][1][INFO] Query:UPDATE users SET sa_outlook_sync_date = ‘[xxx]’ WHERE id = ‘[xxx]’
This had happened every minute until that time, and didn’t show up again. I think something goes wrong either with validation or constant re-encryption of settings. Is there a way to easily log unencrypted settings; I wouldn’t want to edit the code too much?
I’ll ask around with the team and see if we can figure out what’s going on.
I haven’t been able to replicate it again but unlike yourself, I’m not using the plugin on a day by day basis.
Since this doesn’t seem to be a general problem, I suspect what I’m seeing is an unintended side effect of a relatively old installation (originally 7.1.x) and if so, it’s probably something under custom. Do you or anyone else on @salesagility team have an idea which files would be worth checking first? And also, any guesses on what might be missing?
I don’t have many ideas. Not having the Outlook plugin code in my system, it’s quite hard to explore.
Just a couple of things:
things that happen every minute are things that happen from the Schedulers, you can try looking for a job that does Outlook plugin things
what exactly is that about “encrypted settings”? Some settings in SuiteCRM are stored as Base64 encoded, and people think they’re encrypted, but they’re not. You can see what’s inside using https://www.base64decode.org/ for example.,
Most likely yes. What’s interesting is how they abruptly ceased to recur.
Ah, I saw blowfish mentioned somewhere and jumped to conclusions. Anyway decoding then manually would be a pain since they get resaved every minute with small differences, so I’d much rather see them logged unencoded. I guess there’s no built-in feature for that?
If we are really talking about base64 encoded stuff, there’s a PHP function to decode it easily, so yes, you can send it to the logs in plain text if you want.
I was hoping that was implemented already even as an undocumented setting so that I wouldn’t need to customize the code myself. But better start digging!
Ok, QR&R didn’t help. Licence key was lost again on Friday. It actually disappeared while I was archiving mail so I got fresh to the scene. While looking at logs I see the same behavior as before: The loop of process_full_lists and updating settings stopped once the licence key was lost. I’m becoming more confident something is messing up the scheduler, causing the licence key to be lost. I’ll try rebuilding schedulers if that would help.
I had to focus on other things, but I’ve needed to readd the licence key quite a few times in the last month, so rebuilding schedulers did not do any good. I haven’t had time to do any additional testing yet, but maybe later this week.
Figure out, no , however, it has been reported as an issue which requires investigation and I’ve asked for it to be included within the next release. Next release date TBC atm but when I know you’ll know
Until then this I want to try yet haven’t got round to yet, try updating the database from the backend and see if anything changes, try to investigate the logs you pulled closer and play around with a workflow to change to the old value should it change away from it change. Will let you know if a workaround becomes available!
Yes, we’ve seen it on our end however I personally haven’t been able to find a easy way to replicate it. Just like yourself its been a waiting game. With an actual internal Dev instead of just myself hopefully soon to be working on it we might see some progress
Currently AFAIK its planned to be posted once the plugin leaves beta (Phase 3 is launched) which atm has an unconfirmed time frame. I’ll keep you up to date if any info it published
, however, it has been reported as an issue which requires investigation and I’ve asked for it to be included within the next release. Next release date TBC atm but when I know you’ll know 