nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

permission not working

khyati

I added one user to the groupA and this groupA is added to the groupB and editor access is given on a branch to this groupB.

When this user is trying to access the DCRs and edit, edit button is disabled.

I checked the permissions on windows server and they look to be appropriate.

What may be causing this problem ?

Regards

Find more posts tagged with

Comments

Pawan

Can you verify from TS GUI whether the permissions are inherited down the branch to the workareas?
When you say global and local group what do you mean by that?

Migrateduser

Check the work area permissions. I guess the user has to be the owner or member of the workarea group inorder to edit content within a workarea. Just granting role at the branch level is not sufficient.

khyati

All the users are added to one groupA, that group is added to groupB and permissions are granted on groupB.

I can see that permisions are in inherited.

Owner of the workarea is administrator and groupB has full control permission in the workarea. Other users of the group dont have problem.

Migrateduser

All the users are added to one groupA, that group is added to groupB and permissions are granted on groupB.

I can see that permisions are in inherited.

Owner of the workarea is administrator and groupA has full control permission in the workarea. Other users of the group dont have problem.

I guess the workarea should be owned by groupB and not groupA as groupA is a subset of groupB.

Pawan

I guess the workarea should be owned by groupB and not groupA as groupA is a subset of groupB.

If workarea is shared by groupA, how does it stop members of groupA to access the contents?

I added one user to the groupA and this groupA is added to the groupB and editor access is given on a branch to this groupB.

You say you added groupB for the branch and groupA for the workarea, is it?

khyati

nope, groupB is added at branch level and whenever permissions are to be issued, groupB is given permissions. So its always groupB when it comes to permissions. In the previous post I mentioned groupA is given permission at workarea level that was a mistake. I have corrected that mistake. Its alwas groupB and groupA uis a member of groupB. all the users are members of groupA. Sorry for the mistake.

thanks

Pawan

What is the role of the user who is unable to edit?
Though its not good way of doing, but you can try to add that user directly to the branch and workarea and see if he is able to edit. If it works, then you can remove the user and then debug more.If not, then you have to debug more Smiley Very Happy

khyati

groupB has editor role.

Migrateduser

What TS version are you using? Are these groups OS groups?

khyati

TS6.7.1 SP2

Yes, these are OS groups (windows server 2003)

thanks

khyati

TS6.7.1 SP2

Yes, these are OS groups (windows server 2003)

thanks
---------------------------------------------
I tried one more thing.

I added a new user to the already existing group in TS which has editor role.
Now when this user logs in, she does not have edit permissions on the DCRs or files. All the edit buttons are disabled.

Why is it so ?

---------------------------------------------

One user for whom all the edit buttons were disabled till today afternoon, has edit buttons enabled now.
Whats going on over here ?

Thanks

Migrateduser

I guess it won't work for OS groups as workarea is owned by groupB (which is a OS group) and when TeamSite looks at the workarea it sees groupB and will only allow members of groupB (members at OS level) to work in the workarea.

I guess you have defined groupA as member of groupB in TeamSite through administration tab, right?

What you are trying to do can be done if both groupB and groupA are non OS TS groups.

Adam Stoller

TS6.7.1 SP2

Yes, these are OS groups (windows server 2003)

thanks

OS Group nesting doesn't [always?] work as expected - especially if your more than one level deep (local group nested in domain local group nested in domain server group - or something like that)

TS Group nesting does work the way one expects.

You might try adding OS Group-A to TeamSite Group-B2 and see if that works.

khyati

Let me understand this

users are added to groupA (domain global group ?)
groupA is added to groupB (domain local group ?)
groupB is added on a branch to grant permissions
which one is domain server group ?

You suggest to add groupA to TeamSite branch or workarea directly ? and according to you it shd solve the problem ?

------------------------------------------------------------

When I do nesting of groups, permissions are not being set immediately but takes time. In the evening it was done in 2-3 hours, sometimes it takes more than that and sometimes it takes couple of days.
Is it required to update TS after changing permissions ? If yes, how to update TS after changing permissions ? (I can not use iwreset when server is in use during busines hours. Pls suggest alternate way)

This phenomenon is recent. Week before, permission would work immdiately. Would anyone know what is this due to ?

Thanks

Adam Stoller

Let me understand this

users are added to groupA (domain global group ?)
groupA is added to groupB (domain local group ?)
groupB is added on a branch to grant permissions
which one is domain server group ?

I don't know - I'm only saying that I've seen issues with nested OS groups on Windows - although there is (was?) a setting in iw.cfg that was supposed to fix some of the issues - something like domain_local_groups=yes.

You suggest to add groupA to TeamSite branch or workarea directly ? and according to you it shd solve the problem ?

No - I suggested creating a TeamSite Group B2 (to take the place of OS Group

and adding OS Group A (and OS Group B?) to the TeamSite Group B2 - and then using the TeamSite Group B2 on your branch and for assigning roles on the branch.

When I do nesting of groups, permissions are not being set immediately but takes time. In the evening it was done in 2-3 hours, sometimes it takes more than that and sometimes it takes couple of days.
Is it required to update TS after changing permissions ? If yes, how to update TS after changing permissions ? (I can not use iwreset when server is in use during busines hours. Pls suggest alternate way)

This phenomenon is recent. Week before, permission would work immdiately. Would anyone know what is this due to ?

If it takes that long before the permissions are refreshed it is probably with the network connectivity between your TeamSite server and ActiveDirectory server - or you haven't refined the list of domains that your TS server should access for information (domain_list setting within [iwserver] section of iw.cfg).

You should have no issues with running iwreset (no flags) during business hours. If you want to debug what's happening - you can add show_user_list=true to your iw.cfg and run iwreset and then check the iwtrace.log afterwards (this I do not recommend doing during business hours - and remember to remove the entry when done)