Sharepoint 2010 different masterpage for normal user and admin user - sharepoint

How do you make Sharepoint 2010 use a custom master page for a set of users and use another custom master page for another set of users?
Basically I am trying to show a branded cutdown version of Sharepoint to one set of user and present the full admin interface to the admins.
Thanks :)

This will not be possible. There is one Master Page associated with a SPWeb (SPWeb.MasterUrl).
Your only possibility to have different "master pages" for different types of user is to use security trimming. You will have to use WebParts and other security trimmed stuff to show different content for admins/normal users.

there is a solution for this. Usually we create two different master pages to manage this. One master page for administrators containing all staff that is usable for administratos like Ribbon for example.
Other version is only fp anonymous users where HTML generated is clean and no extra SharePoint staff generated for end user. This reduces traffic and time load of page for anonymous users.
This is very useful article how it can be done. We have implemented in the same way and work well.
hope it helps you,
Andrew

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/

Suggestions on creating document library for infopath with departmental hierarchy?

I have one main site with many subsites. Each subsite is basically a department within the organization. I have a time card infopath form (with workflow) that everyone in the organization needs to fill out. However, I want keep the form so that each department can only see within their own unit. I know I can create a form library within each subsite, but that would make it a maintenance nightmare. I just want to create the form under the main site and create links within each subsite. When a user click on the link, it will take them to the central repository but I filter by the department or permissions? I believe you can set some sort of permission that each department can view their own? user roles for the form?
Can someone point me to the right path?
Thanks,
Environment: SP2010,Sql server 2008, Office 2010
After searching and searching,
One option if security is not a concern is just to use a custom view with filtering by Department and created by = [Me] or just simply by Department.
or if security is a concern:
technet q/a

Best way to create Sharepoint forms using Designer 2007 / WSS 3.0

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.

Mysites like page that lists all doc libraries across all SharePoint sites?

We'd like to create a web page that will list all Document libraries across all sharePoint Sites for the user currently accessing the page. We'd also like to offer a all site search for the user. That is all sites they have access to.
We currently do not have Mysites enabled, nor do we want to.
Possilbe to code this?
All site search is easy. If you are using the non-free version of SharePoint 2007 or 2010, then that capability is baked into the product. Users can use the search scopes to search across all content in the SharePoint farm. It will automatically trim search results that users don't have access to.
As for you list of all document libraries, this would probably be too much effort to generate in real time for any non-trivial SharePoint environment. You are most likely going to have to gather this information ahead of time and then display the appropriate summary of the data in a WebPart of some other similar interface. Code to crawl every web application and every site and every sub-site and then every Document Library isn't hard. Actually it is very straightforward. What will be a little tricky is that you will need to collect ACL entries for each of these lists so that you can compare them to the current end user. The real trick is that the ACLs might contain SharePoint Group names and Active Directory group names instead of individual end user names. That will make your reporting task more difficult.

Sharepoint custom personalization

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.

Resources