SharePoint content targeting, is it possible to have multiple views per user? - sharepoint

Our SharePoint site has a couple of broad groups that use it. In essence they are managers and users. We have different tabs viewable to the different people.
We now have a requirement for Managers to be able to pretend for a while that they are users, and see what users would normally see.
We cannot think of a way of achieving this toggle, what we don't want is for managers to get ALL the tabs that managers and users see, but be able to switch views on demand.
It is not required that users are excluded from manager content if they can guess the url, but equally if they are excluded then that is not a big problem.
We can write code if required, we are just not sure where to start with this!
Edit: There are whole sub-sites and pages of info for both audiences, not simply content on the same page.

Put the manager content and the user content in separate divs. Create a content editor web part, and use javascript to hide the irrelevant div based on the query string. Then link to:
mypage.aspx?page=manager
This worked really well for a similar project I had.

Related

Can I restrict different portions of a Sharepoint page to different users?

I have a couple different Sharepoint pages (Sharepoint Word docs) all with roughly the same purpose and information, but for management reasons, some of it needs to be restricted from a certain set of users. We keep having to update each page in several different places any time a single change or update is made.
It'd be easier to be able to mark certain tables on a single page with specific permissions. Is that something Sharepoint can even do, though?
Providing you have an enterprise license for on-premise the best way to achieve this is by using targeted audience feature on the webparts.
You could check SecurityTrimmedControl, you could hide the content based on user permission.
https://rijsat.wordpress.com/2016/10/27/security-trimmed-control-in-sharepoint-2013/

Is it possible to pass params to actions of MODX Revolution's manager in URL?

Is it possible to pass parameters to actions of MODX Revolution's manager in a URL? If it is possible, how to do that? For example, I want to create a direct link to "System Settings" manager page and automatically open "core" namespace and "site" area.
Background:
There are some common sections on the site, which can be duplicated in several places. These sections are more like simple values, rather then blocks of code (let's say, phone numbers, address, some URLs, etc).
I know, that such functionality can be achieved with chunks, but it feels like it would be better to use custom system settings. At least, it would be great to keep end users out of site's templates, chunks, snippets, etc as long as it is possible. But it turned out that customers usually found such things pretty complicated, because it is hard to find them.
MODX Revolution allows developers to create custom widgets. Probably, it is possible to create a widget with a list of links to important areas for site administration. I successfully created an HTML widget with a link to system settings, but, unfortunately, I cannot construct a link to a specific area of them.
Probably, such things can be achieved with Custom Manager Pages, but it looks like it is very hard to create them. I have not much experience with MODX API and never worked with ExtJS.
There is a great extra for MODX Revolution called ClientConfig, that could be used for managing those special system wide settings. Bonus: the access to all system settings could be denied for users with an editor role if ClientConfig is installed.

SharePoint 2010 List disabling edit even for people with Manage permissions

this seems to be a bit of an odd requirement, but we have a separate form (not an infopath form) being filled out by people. Now, this form that we have has quite a lot of validations in it. We're currently trying to prevent people from accessing the list where this certain form is saving the data, this is so that they won't bypass the validations we created in the form that we created. Is there a way to be able to do this, one way or another?
Easy fix. Use SharePoint Designer to browse to the list, starting from "All Files". The list has several files in it. You're only interested in NewForm.aspx and EditForm.aspx.
Open these files. Either add JavaScript redirect code directly to the file (near placeholdermain) to point back to AllItems.aspx, or add a Content Query Web Part to add the redirect JavaScript code in that added web part.
Either way, when users go to add/edit items in that list, they will be bounced back to the page that list the items.
This will only work when JavaScript is enabled. Mind you, SP won't work very well with JavaScript off anyway, so people may not disable JS. But for a bullet proof solution, make a Visual Studio feature for the specific list.

Restricting Views of users on Sharepoint lists

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.

How do I implement user theme switching in SharePoint?

My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.

Resources