I have a custom list tracking idea submissions (think virtual suggestion box) where I am attempting to customize the DispForm.aspx so that users will not see fields that are not directly relevant to viewing the submission.
I am making a copy of the original DispForm.aspx and renaming to i_DispForm_mod.aspx and then changing the settings of the list to use this as the display form.
Problem is, once I modify the display form settings, it takes over the whole ball of wax. I can no longer access EditForm.aspx. Clicking on "Edit" gets you the display form.
Creating the URL to the edit page manually takes you to the display page. Creating a new item works as normal.
For some reason, SP is deciding to redirect all requests for EditForm.aspx to the display form. Properties for the list supporting files are set to all the appropriate pages - but SP is ignoring that in favor of serving up the display form. WTF?
I have no idea how to fix this. This is my second go-round with this after abandoning the first list created when I first got this behaviour.
Oh and just to add additional fun, the behaviour persists after restoring to original DispForm.aspx and resetting list supporting file properties appropriately.
Absent solutions I may have to mark DispForm.aspx as radioactive, do not touch and abandon my design as unattainable.
I cannot find anything similar being documented anywhere on the web.
Related
I have been attempting to have a section on a Sharepoint main page where anyone with modify access to that document library can easily modify the document metadata. Specifically there is a Status column that directs which stage of a review process a document is in and where it is displayed on the site.
I'm trying to make this as painless as possible for the end users. Right now the proposed process is to click the Quick Edit button, modify the column via a dropdown, and then click Exit quick edit to save the changes. Ideally, this document library web part would have a view set up that allowed access to the dropdown without having to go into quick edit, but it appears that the modern view of Sharepoint Online does not allow for the datasheet view to work correctly when used within the web part.
Is there another option to make this editing simpler?
Thanks!
I am working on our intranet that utilizes a custom .master page. One content placeholder that refers to the search functionality of SharePoint is being utilized in the footer ().
In our site mockup, we envisioned two search boxes, one in the top of the site, above the nav and one in the footer. I thought, easy, I just duplicate that content placeholder which brought up a duplication error from Sharepoint.
My question is this: Is there a way to duplicate content placeholders without needing to create a custom placeholder? And if not, is creating a custom placeholder the best way to go about this?
Thank you in advance!
There are many ways to customize this.
Direct master page change
Add (custom) place holder to master page
Use delegate controls (no master page change required)
Delegate controls allow you to create a regular user control (.ascx) and assign it a sequence number so that it becomes attached to an existing master page control. Using delegates could potentially allow you to attach the same user control to two different controls (delegates).
With all the recent "don't change the master page" buzz, it is becoming ever more relevant, although for on-premise scenarios, you can be a bit more eccentric.
Not only you can't duplicate place holders, but you should also be very careful while removing or even adding existing place holders, no matter how irrelevant they may appear to be. Even their original order matters (e.g. PlaceHolderPageTitleInTitleArea, PlaceHolderLeftNavBar).
refs,
http://blog.sharepointexperience.com/2013/08/missing-apps-you-can-add-with-custom-master-page-in-sharepoint-2013/
http://www.eliostruyf.com/missing-apps-can-add-zone-adding-new-app/
http://www.eliostruyf.com/document-set-view-not-visible-in-sharepoint-2013/
examples,
https://zimmergren.net/sp-2013-some-new-delegatecontrol-additions-to-the-sharepoint-2013-master-pages/
http://www.fivenumber.com/understanding-sharepoint-delegate-control/
I am working on a specialized instance of MOSS for a client where What I am wanting to do is hide elements on the master page. In particular, I want to hide the main top navigation bar, the search functionality and the label that shows up in the upper-left-hand corner that tells you the name of the site you are on. So I made a copy of the default.master, and then in SP Designer I set the visible attributes for the placeholders for these blocks to “false” in the new master file.
I can then assign the master to my normal site collection no problems and it seems to been working like I want it to. But when I go to look at the system pages (i.e. any of the forms or backend stuff), it is still using the old default master. And when I tried to set the System Master Page to my customized master file, my MOSS instance threw a File Not Found error. Then certain parts of the admin area just started failing in that same way (i.e. I would try to go into Site Settings -> Content and Structure and it also would throw a File Not Found error) Then at one point, the whole Site Collection would throw “Unknown Error” and there didn't seem to be a way to recover, short of reverting the state of the VM I am running MOSS in for development purposes.
So I am curious, what is the best way to create a custom master page and then hide elements on that page? I realized that my web cluster didn’t have the proper flag set up to actually show me real ASP error messages, so I am going to change that tonight when I get home and see what SP is really telling me about all of this. I have also read that changing the application.master file is not recommended, but I figured I could get away with making a custom page for the Site and System master pages and not worry about application.master. I have been reading a bunch of Heather Solomon articles as well as various other things. They all basically say that it’s ok to hide elements on a master page, but not delete them outright as SP will break if you do that. Would it be advisable to use a JS/CSS hack to manually hide elements that way, rather than actually making a new master page?
You create an asp:placeholder with the visible attribute set to false and place the contentplaceholders that are to be hidden in that container, weird I know but it works... as for the system.master you probably would want to make a copy of the system.master that SharePoint uses and then alter that one in the same manner.
Thank you so much for posting this. Works like a charm. I was so afraid because everyone says not to mess with the Application.Master. All I did was open it with Notepad and add Visible="false" (I wanted to hide the topnavigation bar because I have custom tabs that display depending on a user's permissions which are controlled by code in default.master. But then if a user had to upload a file, upload.aspx uses application.master and all the tabs would be displayed.)
I edited this line only:
wssuc:TopNavBar id="IdTopNavBar" runat="server" ShouldUseExtra="true" Visible="false"
Works like a charm!
Note that the following pages will also be affected:
Site Settings
View all site content
Workflow settings of a document library
Recycle Bin
Search results
I want to hide or make some fields read only on editform.aspx. I follwed the example on this page, but without deliting the "original" webpart list. I hide the original webpart and created a new custom list from the original list. Then i was able to apply xsl on the custom list to hide or to make the field "read only". Unfortunately the recurring events stopped working or where totaly messed up. Some times i've got error messages when I clicked on specific event in calendar view. The calendar list works fine and the fields are hidden or disabled in "Edit mode" when the event is not recurring. My question is. Is there any other way to hide or disable the items for specific security group or sharepoint group on calendar list?
If SharePoint Designer is an option, then this blog post from Laura Rogers shows how you can display SharePoint fields by permission level. It should work with a calendar list.
This will give you complete control over the solution without the need for a third-party product.
Two tools I've run across to do what you're looking for:
SPListDisplaySetting - "SharePoint feature (for WSS 3.0 and MOSS) providing advanced settings to customize list form rendering in new, display and edit mode."
You can specify that certain fields only show up on edit, new, or display pages and only for certain groups, or to hide them completely.
My only problem with this is that the installer doesn't quite work. However, a user has posted working instructions on the discussion board.
SharePoint Tool Basket - List Columns Manager - "This feature allows site collection administrators to view all the columns of a list including hidden/read-only ones and gives column details such as the internal name, Guid, Type.."
I found a pretty nice solution at Cleverworkarounds. The code is writen in javascript so the script does not actually remove the fields, which in my case is necessery, but it does hide the fields. Me, I need to stick to SharePoint List Form Extensions due to some sensitive data our customers have and want to be remove for some users. Laura Rogers solutions is good too, but with Cleverworkarounds you don't need to use Sharepoint Designer.
One option is to download the Sharepoint Manager from CodePlex. Install it on the server (it uses the object model) and you get simple access to a whole heap of stuff including, on a per-field-per-list basis, whether a specific column is hidden in it's entirety (even from the list settings), or hidden from the display form, the edit form or both. It's a matter of setting a true/false dropdown and clicking save. There is also the option for making columns readonly too.
It's all or nothing in terms of permissions though - whatever you choose applies to everyone who can access that area.
You can hide items in the calendar list using JQuery. Please follow the steps below:
- From the Calendar tab Customize List category select -> Form Web Parts -> Default New Form
- Select the Insert tab and from Web Parts category -> click Web Part.
- Choose Media and Content, then choose Content Editor and click Add.
- Place the Content Editor below your form and click inside the Content Editor
- Click on Format Text tab -> Markup category -> Click on HTML -> Edit HTML Source
Add the following code:
<script src="http://code.jquery.com/jquery-1.10.1.min.js"></script>
<script>
$(function() {
$("td.ms-dttimeinput").hide();
$("span[title='All Day Event'] > input").attr("checked","checked");
$("tr:has(span[title='Recurrence'])").not("tr:has(tr)").hide();
$("tr:has(span[title='All Day Event'])").not("tr:has(tr)").hide();
$("tr:has(span[title='Workspace'])").not("tr:has(tr)").hide();
});
</script>
The above code also puts the "All Day Event" to be checked true.
Hope this would be useful ..
I think it is little bit hard to do that. Otherwise there should be not so much such third party tools like SharePoint Column View Permission, Bamboo also has such tool.
Take a look at this if you want make it happen through code stackoverflow.com/questions/1058232. But I am not sure it works in calender.
I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.
Is this expected?
How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.
FWIW, this is the MOSS 2007 Standard version.
Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.
I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.
To give you a few hints and tips, the following should set you off in the right direction:
Created a new list definition.
Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
Copied the standard Rendering Template, but then made the changes to it that I
needed.
Wrapped it all up in a solution, and deployed.
My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.
Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.
I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.
Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}
Perhaps they grab the context back each time programmatically using these values.
I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.
I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.
I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).
Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.