Suitecrm: 7.7.2 - Calendar Activities are off by 1 day

[bennnjamin]

Issue

When you add a call/meeting in the calendar, it displays in the week and month view (for both user and shared calendars) one day before the actual time the activity is scheduled. If you click on the activity to edit it, the appropriate date time is listed. Additionally, the date time for the activity is stored in the database correctly leading me to believe it is an issue with the Calendar view on the client side (Cal.js).

Expected Behavior

The event should display at the correct date and time in the calendar view.

Actual Behavior

The event is one day before the correct date in the calendar view.

Possible Fix

Steps to Reproduce

1. Go to Calender module
2. Click Week view
3. Add a new event by clicking anywhere in the week view
4. Observe that the event is displayed one day before the event's actual date in the calendar view

Context

Trying to use the calendar is impossible with the entire calendar being off by one day. This is a high priority for the Calendar view itself but low priority in the scope of the larger project.

Your Environment

• SuiteCRM Version used: 7.7.2
• Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Occurs on Chrome and Safari
• Environment name and version (e.g. MySQL, PHP 7): PHP 5.6.20-0, mysql Ver 15.1 Distrib 10.0.23-MariaDB
• Operating System and version (e.g Ubuntu 16.04): Debian 8

[shogunpol]

I tested this issue in similar environment, and issue not appear,
@bennnjamin , can you give me more details about your settings, for example: date time format, which time zone you are in.

[bennnjamin]

@shogunpol maybe it is a setting issue on my end then. Time zone settings had occurred to me to be a culprit so I tried changing them but it didn't have any effect. Here's my settings:

[ginslo]

I am having the same issue with meetings/calls/tasks etc appearing on the previous day in the calendar. My production installation is old, recently upgraded from 7.1.6 to 7.7.2, however to test this issue, I have just installed a fresh copy of 7.7.3 (ba95cd5) from this repo on my localhost with sample data and the same thing is occurring.

Whether creating the event by clicking on the calendar itself or via the form, the events show up in the incorrect position. If created on a Friday, it shows up on Thursday in the calendar view. This is on week, month, shared month views. Strangely, no events display in the day view on any days (possibly another unrelated issue).

One observation that may help troubleshooting is when you hover over the event on the calendar, the popup shows the date that the event is in, even though it is not the date in the db record, so maybe related to JS. Example: I create a task for 8/26. It displays in the calendar on 8/25. The popup also shows 8/25. If you click on the event, the editable popup shows the correct date of 8/26.

SuiteCRM 7.7.3 ( ba95cd5)
Dist: Fedora 24
PHP 5.6.24
MySQL Ver 15.1 Distrib 10.1.16-MariaDB
Chrome Version 52.0.2743.116 (64-bit)
Firefox Version 48.0.1

Events in this screenshot are for Friday, 8/26 but incorrectly display on Thursday 8/25.

[staganyi]

I raised this issue in https://github.com/salesagility/SuiteCRM/issues/1938

[bennnjamin]

@staganyi I read your issue before opening mine and since your version was 7.7.1 and the release notes for 7.7.2 claim to have fixed it, I thought maybe this is a new issue.

[staganyi]

That's fine. I actually had a couple bugs on my post and they still closed it without fixing both. This issue is still present on a clean install of v7.7.3. Should be a high priority bug since it renders the calendar useless.

[nathbeadle]

I signed up just to get in on this. The calendar was working perfectly until I upgraded to 7.7 and now the dashlet on my home screen is useless and the calendar module is showing everything a day earlier, even though going into the event/meeting/call shows the date and time correct.

This is a HUGE thing to fix as my team heavily relied on that dashlet!!

EDIT: Okay, so the dashlet is now functional as it's showing events and the hours down the left side of the calendar view. The only issue is everything is displaying a day earlier even though the event information shows the correct date and time.

So more usable but still not fixed

[shogunpol]

@bennnjamin and @ginslo i did re-testing with recent version of SuiteCRM(7.7.3), with settings from screenshots, and again this time i been not able to replicate the issue, all dates and settings in calendar module work correct.
To make sure i take enough care to your issues i did tests on updated and also on fresh installation of SuiteCRM.
Also i analysed your version of environment, and didn't find any similarities what may causing issues.

My Environment

SuiteCRM Version used: 7.7.3
Browser name and version: Version 51.0.2704.79 Ubuntu 14.04 (64-bit)
Environment name and version: PHP 5.5.9-1 Ubuntu 4.19; MySQL 14.14 Distrib 5.5.50
Operating System and version: Ubuntu 14.04.5 LTS

I understand this is an issue, because more than one person has raised the same problem, this can be down to PHP or MYSQL version, however so far im unable to replicate this. I will keep looking on this issue.

[staganyi]

