Is it possible in a SharePoint 2007 list (MOSS, though I don't think that this is Enterprise Edition) to allow users in one SharePoint group to edit values in some fields and users in another group to edit values in the other fields?
From all the searching I've done, this does not appear to be possible, so as a fallback I'll accept answers that suggest the best way to accomplish something like this (e.g. maintain the items in separate lists, linking them by ID).
I do not have access to Central Admin, but I do have Full Control of the site. Also, this site was not configured for custom code, so besides changing list settings (and site settings) I can make changes via SharePoint Developer (but not Visual Studio).
A big THANKS in advance!
Steve
You are correct that it's not possible to set field-level permissions without custom code. Furthermore, you're on the right track thinking separate lists, though you should be aware that SharePoint list lookups are a rather weak correlation. Usable, but not exceedingly robust.
For presenting the combined data you'll want to look at SharePoint Designer's joined subviews.
Have a look at Displaying SharePoint Fields by Permission Level by Laura Rogers. This is an approach that uses SharePoint Designer.
Also see the SPListDisplaySetting CodePlex project. This is a site collection feature that needs to be installed so may not be an option.
You can customize Edit Forms for SharePoint 2007 Lists (EditForm.aspx).
With custom list definition and custom edit form you can write code to check the user and show different fields depended on the users permissions.
'a' workaround to get this functionality is to change the content type associated with a list item using workflows.
Like so:
User creates list item in content type A (limited fields).
Workflow starts, changes to content type B (all fields).
Admin gets notified, opens listitem, fills out additional form fields.
And so on..
Related
i'm using Sharepoint 2010 and i want to create a List in a new Site, which contains Lists from the other sites.
Like a Global Overview.
Our problem is that we're using several sites with Ticketsystems. So i want to create a global list which contains all tickets from all other sites. (For sure just if they got rights to the Ticketsystem).
Is there a way to do this?
Regards
Alex
You can easily create a ticketingsystem in SP2010 with the following steps:
1. create a content type for the ticketsystem
2. add an itemreceiver to the content type
3. create a list for the ticket system
4. add contenttype binding to bind the content type to the list
5. deploy the list to the rootweb as well as all the subsites by adding the list through a webtemplate for instance
The itemreceiver you add should be an itemadding which would place a newly created ticket in the subsite also on the rootweb level. This would allow you to have all the tickets on the subsites and one allcontaining list on the rootsite level.
As far as I know there is no generic way of mixing references from another list in a new list.
You can either integrate and copy list items from your ticket systems into a "central ticket system" or create a custom control that reads from all ticket systems and displays them in the blend you like.
There is custom development in either way.
Begin by having a look at the Data View Web Part
http://office.microsoft.com/en-us/sharepoint-designer-help/display-data-from-multiple-sources-in-a-single-data-view-HA010099144.aspx
http://www.learningsharepoint.com/2010/10/16/create-dataview-webpart-in-sharepoint-2010-tutorial/
There is also the Content Query Web Part
http://msdn.microsoft.com/en-us/library/ff650512.aspx
The SPSiteDataQuery class lets you run a CAML query for all lists/libraries in a single site collection. It's pretty trivial to tie that to an SPGridView control to get a ListView-like user interface.
Internally this is what the Content Query Web Part users, so it has many of the same limitations.
Here's a reasonable example
My company is running its own server with WSS 3.0, and I am using Sharepoint Designer 2007 to make changes. I am new to the world of sharepoint (but experienced with webservers and web programming), but basically what I am trying to accomplish is this:
We are trying to automate forms that all employees must fill out (for example, our Employment Application). Since all employees have access to our sharepoint intranet, we will put it on there. It must do the following:
Display a form where users can enter their data. Once submitted, the data is stored in a database (sharepoint uses Lists for this I believe).
A user can go back to the form to edit things if need be (and their old data will be automatically loaded).
User’s should only be able to access their own form and not see everyone else’s. Only admin’s should be able to see everyone’s stuff.
What is the best way to go about accomplishing this? Can I create a standard list and modify it to suit my needs? Do I need to code some ASP forms to make this work? Is there an inexpensive web part that can do this sorta stuff?
I don’t think using Infopath is an option for me since I have wss 3.0 I would need the end user to have infopath as well, and many won’t have it, so that rules that out.
I think you want to adjust the Item Level Permissions setting of the list. (List Settings->Advanced Settings)
The form in SharePoint States:
"Item-level Permissions
Specify which items users can read and edit.
Note: Users with the Manage Lists permission can read and edit all items. Learn about managing permission settings."
There are settings for Read access and Create and Edit access:
Read access: Specify which items users are allowed to read
-Read all items
-Read items that were created by the user
Create and Edit access: Specify which items users are allowed to create and edit
-Create and edit all items
-Create items and edit items that were created by the user
-None
This sounds like you simply need a custom list, possibly with custom forms (edited with SharePoint Designer) in case the default forms aren't adequate.
I am developing a sharepoint 2010 project.
I want to restrict users view on lists based on their identity. (e.g. the branch of organization they work in, but in fact the ristrictions can be more complicated).
What solutions do you recommend?
With out of the box features this is not possible. You can go to great lengths to remove the list's view selectors and other navigational elements that let people cruise around a the schema and metadata for a list but it is not a security mechanism.
If a user has read permissions to an item, they'll have read access to all the fields of that item.
There is an outside chance that it you disabled all RPC mechanisms, SOAP, RESTful web services, Client Object Model and the office clients that you might be able to claim this as a security mechanism. If you don't there will always be a way around your "security" scheme.
This feature can't be implemented by SharePoint by now and I think neither for the next version
You can use a third part tool to achieve it, such as BoostSolutions' Column/View Permission or LightningTools' DeliverPoint
BTW, I work for BoostSolutions and I mentioned our own product because it works for your issue. Hope it helps :)
create sharepoint groups based upon your requirement or diffrent type of user base and accordingly give them rights may be item level or on complete list
and while doing these things just go through the following posts
http://blogs.gartner.com/neil_macdonald/2009/02/25/sharepoint-security-best-practices/
http://weblogs.asp.net/erobillard/archive/2008/09/11/sharepoint-security-hard-limits-and-recommended-practices.aspx
Not 100% sure on SharePoint 2010, but definitley for SharePoint 2007, there is not a way to do this, especially if the views are corresponding to security requirements on the columns users are able to see.
One way to work around this is have the list be not accessible by users, and then have code logic allow for access to the data creating the different "views" on the data in something like a Web Part. The downsides to this is search becomes an issue (since the data is hidden) and having multiple "views" of the data (if necessary) is also another item to work through.
I know its a very old question but posting it as it might help someone.
There is an work around to do it as described here
I find it easier, if possible, to create the view and lock it with the filters on the list settings page.
For example, I have a list of employees that includes their employee IDs. I use that list on other pages to gather data in other webparts. So I filter the employee list to [ME]. So the data is available to the page needing it to filter others and they cannot see anything else.
Now, what about the person who needs to manage that page? I create a view, call it HR. That view can see everything. Then I export that webpart with that list view on it through the designer. I then delete the HR view from the employee list.
This leaves no way for anyone to switch views and see everything again. I create a webpart page for the person who manages it, and I upload that webpart and set the view of the webpart to HR. In the end, I have a page that I lock down instead of trying to lock down views or list permissions separately.
Would you be able to have two lists that are joined. One that all users have access to and another that only certain people have access to, and then join them? Then maybe the people that don't have access to the other table it doesn't pull the information? Not sure, but I'll try that out later today.
In SharePoint 2010, what are the best practices for trimming content on a single page based on group? For example, I have two types of customers that each belong to a different group. I only want customer 1 to see their content (links, text, etc), and I only want group 2 to see their content. I could put this content on separate pages, but some customers will belong to both groups, and it makes sense to display all of this info on the same page.
Depends how much of an issue Security is.
You could use Audiences to restrict content displayed with the Content Query Web Part - but this is not a security restriction.
Another option is to store the content is separate lists, with permissions restrictions on the lists, and surface the information through CQWPs, standard List Views or XsltListViewWebParts.
However back in SharePoint 2010 Beta an error was thrown if there was a web part pointing to a list you didn't have access to now, but I'm not sure if that was fixed as a bug or if it remains as a feature.
I think this page will provide the answer you're looking for, so long as you can use SharePoint designer:
https://www.nothingbutsharepoint.com/sites/eusp/pages/jquery-to-the-rescue-displayinghiding-content-based-on-user-permissions-or-when-edit-items-permissions-dont-work.aspx
I have created a webpart annual results.This should be available only to managers and not for developers in the home page.How to achieve it?
If you're using MOSS then you can use audience targeting, but be aware that this should only be used as a way to help people notice what's important to them not as a mean of authorizing what they can see.
If you're using WSS then you'll have to write code in the webpart to achive the same functionallity
Per Jakobsen is right, however that is still "security by obscurity". If the data is being pulled from a SharePoint list then consider security that list or the list items within that list, your users who don't have rights will still see the web part but they won't see any data.