0

I have a sharepoint list with a group of users who have permission to view. I would like to: have different permissions against specific columns within the list for example all users can read/write against column 1 only a subset of users can have read/write against column 2 however all users can view/read Is this possible and if so how please?

The reason is that we have baselined certain requirements in the list but still need to allow updates in other columns for the particular item. For example the 'description' column for each item cannot be changed without strict controls but the ability to change the 'update' column for the item should be available for all users.

2

Out of the box, SharePoint does not support permissions at column level.

SharePoint supports access control to the item (or document) level. Access policies can be scoped at the folder, list (library) and site levels. Related security policies are configured at the site collection level (Site Collection Administrators membership and permission levels) and at the Web application level (User Access Policy).

But once a user has access to an item or document, it is not possible to restrict their access at a column level. The permission the user has to the item (view, edit, delete, create) is the permission the user has to all columns in the item.

Microsoft product group members have said, repeatedly and in all kinds of forums, that column-level security is not supported and, when asked about future versions of SharePoint, have said (in effect) “over our dead bodies.”

The issue seems to be performance. Column-level security would put such a burden on every activity that SharePoint and (more specifically) SQL would not be able to scale in the near-infinite manner that Microsoft requires in order to support a feature.

That doesn’t mean it’s not possible to achieve—just not out of the box. And before we talk about some approaches, always keep in mind the underlying issue is performance.

If Microsoft hasn’t been able to architect it in a way that’s scalable (near infinite-ly), it’s unlikely that anyone else can, either.

So whatever approach you take or solution you buy, it’s critical that you test the solution against anticipated projected workloads to ensure that the impact on performance is understood and acceptable.

Three Approaches to Securing SharePoint at the Column Level

One approach to securing column data is a security-by-obscurity approach. In other words, you make it more difficult to access the column in unwanted ways, without actually enforcing column level security.

This can be achieved using conditional formatting (created with SharePoint Designer or InfoPath, for example), that “hides” columns you don’t want a user to see, or control properties (created with InfoPath, for example) that specify a control is read-only, or hidden entirely. Building this logic into views and forms can be tricky, to say the least, but people have found some success pursuing this path.

A second approach involves leveraging the new “related lists” feature of SharePoint 2010, which allows you to “project” a field from a child list into the parent list. For example, an “orders” list, in which you select a customer, can display address and telephone information from the customer list. Those fields are, by nature, read-only in the order list.

Taking that approach to the next level brings us to my favored “easy” approach: connected web parts.

Imagine this scenario: You want to track Employee contact information, but you want social security numbers, salary, and other important private data to be available only to the Human Resources department.

Instead of putting all the data in a single list—and then having to try to “hide” columns—put the data in two separate lists, linked by a common field (e.g. Employee ID).

In views, display both lists, in two separate web parts. Visualize a web part on top where you select an employee and see their publicly-visible properties.

The web part below shows the data from the “Employee HR Data” list, which contains the more sensitive information. The web part on top is connected to the web part below, based on the Employee ID field.

When an employee is selected on top, the view below filters to show only the selected employee’s sensitive information.

Now here’s the cool part. If you aren’t in the HR department, and therefore don’t have access to the “Employee HR Data” list, you simply won’t see anything in the web part.

By separating data into lists based on common security requirements, then “stitching together” information in views and forms from the related lists, SharePoint can continue to enforce security at the list level but the effect is that you’ve secured specific metadata about a single item (employee).

The third option is to write custom code that enforces custom business logic for data access.

There are third-party solutions out there that address column-level security scenarios. Most (or all) of them use one of these approaches: conditional formatting, custom content controls or forms, related lists, or “middle man” injection into the content access processes of SharePoint.

Why Microsoft Doesn't Provide Column-Level Security in SharePoint

Again, none of these approaches are “evil” per se, but remember that Microsoft isn’t providing column-level security for a reason: performance. Make sure that you test any approaches against your workloads and content, to be sure that the impact on performance is understood and acceptable

Source: http://sharepointpromag.com/blog/3-approaches-restricting-access-sharepoint-columns-and-metadata

2

You can try 3rd party solutions from Virtosoftware (List Form Extender) or from Kwizcom (Column/Field Permissions)

0

The New and Edit forms of a list are distinct, so a viable approach to the problem you describe is to hide certain fields (such as the "Update" field in your example) from the New Item form, while hiding other fields (such as the "Description" field in your example) from the Edit Item form.

This can be achieved a variety of ways, depending upon your environment, resources, and level of access.

You can customize the forms via InfoPath or SharePoint Designer, or add CSS/JavaScript to the forms to hide or disable the desired fields.

If you have programmatic access to the SharePoint environment (Powershell or .NET code) you can access the SPField object for each field you'd like to show/hide and set the ShowInNewForm and ShowInEditForm properties.

0

SharePoint doesn't support list field/column permissions natively. Others on this post have mentioned several options to get around that limitation. Another is a 3rd party product such as the SharePoint Column/View Permissions created by BoostSolutions.

0

Here is the solution for Sharepoint 2010 :

SharePoint Column & View Permission

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.