evollic
asked on
Sharepoint List View Permission Problems
The original problem is that we needed to limit certain groups from viewing all the list views from within a list. I found SPViewPermissionSettings from http://spviewpermission.codeplex.com to do the trick. It works for individuals but when you just use Active Directory Groups within the sharepoint permissions, it won’t lock down the views and lets them view all views from within a list. Here is a bit of a background on the problem:
Moss 2007 installed on Server 2008 32 bit. Took the Microsoft helpdesk template and modified it to meet my needs. Installed SPViewPermissionSetting as directed and activated. It worked out the box just fine. I was able to set the view permissions and have it work correctly, as in it would take a "viewer" and only show their default view of "my active service requests" and not allow them to even see any other views as a selection. I was just notified that "viewers" can now see all views which show info they should not see.
The only thing that has changed is that we have added a couple new views after I installed and activated SPViewPermissionSetting. After adding the new views, I am able to go to list settings, view permission settings (powered by Bewise) and set permissions on them. But it seems that after I added those views, that now none of the permission settings work.
As of right now if a "viewer" goes to the list, they can see all the views. They DON'T have the default view that is set for them (my active service requests) coming up as the default. And no matter what I change it just flat out doesn't work and assign the correct permissions on views.
I have tried the usual remedies of rebooting. I even removed the wsp completely and re-installed, re-deployed, and re-setup the permissions but it still isn't working. I have read that there is a "reset" button I can't get it to come up to do an actual reset. Does anyone have any idea what I could do to restore these view permissions?
I found this fix from their discussion site and installed the pbs plugin as described, but when I delete the properties using pbs, it DOES fix it for the individuals listed within a sharepoint group, but it won’t implement the view lockdowns for groups (active directory security groups):
http://spviewpermission.codeplex.com/WorkItem/View.aspx?WorkItemId=3880
“Hi Suchii,
like others, I have the problem that after a change to the group permissions the configured views does not work anymore. I am not a developer, but I recognized that the assignment of groups to view permissions is written to persistent web properties. Subsequent changes by users to the groups may not be intercepted by the feature. So, the properties contain invalid values after then. When you deinstall the feature it does not help because the properties are not deleted.
workarround:
Delete the properties variables with Powershell and the views will work and set the list view permissions again.
Best regard
NPO
most recent at top (show oldest at top)
npo wrote Nov 3 2009 at 7:33 AM
There is a great new solution to modifiy all sharepoint properties
http://pbs.codeplex.com
Any ideas why this is happening?
Moss 2007 installed on Server 2008 32 bit. Took the Microsoft helpdesk template and modified it to meet my needs. Installed SPViewPermissionSetting as directed and activated. It worked out the box just fine. I was able to set the view permissions and have it work correctly, as in it would take a "viewer" and only show their default view of "my active service requests" and not allow them to even see any other views as a selection. I was just notified that "viewers" can now see all views which show info they should not see.
The only thing that has changed is that we have added a couple new views after I installed and activated SPViewPermissionSetting. After adding the new views, I am able to go to list settings, view permission settings (powered by Bewise) and set permissions on them. But it seems that after I added those views, that now none of the permission settings work.
As of right now if a "viewer" goes to the list, they can see all the views. They DON'T have the default view that is set for them (my active service requests) coming up as the default. And no matter what I change it just flat out doesn't work and assign the correct permissions on views.
I have tried the usual remedies of rebooting. I even removed the wsp completely and re-installed, re-deployed, and re-setup the permissions but it still isn't working. I have read that there is a "reset" button I can't get it to come up to do an actual reset. Does anyone have any idea what I could do to restore these view permissions?
I found this fix from their discussion site and installed the pbs plugin as described, but when I delete the properties using pbs, it DOES fix it for the individuals listed within a sharepoint group, but it won’t implement the view lockdowns for groups (active directory security groups):
http://spviewpermission.codeplex.com/WorkItem/View.aspx?WorkItemId=3880
“Hi Suchii,
like others, I have the problem that after a change to the group permissions the configured views does not work anymore. I am not a developer, but I recognized that the assignment of groups to view permissions is written to persistent web properties. Subsequent changes by users to the groups may not be intercepted by the feature. So, the properties contain invalid values after then. When you deinstall the feature it does not help because the properties are not deleted.
workarround:
Delete the properties variables with Powershell and the views will work and set the list view permissions again.
Best regard
NPO
most recent at top (show oldest at top)
npo wrote Nov 3 2009 at 7:33 AM
There is a great new solution to modifiy all sharepoint properties
http://pbs.codeplex.com
Any ideas why this is happening?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
At best this solution is a kludge. Using a VIEW to "secure" a list is a bad idea. The proper solution would be to secure the items themselves, since a VIEW is really just a group/filter/etc on the data, it doesn't actually secure the content. Just my thoughts.