[Vtigercrm-developers] calendars don't follow role permissions

Alex Hall ahall at autodist.com
Mon Apr 23 16:14:39 GMT 2018


Reports are already set up to not show non-subordinate events. The problem
we had was with the shared calendar view, which shows all events regardless
of ACL.

On Fri, Apr 20, 2018 at 6:25 AM, nilay khatri <nilay.spartan at gmail.com>
wrote:

> What about reports ?
>
> On Fri, Apr 20, 2018 at 3:33 PM, Alex Hall <ahall at autodist.com> wrote:
>
>> The other IT guy here came up with an idea. We made the calendar display
>> models get the subordinates of the current user, then only show the events
>> belonging to the users in that subordinates list. So far, this has worked.
>>
>> On Apr 19, 2018, at 11:16, nilay khatri <nilay.spartan at gmail.com> wrote:
>>
>> Hi Alex,
>>
>> were you able to figure out a solution for this?
>>
>>
>>
>> On Wed, Apr 4, 2018 at 8:07 PM, Alex Hall <ahall at autodist.com> wrote:
>>
>>> Hi all,
>>> One major bug we've run into is calendars. We have users set to sync VT
>>> with Google calendars, but the views don't follow the rules. With
>>> organizations, contacts, and all other modules, managers can see sales
>>> reps' data, but reps can't see other reps' data. This is how it should be,
>>> so our roles are working.
>>>
>>> However, calendars don't follow this at all. If events are public, all
>>> reps can see events from all other reps, despite the roles not allowing for
>>> it. If events are private, managers can't see those events for their reps
>>> like they need to be able to.
>>>
>>> I've looked into this, and found only one suggested fix. It failed, and
>>> is for V6 anyway. Since then, the other IT guy and I have been tracing
>>> through VT's source, trying to add things to make it work how we want.
>>> We're thinking of getting all subordinate users for the current user, then
>>> adding each as an OR in the query that gets the events. This fails because
>>> the addCondition call inserts the user ID, but not the string, such as
>>> 'current_user_id'. Thus, our query ends up with "and = 1" instead of "and
>>> current_user_id = 1".
>>>
>>> I have no idea if this is even the right way to do it, and I haven't yet
>>> worked out how to get the string in the query. I'll also need to include
>>> all subordinate IDs in a big parenthesized group, since each is separated
>>> by OR, but I can't get groups in queryGenerator.php to work how I thought
>>> they would.
>>>
>>> Does anyone have any suggestions for how this is supposed to work? What
>>> could I do to make events behave how every other module does? Is this
>>> problem by design, or a very long-standing bug? If I'm on the right track
>>> with the fix, why would queryGenerator->addCondition fail to add the string
>>> I pass in as the first parameter? Thanks for any help or suggestions.
>>>
>>> --
>>> Alex Hall
>>> Automatic Distributors, IT department
>>> ahall at autodist.com
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
> _______________________________________________
> http://www.vtiger.com/
>



-- 
Alex Hall
Automatic Distributors, IT department
ahall at autodist.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20180423/ce8280e4/attachment-0001.html>


More information about the vtigercrm-developers mailing list