Modern Library - Not able to Customize NewForm.aspx

Brass Contributor

Hi SharePoint Folks,

 

I am facing an issue with Modern Document Library. As a part of my customization, I have to customize newform with tabbing becasue large number of columns.

 

This piece of work I have done earlier with classic version. But with the new changes from Microsoft on Document Libraries, now I am not able to edit NewForm.aspx page and without that I wont be able to do any customizations.

 

I came across an article in this forum where they have announced the Field level JSLink implementation. Does this implies Client Side Rendering(CSR) is disabled for forms?

 

Is there any solution or workaround for this scenario??

 

Happy Coding!!

 

Sri

13 Replies

Hi Srinivas

 

Check out this brand new article of Vesa Juvonen about the possibilities of customizing the different modern experience "parts": https://msdn.microsoft.com/en-us/pnp_articles/modern-experience-customizations

 

Best, Marcel

Short answer: the team has not released yet a way to customize list forms in the way you used to do in the classic mode
Thanks @Jaun & @Marcel

I wasn't aware one could tab metadata fields in the old form customizations. 

Coincidentally this is a feature my users were used to in OpenText.

Hi @Srinivas Narula,

 

Traditionally in SharePoint we used to modify the list forms. It's questionably if this is the right approach. I've always seen the lists in SharePoint a place to store my data and nothing more. At least since SharePoint 2013 with its search web parts and display templates.

 

So I have lists to store my data

Search web parts to spit out html

and css to make it look good.

 

You could even use the search web parts, workflows or apps let users update list items.

 

So depending on your requirements I would consider apps as a means to interact with your lists.

In the classic mode, we used listforms just as forms to place data bound controls on them and styled them. mostly we created own listforms bound to custom content types. all of this was pretty "freestyle" and everyone used it's own javascript frameworks and UI styling components.

 

I think it's a question of time, until we see a standardized way of form customizations in modern experience. if you want to build your own and mobile sp list UI, just use PowerApps!

DO NOT use powerapps. If you have site visitors in your modern site, they won’t see your fancy powerapps form. Instead they will see a friendly notice that they require a powerapps license. What a perfect replacement over classic methods!

I agree, PowerApps is a convenience, not a solution.  Pushing these technology upgrades out with reduced capabilities is not helpful.  At a minimum, modern experience should maintain the features that classic provided; it does not.  If I could force my end users to not use the modern experience, I would absolutely do so since they are expecting the same feature enhancements that are not available (script editor/editing newform/editing editform/etc...).

Anybody come up with a solution for this yet? I don't even want to do anything complex...just hide/show various fields on the new/edit form and on the display form.

 

Also, doing this in GCC, so PowerApps isn't even on the table.

 

I tried using PowerShell to leverage SetShowIn___Form($false/$true). It sort of works, however, it appears that in the modern UI everything is an “EditForm”. So your New/Edit/Display forms are always identical based on the $true/$false for SetShowInEditForm() (using PnPPowerShell).

 

Does anyone have any other ideas on having a different new/edit form than I do a view form?

 

 

@Ben Stegink  I just tried this on a test modern list and it worked. I had to wait 10-15 minutes before the field actually disappeared from the form.

This test was to remove a field from the New Form. It used the PnP library. If you haven't used that before, you'll need to install it

Install-Module -Name SharePointPnPPowerShellOnline

Change the TENANTNAME, SITENAME, LISTDISPLAYNAME, FIELDINTERNALNAME

 

$cred = Get-Credential
Connect-PnPOnline -Url https://TENANTNAME.sharepoint.com/sites/SITENAME -credential $cred
$processedField = Get-PnPField -List "LISTDISPLAYNAME" | Where {$_.InternalName -eq "INTERNALFIELDNAME"}


#SetShowInDisplayForm
#SetShowInEditForm


$processedField.SetShowInNewForm($false)
$processedField.Update();
Invoke-PnPQuery
Disconnect-PnPOnline

 

@Robin Nilsson Thanks, I was using the method you outlined already, I just needed to do little more testing. I was changing too many properties at once when I was originally testing. The New/Edit does appear to work, however, the Edit/Display is where it all falls apart. I took the time to go through all the configurations and this is what you get

2019-03-21_12-57-39.png

Essentially, Display follows along with the Edit property rather than the Display. I'm assuming this is due to the quick edit in the information pane. But what would make sense it to only show the "Display" fields in the information pane, and the "Edit" fields once you click "Edit All". So, when dealing with Modern UI, you really only have New and Edit. Display is just ignored

 

Also, I realized one of the fields I was using was a calculated column. Those actually just ignore all the rules and won't show at all.

 

You could maybe make the argument that you don't need Display, as you can display everything you need in the list view and should only click on the info panel if you need to make a change. This may be the route I try. However, there are also times when you want a set of the fields in the list view for sorting/filtering/grouping but don't want to show all the fields. Once someone finds the list item they are looking for, they should be able to click it to view all the fields but not be able to change specific fields. Right now that doesn't seem to be possible with the built-in functionality in the modern UI.

Great work! I confirm your analysis on Display form not acting as expected when using the .SetShowInDisplayForm property of a field. I'd consider that a bug, actually - if there's a reason to not display something, it should be honored. I don't train much on using the info panel - I'm torn by its ease of use. But if a list uses PowerApps to interact with a list, the info panel is a way to get around any processing the PowerApps might do, which could cause problems.

Calculated fields have always been like that in SharePoint - only available on the Display Form. When I've needed to show it on an edit form I used customization to pull the field value and display it.

@Robin Nilsson, Yeah, I was going to use PowerApps, but it's a GCC tenant (which doesn't have PowerApps yet, it's been delayed at least 6 months beyond when it was supposed to be available...another story...) 

 

As for calculated fields, agree, it makes sense it shouldn't be on New/Edit since it's calculated. It just doesn't show on Display either...probably due to the face that Display appears to be driven off the Edit property.

 

Thanks Robin!

Ben