NaN seconds ago

[uhlhosting]

I only receive this information when it comes to time:

NaN seconds ago

[barrydegraaff]

To time what?

[uhlhosting]

@barrydegraaff this is the Time of the so called login time of the Account history boards. I see in both Admin and Client side, instead of a time like in your showcase, only NaN seconds ago.

[uhlhosting]

details: NaN,922 2018-07-18 15:39:06,922 INFO [qtp1286783232-167:http://localhost:8080/service/soap/AuthRequest] [name=cosmin@uhlhost.net;oip=xxx.xxx.xxx.xxx;ua=zclient/8.8.9_GA_2055;soapId=5b5fc50f;] security - cmd=Auth; account=sss@xxx.; protocol=soap;

[barrydegraaff]

What is your OS version and Zimbra version?

[uhlhosting]

@barrydegraaff running latest Zimbra 8.8.9, and Centos 6. Here a screenshot: http://prntscr.com/k8goe3

[barrydegraaff]

I have a feeling CentOS 6 does not work, I had some trouble running on that myself, perhaps the log format differs from CentOS6 to 7... but have not yet be able to debug that.

[marcello-lodi]

Same bug also in CentOS 7.5 But when choosing 'Full log', then the date is displayed correctly.

[uhlhosting]

@marcello-lodi choosing Full log? Can you explain that

[marcello-lodi]

Sure. I upload a couple of screenshot. If right click on Account history, it is possible to chose 'Full log'. Then hours are displayed on the list.

I hope it is more clear now.

[uhlhosting]

Check the down side, the bug is still persisting. Indeed the upper part shows a time now. So by using full log 50% of the issue can be just to double check the code and small fix applied should do.

[marcello-lodi]

Yes, sure. You are right.

[uhlhosting]

Yep, this is a minor bug as it seems.

[barrydegraaff]

For some reason the log format on your server is different, what I am used to see is this: Details: 1533729874000,265 2018-08-08 14:04:34,265 INFO [qtp1286783232-11133:http://localhost:8080/service/soap/AuthRequest] [name=info@barrydegraaff.tk;oip=xxxxxxxxxxx;ua=zclient/8.8.9_GA_3006;soapId=171397da;] security - cmd=Auth; account=info@barrydegraaff.tk; protocol=soap;

What you get seems to be this: NaN,922 2018-07-18 15:39:06,922 INFO [qtp1286783232-167:http://localhost:8080/service/soap/AuthRequest] [name=cosmin@uhlhost.net;oip=xxx.xxx.xxx.xxx;ua=zclient/8.8.9_GA_2055;soapId=5b5fc50f;] security - cmd=Auth; account=sss@xxx.; protocol=soap;

The Zimlet parses the date by getting substring(18,37) (in my case) and that works in the first case, but not your case. I guess we will need to use the javascript explode() method and split the string as if it was delimited by space. And then glue together the appropriate parts.

I will pick up on this tomorrow.

Thanks for reporting, and excuse the tardiness.

[barrydegraaff]

In addition the Zimlet uses the first long character to calculate how to display time since , so minutes ago, instead of just showing dates.

That will no longer work, as apparently that is not always present in the log, we should find out why.

But in the mean time, we should just get the date as mentioned in my previous comment and convert that to unixtime.

See also: https://github.com/Zimbra-Community/account-history/commit/2bb1dfea6cf9fde572ed5bee4937829201fc8fff

[barrydegraaff]

Not that minor a bug :-p But also not too big.

[barrydegraaff]

Instead of using explode() perhaps a regex is better, as than it would not matter where the date can be found in the log string.

[uhlhosting]

It might be connected also with the ZImbra's logging options.

[barrydegraaff]

I implemented the regex, can you guys redownload and rerun the installer and see if this fixes the issue.

If not, use google chrome hit f12 view the console tab, and send me the contents of the logged data. It looks like [{…}] and you need to click it to expand. You can send it to info@barrydegraaff.tk

NaN can be a result of a failed date.parse (in which case we need to replace it with something like new Date(year, month, day [, hour, minute, second, millisecond ]))

If it still does not work, for some reason date.parse does not work on your browser. Perhaps since you are from France, are you using a localized (aka french) google chrome?

Does it work in the US/en version? In any case we probably need to remove date.parse

[marcello-lodi]

Hi Barry, thank you for your reply. I am doing some test with Chrome and Firefox. With these browsers the fix works. But the issue persists while using Safari. I am from Spain and the locale I am using is en_ES. I hope it helps. No logs from the web console.

[barrydegraaff]

Yep that means date.parse is useless.

[barrydegraaff]

@marcello-lodi please redownload and re-run the installer, then it should work in Safari as well. Can you confirm the issues are resolved now?

[marcello-lodi]

Great!!! It worked with Safari. Thank you.

Just a comment: it seems to be an error with a javascript library. Here it goes the error and the link which produces the error (or warning).

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (purify.js.map, line 0) https://mail.xxxx.xxxx.es/service/zimlet/_dev/tk_barrydegraaff_account_history/purify.js.map

It is only with Safari. No problem with Chrome and Firefox.

[barrydegraaff]

The 404 error is not a big issue, so I am leaving that as is for now. Also I need to back-patch all these changes to the admin zimlet. I'll leave this one open till the admin-zimlet is patched.

[uhlhosting]

Now it's patched? can we upgrade?

[barrydegraaff]

@uhlhosting yah, the client zimlet was patched 25 days ago, but now the admin zimlet as well, so yes give it a go!