Obviously there is an issue with how the calendar translates the event (meeting, call...) because when you use the detail view of the item, the correct date and time is displayed.

[bennnjamin]

@shogunpol I discovered the nature of the bug and why it is not showing up on your installation. My assumption is that you are located in a region of the Earth that is closer to UTC (I am in UTC-7 DST).

The bug is purely javascript related and is in Cal.js line 771 - 772. It is because moment.js parses dates in local time (http://momentjs.com/docs/#/parsing/utc/). I found that that the day component of the calendar event was the correct day (in unix timestamp). I am not sure if this will hold valid across multiple local timezones and Suitecrm timezone settings. If element['ts_start'] in Cal.js is stored/retrieved according to UTC then this fix should work for all timezones. If it is converted at any point it may take someone who knows the project better than me to ensure correct timezone manipulation. In any case, future issues may crop up like this. I know first hand how frustrating dealing with timezones in Javascript is.

For now I have fixed the bug by wrapping the moment creation in a moment.utc() call to prevent the date from being automatically converted to the user's local timezone (read: BROWSER timezone, not SuiteCRM timezone). A more appropriate solution would be to convert the timestamp based on SuiteCRM's timezone setting for that user. As of now, if the SuiteCRM timezone setting and browser time setting are not identical this may still cause some event times to be incorrectly displayed.

Fix for now:

/*771*/ valueToPush["start"] = new Date(moment.utc(moment.unix(element['ts_start'])).format("MM/DD/YYYY") + " " + moment(element['time_start'], 'hh:mma').format("HH:mm")); /*772*/ valueToPush["end"] = moment(new Date(moment.utc(moment.unix(element['ts_start'])).format("MM/DD/YYYY") + " " + moment(element['time_start'], 'hh:mma').format("HH:mm"))).add(element['duration_hours'], 'hours').add(element['duration_minutes'], 'minutes');

[nathbeadle]

I tested bannnjamin's fix by updating line 771 and 772 in Cal.js in the Calendar module folder and the events (meetings, calls, etc) are now listed under the correct day in the daily/weekly/monthly views! Great work figuring that out!

[ginslo]

Yes, thank you @bennnjamin! Confirming that updating modules/Calendar/Cal.js as described fixes the display. I knew the db had the right dates and it had to be view related. Note that I also had to do a browser refresh to clear cache (apparently) before it showed correctly. Great find!

[jason-unleashed]

thanks @bennnjamin
It does fix the main calendar display, but the calendar dashlet is a little funky now. Sometimes meetings appear 7 hours later than scheduled and then pop up to the correct slot.
i.e. I have a meeting at noon, but when I first log into suiteCRM the dashlet indicates 7pm. After about 15 sec or less, the meeting jumps up to the correct time slot. I haven't seen this behavior on the calendar page, only the dashlet.

I also noticed the calendar dashlet gives me a couple "undefined" messages when I pause the mouse on an item. Don't have that on the main calendar.

Thank you for providing a workaround. Hopefully, a complete fix is found soon.

Cheers,
J

[ijdavie]

Hi @bennnjamin, that information has done the job, @shogunpol has been able to replicate this and is working with your snippet to see if a fix can be developed. @shogunpol will keep you updated.
Thanks for the information.

[jfaerts]

This error is occurring today, 09/13/2016 in version 7.7.4

CAL.update_vcal = function () {
var v = CAL.current_user_id;
var callback = {
success: function (result) {
line 771 if (typeof GLOBAL_REGISTRY.freebusy == 'undefined') {
GLOBAL_REGISTRY.freebusy = new Object();
}
if (typeof GLOBAL_REGISTRY.freebusy_adjusted == 'undefined') {
GLOBAL_REGISTRY.freebusy_adjusted = new Object();
}
GLOBAL_REGISTRY.freebusy[v] = SugarVCalClient.parseResults(result.responseText, false);
GLOBAL_REGISTRY.freebusy_adjusted[v] = SugarVCalClient.parseResults(result.responseText, true);
SugarWidgetScheduler.update_time();
}

[nathbeadle]

I upgraded to 7.7.4 from .3 and re-applied the fix from bennnjamin and the calendar seems to work again. I'm guessing the fix wasn't in 7.7.4 as everything shifted off a day after the update.

To note, the Cal.js file has been condensed and all spacing and comments have been removed... not a fan of this as it makes trouble-shooting and customizing a huge pain. The code needs to be updated on line 145 in the new Cal.js file.

Can someone please not condense the code?

[jfaerts]

Thanks for the update.

JohnA

On Tue, Sep 13, 2016 at 2:44 PM, nathbeadle [email protected]
wrote:

I upgraded to 7.7.4 from .3 and re-applied the fix from bennnjamin and the
calendar seems to work again. I'm guessing the fix wasn't in 7.7.4 as
everything shifted off a day after the update.

To note, the Cal.js file has been condensed and all spacing and comments
have been removed... not a fan of this as it makes trouble-shooting and
customizing a huge pain. The code needs to be updated on line 145 in the
new Cal.js file.

Can someone please not condense the code?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/salesagility/SuiteCRM/issues/2049#issuecomment-246835047,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVJ3ECgzf7hU-3mHZDhlZJrjssxQxlh8ks5qpxlGgaJpZM4JtkFl
.

[staganyi]

Still not fixed in 7.7.7. When you add an activity, it shifts it to the previous day. However, when you reload the page, it is displayed in it's correct day. I have not had a chance to test the proposed fix.

[staganyi]

I think the fix was actually applied in the 7.7.7 release because the code looks identical to what was proposed. I would label this high priority since the calendar is an extremely important aspect to the crm.

[mdinat3]

They fixed it in 7.7.7 but only when you refresh the page, They forgot to update the dialog_save function moment conversion. I believe its line 646,647 and 659,660 in the modules/calendar/Cal.js file

replace this in both spots

newEvent.start = new Date(moment.unix(res['ts_start']).format("MM/DD/YYYY") + " " + moment(res['time_start'], 'hh:mma').format("HH:mm")); //newEvent.end = moment(new Date(moment.unix(res['ts_start']).format("MM/DD/YYYY") + " " + moment(res['time_start'], 'hh:mma').format("HH:mm"))).add(res['duration_hours'], 'hours').add(res['duration_minutes'], 'minutes');

With this

newEvent.start = new Date(moment.utc(moment.unix(res['ts_start'])).format("MM/DD/YYYY") + " " + moment(res['time_start'], 'hh:mma').format("HH:mm")); newEvent.end = moment(new Date(moment.utc(moment.unix(res['ts_start'])).format("MM/DD/YYYY") + " " + moment(res['time_start'], 'hh:mma').format("HH:mm"))).add(res['duration_hours'], 'hours').add(res['duration_minutes'], 'minutes');

[staganyi]

That did the trick, thanks @mdinat3!

[chris001]

@shogunpol This issue should be re-opened it's still broken on 7.8.1, as you can see in the above posts, the code from @mdinat3 to fix the dialog_save function must be added to a PR and merged to fully fix this bug.

[chris001]

@mdinat3 Can you do a PR for your update to the dialog_save function

[shogunpol]

Probably the best will be if, @mdinat3 will do the PR, but if he don't, i will do.

[mdinat3]

I'm a total noob to github, this was my first post because i knew how to fix this. Can someone show me how to do this? Or please go ahead if you like.

[chris001]

@mdinat3
Click Code, Branch, Hotfix.
Go to thru the folders until you get to the file you want to fix, /modules/Calendar/Cal.js
Click the Pencil icon on the top right of the editor box.
Go to the lines you want to fix, lines 646 and 659.
Fix each one.
Click Save.
Click to Create pull request.
Fill out the form.
Click Save.

[nathbeadle]

Hey guys,

I've been holding off on any further upgrades to SuiteCRM as I didn't
want to keep having to go into the code and fix the calendar for our
team. After seeing the flurry of emails a few weeks ago, has this issue
been finally resolved/implemented? I'm still running 7.7.4 right now.
Thanks!

On 2/20/2017 4:22 PM, Chris Coleman wrote:
>

@mdinat3 https://github.com/mdinat3
Click Code, Branch, Hotfix.
Go to thru the folders until you get to the file you want to fix,
/modules/Calendar/Cal.js
Click the Pencil icon on the top right of the editor box.
Go to the lines you want to fix, lines 646 and 659.
Fix each one.
Click Save.
Click to Create pull request.
Fill out the form.
Click Save.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/salesagility/SuiteCRM/issues/2049#issuecomment-281204565,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUSITxzKAR2JrKKZuKoxezXyCkdY3Emzks5reiA2gaJpZM4JtkFl.

[staganyi]

It wasn't in 7.7.9 which I am still on. Don't know about 7.8+.

[chris001]

@nathbeadle @staganyi
The PR #3170 which @mdinat3 made has not yet been merged, as you may be able to see above, there's no notification of it having been merged.
Also when you check the latest code in this repo, it's missing the added call to moment.utc:
https://github.com/salesagility/SuiteCRM/blob/master/modules/Calendar/Cal.js#L119
So after upgrading to 7.8.1, you would have to re-edit Cal.js.

[nathbeadle]

Okay, thanks all for the update/info. I'm honestly surprised that such a
big issue with a small fix has gone on for as long as it has. Obviously
not everyone is having this issue or noticing it. I'll hold off
upgrading for now as everything is working fine for the moment. Hope it
is fixed once and for all soon. Cheers!

On 3/8/2017 1:17 PM, Chris Coleman wrote:
>

@nathbeadle https://github.com/nathbeadle @staganyi
https://github.com/staganyi
The PR #3170 https://github.com/salesagility/SuiteCRM/pull/3170
which @mdinat3 https://github.com/mdinat3 made has not yet been
merged, as you may be able to see above, there's no notification of it
having been merged.
Also when you check the latest code in this repo, it's missing the
added call to |moment.utc|:
https://github.com/salesagility/SuiteCRM/blob/master/modules/Calendar/Cal.js#L119
So after upgrading to 7.8.1, you would have to re-edit |Cal.js|.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/salesagility/SuiteCRM/issues/2049#issuecomment-285156132,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUSIT6O35CXGHrcPW6BINYQFtc9nLJWaks5rjwzMgaJpZM4JtkFl.

[chris001]

@nathbeadle I'd ask the same of @samus-aran and @shogunpol , what's the criteria for including, or not including as it were, a bug fix such as this one, in the 7.8 release.

[cumanacr]

This problem is still present in SuiteCRM 7.9.1 and the fix in @mdinat3 comment stills fix it not in the same line, but in line 119

IMHO this is a must, it's easy to merge and fix a big problem.

Regards

[chris001]

@nathbeadle @cumanacr
I believe the folks at @salesagility including but not limited to @samus-aran and @shogunpol , cannot fully appreciate the importance of merging this fix #3170 immediately, because they're located inside the UTC time zone which makes it so that code containing bugs with regards to failing to compensate for time zone, does not show as a bug, because UTC time and their local time are one and the same.
So there appears to be no bug for them.
Yet this isn't the case for us, we see the bug clearly because UTC time is not equal to local time.

[staganyi]

Exactly. These date "issues" occur throughout the CRM and I've lost count of how many fixes I've had to manually apply. All because of the UTC time zone.

[pgorod]

@Dillon-Brown I see you're going through old stuff, this Issue here is one that should really be fixed, it's not really low-priority, and complaints keep coming up about this. Thanks!

[Dillon-Brown]

@pgorod Will take a look. Seems like it's just a case of resolving the conflicts in #3170 and remaking for 7.8.x

[mrbarletta]

So sad to see solved issues by the community being ignored for years, thats why this community never took off, thats why Greg's idea of raising 300K for SuiteCRM didn't work he has no community.

I still you guys (salesagility team) do a great job, but you still don't understand Open Source community building, you can grow as a company but that is not the same as growing a community, hope you can make your team leaders notice this.

[samus-aran]

Hey @mrbarletta, Thanks for being honest with us. Yeah, I get where you are coming from. I think the specific case with this issue is that yes a community member provided a fix #3170 but didn't include the source files (so it was half fixed). Our team felt it was good fix and made PR that does include it #5456. We got feedback that it didn't quite work and it fell to the wayside of day to day tasks of other bugs...

But to address the lack of community... you know I’ll disagree (that’s to be expected I guess, right?). We are a community and we do help each other and work together, but I concur we can improve and become abit more focused on the processes of making this open source project great and that is something I fully take that on board. Driving an online community is like herding cats and people choose when and where their prioritises are and pull resources, skill & time into so many different directions. I’m not saying that as an excuse, just as one of the things that pulls any maintainers attention from bugs/prs being merged or overlooked.
So what I’m saying is its a learning curve for us and we have improved (certainly in the past year), and we will continue to improve with each passing release (open discussions, more community merges, events, joint community projects, bug fixing releases) and we hope that you continue to be part of that journey of growing our open source community. Feel free to message if you want to speak about things directly we’re all ears ([email protected])

[mdinat3]

I didn't know i needed to have source files, i explained im a totally noob and the other person helped me out with updating stuff on git. I thought the code should be efficient enough for the fix.

[samus-aran]

@mdinat3 totally understandable, and that is a failing on our part not to be more proactive with helping other understand why PRs don't get merged as quickly as others. Are you able to help test/assess the PR that is open ? #5456 ? That would be grand.

[mrbarletta]

I don't want to minimize the progress you guys have made improving the community, it has improved a lot indeed since the early days.

Every OSS maintainer knows how hard is to maintain it and keep people motivated, let along a project this size and complexity.

What I am trying to say is that the OSS community focus that you see in other projects ain't here quite yet.

But from my view, this project resembles the dual-licensed OSS project out there that only company members are involved in the project decision making/write access to the repo, etc.

1482 stars and a single committer(d-brown) for the past week ain't fair for a software like this, it deserves a lot more.

Hopefully, your new on-demand platform attracts more devs around here and you can leverage that to further improve the community/project.

[mdinat3]

like i said i have no idea :-). What do i need to do here?

[Dillon-Brown]

Hi @mdinat3, nothing more will need done. This will be fixed in the next 7.11.x and 7.8.x LTS release. Thanks!