Jan 17 2017 02:14 PM
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
Jan 17 2017 02:32 PM - edited Jan 17 2017 02:33 PM
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
Jan 17 2017 10:54 PM
Jan 18 2017 03:10 AM
Jan 19 2017 04:39 AM
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.
Jan 19 2017 05:59 AM
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.
Jan 19 2017 06:23 AM - edited Jan 19 2017 06:34 AM
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!
May 23 2018 04:56 PM
Nov 05 2018 06:57 AM
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...).
Mar 20 2019 01:53 PM
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?
Mar 20 2019 03:27 PM - edited Mar 21 2019 10:35 AM
@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
Mar 21 2019 10:12 AM
@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
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.
Mar 21 2019 10:34 AM
Mar 21 2019 10:43 AM
@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