Modern DFFS Formpage DispForm no “Edit” button

[Joe Penland]

Hi Alexander,

I noticed the web part you added which enables showing forms on a SharePoint page – thank you! This is really useful! I have been playing around with it and it seems to be working correctly overall – just like the forms work when in a list.

I did notice one slight difference, though, in regard to the DispForm. When viewing an item directly in the list, there are “Edit” and “Cancel” buttons available so a user can switch to the EditForm. However, when viewing an item’s form in a Site Page via the new web part, the “Edit” button is not present. Is this by design, or would it be possible to have the “Edit” button available like it is when viewing an item directly in a list?

Thank you!

Attachments:

1. 

   Screenshot-2023-03-22-at-2.09.11-PM.png
   

[Alexander Bautz]

Hi,
I did a quick test and cannot reproduce this issue – the edit button shows. Do you use any rules or custom js / css that could hide the button?

Does the edit button show if you view the item in the list view?

Alexander

[Joe Penland]

I did a little more digging and found it seems to be a permissions issue.

I am testing with an account which has “Contribute” permissions on the list, but “Read” permissions on the site and site page which hosts the web part. It seems as though perhaps the web part is checking user permissions based on the page context or site, but not based on the actual list being passed through the DFFSList parameter. Is that possible? I would like to allow people to edit list items without giving them edit access to the whole site, or even to the page hosting the web part.

I tested adding the account to the site members group and the edit buttons came back. However, once I removed them again and they are only in the site visitors group, the buttons disappear again. When directly on the list, the account can see the edit buttons as expected due to having “Contribute” permission on the list.

[Joe Penland]

I would imagine you already know how to check the permissions agains the list, but if it would help I can provide some code I use to do this type of permissions check in my own web parts. Just let me know if it would be helpful.

[Alexander Bautz]

Thanks for your investigation and your feedback – you are correct, it is a problem with the permissions check. I actually checked the permissions on the web and not the list or list item.

I’ll get this fixed and publish a new version later this week / weekend.

Alexander

[Joe Penland]

Thank you. And thanks again for adding this web part. It is very useful and allows replicating what the form pages used to do.

[Joe Penland]

A couple other things I noticed, which I thought I should mention:

It appears the redirect from the page with the web part executes BEFORE the dffs_PostSaveAction() and dffs_PostCancelAction() are executed. Because the redirect navigates away from the page, the post save or post cancel actions are never executed at all as far as I can tell.

Also, when the DispForm is open for an item (while in the list, not through the web part) it appears the dffs_PostCancelAction() is executed if you click the “Edit” button to edit the item. This causes problems if you are using the dffs_PostCancelAction() to redirect the user to a different page because the form was not actually cancelled.

Thanks again for all your work.

[Alexander Bautz]

Can you show me the code you use to redirect and the dffs_PostSaveAction / dffs_PostCancelAction code? – I’ wondering if you are using asynchronous code and therefore the code does not trigger before the redirect?

Alexander

[Joe Penland]

Sure, I just have the code below for testing to make sure there should be no delays:

function dffs_PostSaveAction() {
console.log(‘This is the post SAVE action.’);
location.href = ‘https://duckduckgo.com/’;
}
function dffs_PostCancelAction() {
console.log(‘This is the post CANCEL action.’);
location.href = ‘https://www.google.com/’;
}

I added Source=https://www.bing.com/ to the URL on the site page with the web part and it always redirects to Bing no matter if I save or cancel – I never end up at Google or DuckDuckGo. I also never get either message printed in the console.

*** Both actions work properly if I cancel or save directly in the list, just not the site page with the web part.

• This reply was modified 1 year ago by Joe Penland.

[Alexander Bautz]

It looks like SharePoint “steals” the redirect when you use the Source parameter (it has as built in detection of the source attribute).

I’ll look at adding support for an alternative “Source” URL parameter to add a redirect in the URL when you do not use the dffs_PostSaveAction function to do the redirect.

In your case (when using the dffs_PostSaveAction) you can try removing the Source URL parameter. Please note that there is a built in redirect to the web frontpage that might kick in and override your postsave function, but I’ll add a delay on that one in the next version to ensure any location.href in the postsave function will kick in first.

Alexander

[Joe Penland]

Gotcha. Thanks for explaining.

I wanted to make sure you also saw the issue where the dffs_PostCancelAction() on a DispForm is getting triggered when you click the “Edit” button, not only the “Cancel” button. The dffs_PostCancelAction() executes before the form switches to the EditForm. I was seeing this behavior directly in the list when viewing an item and then clicking the “Edit” button.

Thanks again!

[Alexander Bautz]

Yes, that issue has been confirmed and will be fixed in the next version.

Alexander

[Alexander Bautz]

Thanks again, I’ll check those issues also and fix any errors in the next version.

Alexander

[Author]

Posts