I made a custom page and added it to a MOSS 2007 site.
the custom page has an update panel and some ajax controls
when I'm logged in as an administrator with full control permissions, the page works fine.
but if another user with even Full control permission logs in and browse the page, an error appears:
The control with ID 'UpdatePanel2' requires a ScriptManager on the page. The ScriptManager must appear before any controls that need it.
where UpdatePanel2 id the id of the update panel in the page, and the strange thing is that the master page of the site has a script manager addded to it.
so what can be the reason of this ?
thanks
This is one of the Common Behaviour when you dont approve the changes of the MasterPage after chaning the master page through SharePoint designer. To resolve this problem make sure that you have approved the changes of the MasterPage you did. Usually admin has fullpermission to view the unapproved changes as well, while normal users dont.
Related
I have a SharePoint site where I am the admin and I have full control permission. One of the users created a link on the navigation menu, but I cannot edit it or delete it. The user is no longer on the site. I checked the permission again, and it shows I have full control.
How do I modify or delete the link and its page?
I tried giving myself more permission, but that did not help. I thought full control covers everything.
On the edit mode, some links are editable, but the one I need to remove doesn't give me that option.
If it is a link to a list/library, it might not be permissions related. Check the List/Library Settings, "Name, Description and Navigation" option:
I have just edited my publishing site home page in SharePoint Designer. The page originally contains some web parts.
I am a newbie as far as SharePoint branding is concerned. I did the editing in Advance Mode when I realized that I couldn't edit areas outside my Web Part Zones and since I need to do that, I tried it using the advance mode. I edited the page adding some inline CSS styling and even added some additional Web Part Zones. Everything looked good when I previewed so I saved and thought all was okay. But to my surprise, Only my account (System Account) can see the changes I made. Every other user on the domain are still see the original page without any of my recent changes.
I have done the Check-In and Publish circle over and over again but no luck.
Does any one have any idea as to what I might have done wrong here and what I can do to fix the issue.
Follow below steps for publishing:
Select “Publish a major version,”. When
prompted to approve the master page, click Yes. This automatically
invokes a SharePoint master page approval page, where you
will find your new master page listed at the top of the page.
Click the drop-down menu beside the master page. Select
Approve and select the Approved radio button. Click OK. Your
master page is now saved and approved in SharePoint.
Navigate to your top-level site collection, and click Site Actions -> Site Settings
Under Look and Feel, select the Master Pages link. For both the
Site and System Master Page settings, select your new master
page from the drop-down menu.
Once you click OK, your changes should be available to all users
I have two features that add CustomAction to the SiteSettings page. One feature is at the Site level and the other is at Web level.
The CustomAction that is being added at the Site level is a link to the custom configuration page that manipulates Site level settings for my application. Therefore, I don't want the link displayed for the SiteSettings page of a subsite. I know there is a setting (RequireSiteAdministrator) that hides the page according to access level, but I would still like to have this page show up for Site owners at the top/root level site settings page and not in the sub site level setting page.
There is a RootWebOnly attribute for the CustomAction xml node which would solve my problem. The problem with this attribute is that it only available for SandBoxed solutions.
I know that this is possible, since I see the behavior for the Site collection administrators link in the Users and Permissions section of the Site Settings page. Please notice that if you go to the top/root level settings page, you will see this link. On the other hand, if you navigate to the Site Settings page of a subsite, the link is no longer there.
I have tried using HideCustomAction, but this hides the link on both pages.
After battling with this for two day, I had an ah moment that I thought I would share. This will allow you to place a custom action that will show only at the root web level.
Create 2 features. One at the site level (siteFeature) and one at the web level (webFeature).
Make the web feature hidden so that it can't be accessed (activate/deactivate) though manage features page.
Put the custom actions element xml in the web feature.
In the activation event receiver of the site feature, activate the web feature.
UnfortunlyUnfortunately this is not possible with custom actions and custom group.
All you can do is just to set up permissions on the link that will be shown only to SiteCollection Administrator
Example how it will be is "Site Collection Administation" group where links are hidden when you are not on the top site level and shown when you are.
Hope it helps,
Andrew
I have a test user account, who is in the group "Members" with the default permission level of "Contribute". I created two custom aspx pages in Visual Studio, that are stored in the _layouts directory. How is it possible that this user account can view one of those pages, but not the other? One page has a single button on it and the other has a gridview, displaying list items. He can view the page with the gridview, but not the page with a single button. Anyone has an idea why?
Oh, and he is also prohibited from viewing a custom web-part written in Visual Studio, for some reason.
Ok based on your comments it sounds like you are probably accessing either the Group itself and the current user doesn't have access to view the members of the group. Note it may also be something else in your code behind that the current user doesn't have permission to do. Typically the access denied page happens without an exception so you'll have to look at the SharePoint ULS logs for more information on the error. (Technically it aborts the normal page rendering life cycle and redirects the user to the Access Denied page.)
ULS logs are found in the 12 hive under the LOGS subdirectory. I would suggest using the ULS Viewer instead of trying to visually parse through the logs with NotePad (there's a lot there).
Another SharePoint question from myself!
I've created a subsite and from within Sharepoint designer I've created a new aspx page, all nice and simple so far. I can't seem to find where I can change the security on this new page, only site admins can view the page and everyone else gets access denied.
It doesn't seem to inherit the permissions from the parent and I can't see where to change the security settings!
Please help, I'm sure it's something simple!
Thanks
Dan
You've placed your ASPX file in a 'bad' place. It doesn't sit where the normal security structures for SharePoint work so you won't be able to set its item level permissions (because it is not an 'item'). This is the danger of giving people SharePoint Designer ;)
Personally I think your page belongs in the _layouts folder somewhere since it seems to be an admin page. In there you could simply secure it by a call like:
SPUtility.EnsureSiteAdminAccess();
Either you can:
Put your page in a library so you can set item level permissions to it
Create a custom control that allows you to call the code above for any page
Move the page to _layouts
From SharePoint, you should be able to navigate to where you stored your new aspx page (probably in one of your Document Libraries). From that location you can either change the permission of the Document Library, or manage the permissions of an individual aspx page.
Please note that it is best practice to set permissions at the Site Collection level and allow everything under the Site Collection to inherit permissions.