Modern DFFS Formpage DispForm no “Edit” button

Home Forums Modern DFFS Modern DFFS Formpage DispForm no “Edit” button

Viewing 4 reply threads
  • Author
    Posts
    • #36556
      Joe Penland
      Participant

        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!

      • #36558
        Alexander Bautz
        Keymaster

          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

          • #36560
            Joe Penland
            Participant

              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.

            • #36561
              Joe Penland
              Participant

                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.

            • #36562
              Alexander Bautz
              Keymaster

                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

                • #36565
                  Joe Penland
                  Participant

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

                • #36566
                  Joe Penland
                  Participant

                    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.

                    • #36569
                      Alexander Bautz
                      Keymaster

                        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

                      • #36570
                        Joe Penland
                        Participant

                          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, 9 months ago by Joe Penland.
                        • #36576
                          Alexander Bautz
                          Keymaster

                            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

                          • #36578
                            Joe Penland
                            Participant

                              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!

                            • #36585
                              Alexander Bautz
                              Keymaster

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

                                Alexander

                            • #36568
                              Alexander Bautz
                              Keymaster

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

                                Alexander

                            Viewing 4 reply threads
                            • You must be logged in to reply to this topic.