Tasks appearing in wrong time in calendar module

SuiteCRM Forum - English Language SuiteCRM General Discussion
1

Hello!

We are running 7.8.7. When I create a new task, starting, let’s say, at 9 a.m., ending 11 a.m. and save it, when I open the Calendar module, the task is graphically shown as starting at 11 a.m, ending at 1 p.m… It happens with calls as well. Nonetheless, when I create a meeting, it appears perfect!

Is it the expected behavior? I expect the task being shown as a rectangle starting at 9, ending at 11, not starting at 11, ending at 1 p.m.

I have discarded any time zone issue as long as meeting are working the expected way.

Any tips?

Regs

Wilson

2

Hi. Can you try and reproduce this on the online demo?

demo.suiteondemand.com

That way we can know if the problem is only in your system, or not.

3

Hola, tengo el mismo problema, como se ha resuelto??? mi version es 7.11.10

4

I have the same problem in all my installations.
I have a clean LTS 7.10.25 installation, a 7.11.10 with greek language and various others, but the problem seems to be everywhere.

Screenshot from 2020-05-26 17-25-32
Screenshot from 2020-05-26 17-25-321074×600 17.1 KB

it seems something is miscalculated.

5

Check your server time on your PHP timezone.

Please let us know if it helps,

BrozTechnologies

6

I did it and everything is ok. My time-zone is set as it should (Europe/Athens) and the time is correct.

The problem is, as you can see in the screenshot above, that the bar has to begin at Tuesday 26 and END at Friday 29. That’s how the task is registered - see the dates above the light-grey bar, under “Test Task”.
But the task BEGINS after the ending time…

7

Trying to find a solution, I checked the modules/Calendar/CalendarActivity.php. There I checked the values of CalendarActivityObject ($this) and found all information is correct.

So, the problem has to be in the script which makes the depiction of the bars.

I am going to find it, but any help will be appreciated. Do you know where is this located?

9

It seems that was changed in order to fix this:

The change is here

I don’t suppose we shouldn’t just be changing it back - maybe there’s a better way forward, solving both the current issue you’re getting and the Issue on Gituhb mentioned above.

10

I can maybe help fixing it if you point me to what exactly is the expected behavior.

11

I am afraid I don’t know…

I know that due_date vs start_date is a particularly tricky issue with SuiteCRM, because of the aggregating subpanel called “activities”, which uses dates from several modules and tries to make sense of them. There have been several bugs and regressions with these fields in that subpanel.

But I am not sure what is supposed to be going on in the calendar.

This thread has some info about the fullCalendar options to make things draggable:

12

As I couldn’t find how the view is created (I didn’t have the time to reverse engineer the Calendar View logic), I did a hacky trick.

As the database and bean data are preserved, I think there’s no problem with it.

Firstly, I commented line 113 at CalendarUtils.php file where for some reason the “start field” is equaled to “date_due”.

if ($bean->object_name == ‘Task’) {
// $start_field = $end_field = “date_due”;
}

Then, I changed line 57 in Calendar.php as follows

“Tasks” => array(“showCompleted” => true,“start” => “date_start”, “end” => “date_due”),

and finally (that’s the very hacky part) I bypassed the task data by adding the following code at line 261 in CalendarDisplay.php:

         foreach ($this->cal->items[1] as &$item)   {

            if ($item['type'] == 'task') {
                $duration = (intval($item['duration_hours'] * 3600) + intval($item['duration_minutes']) * 60);
                $start = intval($item['ts_start']) - $duration;
                $stop = intval($item['ts_end']) - $duration;
                $item['ts_start'] = strval($start);
                $item['date_start'] = strval($start);
                $item['timestamp'] = strval($start);
                $item['ts_end'] = strval($stop);
            }
        }

I admit is a dirty and bad way of fixing it, but in my defense, it seemed hacked all the way around.

1 Like
13

Cool.

Remember to check if your change has any impact on the Activities subpanels, or on Dashlets showing activities or tasks.

14

There’s no visible problems until now.

I will report here if something goes wrong.

15

I checked the problem mentioned above, about the fatal error when there’s no due date in a task. Yes, its still happening.

It is easily fixed when you add an additional check in CalendarActivity.php
to update $this->sugar_bean->date_due with a time after $this->sugar_bean->date_start.

I will post the fix as soon as I find where the hell is the function that gets user time format… :slight_smile:

16

Perhaps this one

17

Thanks for the info! $timedate->get_date_time_format() is what I was searching for.

I took the liberty to set 1 day for the default duration of a Task which has only start date.

The patch which fixes the Calendar and allows Tasks to process normally even without due dates, is the following: File /modules/Calendar/CalendarActivity.php line 80:

//Add this to allow Task process normally if due date is not present
if(empty($this->sugar_bean->date_due) && !empty($this->sugar_bean->date_start)){
$timeObject = DateTime::createFromFormat($timedate->get_date_time_format(), $this->sugar_bean->date_start);
$timeObject->add(new DateInterval(‘P1D’));
$this->sugar_bean->date_due = $timeObject->format($timedate->get_date_time_format());
}
// End addition

18

Do you want to make a PR for that, so that the code goes into core SuteCRM?

19

How is this done? Is there any guidelines?

20

And if that sounds very complicated, don’t be shy, just go ahead and start something, there is a generic good-will towards people who are newbies in git, github, etc, because we’ve all been there, and these things have a learning curve.

And because it’s more important to have good development and problem solving skills, the rest one learns later. Thanks for contributing!