I am creating sharepoint custom solution that will show number of drop down in page. The drop down data is shared in may pages.
I want to persist selected values of the user such that when ever he visit that page or any other page that have same drop down, he should be able to see is saved value pre selected in drop down.
To implement this I have a number of options. Please suggest the best for SharePoint
1)Sharepoint User profiles
2)Sharepoint list
3) Cookie
4) Isolated storage?
Options 3 and 4 here are clientside. But I am looking for any other way that SharePoint provides to save user preferences/personalization information.
Which one is the correct way of doing that in SharePoint?
Thanks
One issue you should be aware of with user profiles is that they are only available for MOSS (as opposed to WSS). In WSS each site has their own User information list. If the solution you are building will need to run in both MOSS and WSS environments, you should plan accordingly.
jt
My instinct tells me to use cookies for this, if it's a fairly simple state you need to persist. This seems to be a part of the UI logic, and I wouldn't bind that to the profile storage.
Pages and web parts have personalization stores as well, but they are generally not shared between instances.
I would go with profile storage, because that's the sort of thing it's there for, although generally when you are writing custom code in SharePoint the idea of best practices kind of gets thrown out the window.
Related
I have Silverlight application set in Sharepoint webpart. The application modifies Sharepoint lists using client object model.
What I want to achieve is to provide some security for these lists. The idea is that users should be able to modify lists only by my application. Modifying by SharePoint UI shouldn’t be possible for users.
I know that something like that could be achieved using web services but my question is whether is it possible using client object model?
Thanks for any reply and sorry for my English.
Chris
The short answer is no. The user will always have a context and be allowed to edit based on that logged in context and the list permissions.
You could try other tricks such as hiding the lists and adding controls for the edit/new forms that based on a user not being part of an admin group, simply refuse to show the list information in the normal manner but allow the list information through your Silverlight application.
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.
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.
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..
I am working on a project that is replacing an old portal system (Plumtree) with sharepoint and we want to make the transition as smooth as possible.
One thing we are look at currently is taking all the gadgets (Plumtree term for WebParts) and making sure they appear in the same place on the users new MySite.
Plumtree holds this information in a simple table containing the user, page, gadget and position information. I want to find a way to automate reading this table and putting the new WebParts on the users MySite and not have to manually set it up for hundreds of users.
I'm told modifying Sharepoint tables in SQL Server directly is not a good option as it may affect our support arrangements, but if it saves doing this by hand then I would concider it.
Other options that spring to mind are creating a equivalent table and using API calls to load the WebParts the first time the user accesses their MySite.
Any better suggestions?
You are right, messing directly with databases are not supported nor recommended.
Unfortunately, there are not much ways to modify MySites, the best way I know come from the MOSS Team Blog: http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx
The way we did it was pretty much what is described in the link above (http://blogs.msdn.com/sharepoint/archive/2007/03/22/customizing-moss-2007-my-sites-within-the-enterprise.aspx).
Your best bet is probably to staple a Feature to MySite creation and have it poll the plumtree database, find the gadgets for that user, and add a 'Page Viewer' web part for each, pointing to the gadget's location. That said, you may want to reconsider blindly migrating all your plumtree gadgets into SharePoint. There may be much better 'SharePointy' ways to provide the functionality that your gadgets are currently providing.