This is puzzling me for awhile.
I am developing a SharePoint MOSS 2007 site.
I have one set of accounts, who have no issues accessing the site and using correct master page.
When I use the second set of Windows user accounts, they use completely different master page for unknown to me reason.
There is no logical separation between those groups, meaning that 1 account from 1 department may behave correctly, and another account form the same department, who should have the same privileges, references a different master page.
When I try to programmatically see what the master page is, it displays the same standard default path as for other users, "_catalogs/masterpage/default.master".
The strange thing is that it seems that this different master page is really the same, but the older version of it.
Did anyone experienced the same issue?
How do I fix this?
How do I find out what the second master page really is?
Thanks in advance.
Have you checked in and also approved the master pager after editing it, so that the new version is available for everyone?
Related
modern sites on my site collection do not have a working edit button. The issue is inconsistent, Previously it was working but from last couple of days Edit button is not showing.
I have full control over the entire collection, so permissions shouldn't be the issue.
I tried multiple browsers, windows clearing the browser cache, and have determined that it's universally affecting all users regardless of browser.
Tried to add "?ToolPaneView=2&Mode=Edit" to the url to check whether they could be edited still it's not working.
I can confirm that these sites were editable a couple of days ago, After, Did R&D on that
i came across to know that i need to install latest Sharepoint updates.
So i updated kb5002135 to kb5002180 though it is not visible.
Run the SharePoint configuration wizard but still same issue.
Before : enter image description here
After : enter image description here
I had exactly the same symptoms as described, and none of the suggestions identified in question worked for me either.
We do now have a solution.
KB5002206 & KB5002207, released in May 2022, did solve our problem and the Edit Button returned across all of our browsers and environments.
In all cases it was necessary to use ctrl-F5 to force a refresh of the cache in the Browser.
WHen I make any modifications in seattle.master, I see that all the authenticated users are able to see the changes. However, when I am an anonymous user, I do not see any changes, it seems like seattle.master is never used for anonymous users. The problem is I could not find which master page is used for anonymous users. I even tried to modify all the master pages in SP Designer 2013 one by one (Yea brute force:)), but nothing changed. Is there anyone that can give me a clue about this?
Thanks.
SharePoint 2013 is used.
I directed to the master page gallery myweb/_layouts/15/start.aspx#/_catalogs/masterpage/Forms/allitems.aspx, then I checked out seattle.master, then immediately checked in. While checking in, I selected v3.0(publish). The problem is solved like that. Thanks #Serv for helping me to get the solution.
Our users have access to certain subsites, and they can add the address of these subsites in Harmon.ie and navigate inside. Also, all checkboxes "Hide subsites with limited or no access" are unchecked. Therefore, we would expect that when adding the address of the "higher level" site in Harmon.ie, that we would visualise the names of the subsites below: but we don't. What can it be?
Please read carefully our KB at http://harmon.ie/KB/sharepointrequirements Browsing subsites, it details the needed permission when working through web services like Harmon.ie.
If it does not help please re-do the security, but for on individual (for the concerned users), check whether one of the permissions didn't have the Browse Directories enabled.
We have, however, seen few situations in the past, where despite all the proper settings, such as ‘Browse Directories’, people were unable to see sub-sites or directories. Unfortunately, we were never able to reproduce such a situation inside our Labs to properly analyze that. We believe that it may be related to precedence of security settings applied to SharePoint user account. For instance, if there is a ‘Read’ and ‘Manage’ access levels – it may be that one of those has ‘Browse Directory’ while the other one doesn’t.
In the few situations that we have come across where similar issue occurred – it was resolved some times by remove the ‘Browse Directories’ setting and then applying it again.
---- Jean
I have two reports that I need to build. One that has a dozen or so columns. The other has the same columns + 2 extra. The first one is aimed at employees the second with the additional columns is aimed at Sr. Management.
I have a windows group set up for the proper Sr. Mgt users.
I am using SQL 2012.
I've done some SSRS stuff, but not enough to say I'm competent to do more difficult reports.
The problem I'm having is that we do not want the employees to see the sensitive information in those two columns. Frankly, we don't even want them to know the existence of a different report.
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Option 2: I was thinking that I can use the UserID condition to hide the columns in the report and just create one report that differs depending on who was viewing. There are two issues that surfaced in my research. First, there is no facility for using Windows Groups instead of userid. That would mean I have to maintain the list of people inside the report and boy would that be a pain. And second, my understanding is that the export facility does not respect the column actions -- like hiding.
Am I making this too complicated? Is there an easier way to do this? With no other solution, so I need to put up another instance of SSRS for management and make them go back and forth?
Thanks for your time
Option1: You should not be able to 'browse' for folders unless the 'parent' level permission has an 'everyone' user set up to browse on the higher level. Set up a test account and RDP to a box you can use the test account on. Generally under 'Folder Settings' you set up permission and it cascades down until interupted. If you have a parent permission to browse and a lower one not to, they may be able to browse directories. You can ensure that the directory has ONLY dedicated users and the inherited settings are removed manually.
Option2: I would NOT do this. You will have a maintenance nightmare on your hands as you would have to determine in code who was what and update a list that would probably need to be updated somewhere in SQL or a service. As far as I know SSRS does not work with getting parameters and such directly from AD so you would have to code this time and again. For this reason and security context I would avoid this.
Option3: Set up a 'Subscription' to save the report to a file format(excel, pdf, word, etc) or email on a scedule and turn off permission for everyone but admins. If someone can still see the report or directory there is most likely a security context issue.
Option4: You can do a cheapy 'Hide in tile view' move that for most users will hide the directory unless they go to the URL directly and have access. Click on a folder then choose 'Folder Settings' then check 'hide in tile view' and hit okay. Directory is now gone for most part for regular users browsing in default mode.
I think we can just fix your problem, and avoid inventing a complicated and unnecessary solution:
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Chances are that either you set up the security settings wrong, or there's a bigger configuration nightmare to worry about. What you should do is create the folder, go into the settings of the folder, and edit the security (thus breaking inheritance from the parent folder). Before even adding groups, you need to remove anyone that doesn't belong - namely entries like "YOU\Domain Users" - that gives access to anyone on your domain. Once you've cleaned out whomever shouldn't have access, you can add the users/groups that should. Problem solved.
Now, if that doesn't work, then it would seem to me that your SSRS instance is somehow granting everyone sysadmin access - check the Site Settings to see what users and groups are in the System Administrator role. Investigate any groups thoroughly - is BUILTIN\Administrators a sysadmin in SSRS? Check the group locally on the computer - is there another blanket domain group shown there?
If everyone on your domain has complete access to the SSRS instance, then your goal of "hiding" things is impossible.
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