[Vtigercrm-developers] V6 - sharing access bug?

[Mani Kumar]

As of my understanding on your problem these are my views on how system
should work.

*Scenario: *

    Notation: U ≡ User;   G ≡ Group

   - U1 ∈ G1, U2 ∈ G2
   - G2 ⊂ G1
   - In Sharing access you made organizations module as a private. which
   means any user can access his own records and his subordinates' (Users
   under him. Not at same level).

In this case U1 can access records assigned to

   - Own records
   - Group G1
   - Users under him (No need to be in same group)

And U2 can access records assigned to

   - Own records
   - Groups G1,G2
   - Users under him (No need to be in same group)

Now the question:

Can U1 Access the records of U2 ?

It depends on sharing access. U2 < U1 then he can. The same thing will
happen in case of U2.

If System is not acting above it is a bug.

Any one can correct me if any point wrong.

ThankYou



Regards,
Mani
Vtiger Team <http://www.vtiger.com>


On Wed, Mar 5, 2014 at 2:57 PM, Siam Translations LLP <
info at siam-translations.com> wrote:

> Waiting for contribution in this thread I tested another configuration of
> groups and sharing privileges.
> To reproduce my steps see below:
>
> 1. Created group G1
> 2. In sharing rules made organizations module as a private
> 3. Assigned few organizations to the group G1
> 4. Created group named G2 where I assigned user named USER1
> 5. Get to the group G1 and insert G2 as a member of G1
>
> Result is that USER1 can not see records assigned to G1. Could you guys
> please tell me if this is OK? Is this the way the groups working?
> Previously Uma says it is ok that visibility is out of control (read
> thread)  now here is no access to records :-) I will appreciate any comment
> eventually confirmation that it working somewhere else differently.
>
> Regards
> Andrew Smith
>
>
>
> On Tue, Mar 4, 2014 at 2:31 PM, Siam Translations LLP <
> info at siam-translations.com> wrote:
>
>> In my opinion it going too deep. visibility suppose to be limited to
>> group only not group and user. If this is not bug it is incorrect design
>> than.
>> What if user belonging to more groups? Why member of one group should see
>> documents of other group created by particular user?
>> On the other word: it like I am an employee of vTiger team, but my wife
>> not - doesn't it?
>> Group vTiger and Group Family should be separated or not?
>> I allow that I am wrong of course therefore I would like to ask forum
>> guys to issue own opinion.
>>
>> Regards
>> Andrew Smith
>>
>>
>>
>>
>>
>> On 2014-03-04 14:16, Uma S wrote:
>>
>>> Hi,
>>>
>>> This is not a bug. As you explained even-though documents module is
>>> private, We have custom sharing rule saying documents assigned to
>>> Group B can be accessed by Group A Read only. As User 1 is part of
>>> Group A and User 2 is part of Group B. If User 1 logged in, He can see
>>> all records assigned to Group B and User 2.
>>>
>>> On Sun, Mar 2, 2014 at 7:56 AM, Siam Translations LLP
>>> <info at siam-translations.com> wrote:
>>>
>>>  State:
>>>>
>>>> Group A - User 1
>>>> Group B - User 2
>>>> Documents module - private
>>>> Sharing Rule - Documents of Group B can be accessed by Group A Read
>>>> Only.
>>>> All users having Subordinate Role on the same level
>>>>
>>>> Bug:
>>>>
>>>> Logged User 1 can see all documents assigned to Group B AND to User
>>>> 2
>>>> Visibility in line with sharing rules should be limited only to
>>>> documents assigned to Group B
>>>> or I am missing something?
>>>>
>>>> Regards
>>>> Andrew Smith
>>>>
>>>> _______________________________________________
>>>> http://www.vtiger.com/ [1]
>>>>
>>>
>>> --
>>>
>>> With
>>> Best Regards
>>> Uma.S
>>>
>>> Vtiger Team
>>>
>>> Links:
>>> ------
>>> [1] http://www.vtiger.com/
>>>
>>> _______________________________________________
>>> http://www.vtiger.com/
>>>
>>
>>
>
> _______________________________________________
> http://www.vtiger.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140306/d4fb8554/attachment-0001.html>