Control what your users can access and save time, money, and frustrations. Lock down sensitive data in SugarCRM or SuiteCRM to specific groups or teams. Supports unlimited assigned users, unlimited group assignments to records, custom layouts for each group, login/sudo capabilities and much more.
#653 - Calendar module not working for users in a restrictive group
Just upgraded to 6.5.17. Nothing changed related to the permissions or roles of users. As an admin, I am able to load the calendar module just fine with no delay. Any user that has a restrictive permissions, the calendar module fails, showing that it ran out of memory. My current memory limit is 512MB, I don't think that is the issue. This was working prior to upgrading so I believe it has something to do with the new hide shared calendar setting. I have tried enabling that feature and leaving it off, same result. Users with full access can load Calendar module, users with less permissions cannot.
-
"Quite powerful, flexible and easy to use plugin. Works perfectly in SuiteCRM as well as in SugarCRM." - damien8105
Read More Reviews
- Most Recent Love from Users
kacsoristvan- damien8105
- anri
- Administrador
- Stefano1
- einkauf2
9 years ago
I looked into what the Calendar is doing and I can't see how you would be running out of memory with PHP. If there is any load it will be on the database side, but even then it should only be the same as if a non-admin went to the list view of any of those modules (meetings, calls, tasks).
If your calendar is at a stand still and needs to work right this minute then I'd advise finding a blank 6.5.17 instance and copying these 4 files into your system (reverts the calendar to work as it does without SecuritySuite installed):
-Jason
9 years ago
Thank you for the response. Unfortunately, this did not correct the problem. Is there any other files I should try to replace? I will see if i can see more in the logs, this is an odd issue.
9 years ago
Those are the only 4 files involved with any SecuritySuite - Calendar customizations. It's stock 6.5.17 functionality at that point. Any way to test it with 1024MB allocated for memory? Maybe it's just that much of a beast now.
9 years ago
Found the issue, blame lies with Sugar. In case you hear of anyone else with this issue, I located the solution here: http://www.sugaruk.co.uk/blog/sugar-6516-calendar-speed-issues. It was related to 6.5.16, but issue persists in 6.5.17.
9 years ago
Nice find! Thanks for following up with the solution.
8 years ago
Hello Jason,
we have the exact same Issue witch suitecrm taht usees the core sugarcrm 6.5.20, is there a solution for this problem?
8 years ago
we are currently using SecurityGroups - Full Edition 2.8.1
8 years ago
Looks like the link to the solution is broken. The problem is in the Calendar module, file: modules/Calendar/CalendarActivity.php on line 187.
change: ~~~ $where = self::get_occurs_until_where_clause($meeting->table_name, $meeting->rel_users_table, $view_start_time, $view_end_time, 'date_start', $view);
8 years ago
Looks like I cannot edit my comment and the previous formatting looks bad, so to clarify:
on or around line 187 in modules/Calendar/CalendarActivity.php change: $where = self::get_occurs_until_where_clause($meeting->table_name, $meeting->rel_users_table, $view_start_time, $view_end_time, 'date_start', $view); to: $where = self::get_occurs_within_where_clause($meeting->table_name, $meeting->rel_users_table, $view_start_time, $view_end_time, 'date_start', $view);
the function get_occurs_until_where_clause does not take the start date into consideration and pulls all events until the end date. So a new user will not notice this issue, it only affects users after they have entered a few hundred meetings. changing the function to get_occurs_within_where_clause uses the calendar date range reducing the number of records the form has to process.
8 years ago
Thanks for helping out!
8 years ago
Thank you very much for a quick solution
8 years ago
Did ipfsugarcrm's solution do the trick for you?
8 years ago
The solution worked perfectly, thanks again