Forum Replies Created
-
Posts
-
Hi Alexander,
That sounds like it is most likely the issue. Our company does remove the license when it disables a user account. Thanks for looking into this.
Joe
In addition, I rearranged the form fields between the forms just to be sure it wasn’t something to do with just the HTML fields. The fields stay in the DispForm order–they don’t switch to the EditForm order.
There must have been something unusual going on, but I don’t know what. I tried reproducing it, but I couldn’t do it with a simple clean list. Not sure exactly what was happening, but I did get it resolved by overwriting the form with an export from a mirror list. Sorry about the false alarm and inability to reproduce the issue! Thanks for your help.
It turns out the issue was a rule/form configuration mismatch. The rule which was supposed to trigger on form load included hiding many fields, but the fields had been deleted from the form itself where the rule was being applied. This did not trigger any errors, and I never could get any output in the console even with debugging on, which seems strange still. However, I was able to rebuild the form and only hide fields which were actually present. With this configuration, the rule triggers and outputs to the console as expected.
So my conclusion is, it seems if the rule which triggers on form load is referencing fields that do not actually exist in the form (even though they exist in the list), the rule may break or otherwise not run–even though the trigger conditions are met (but I never got any error messages to prove this theory).
It is just a normal choice field with “No” and “Yes” options. There may be more to this on our side. I am picking up where another user created the beginning of the form. I will do some more research into this and report back whether or not there is something that requires your assistance. Thanks for your willingness to help.
Oh, I assumed it was possible because in the rule it shows:
RuleID (for use in Custom JS)
I am trying to show or hide an element based on the value in a field. For some reason the rule does not apply when the form loads–just when the field is manually updated afterwards. We do have it set to trigger on “Form load and change of conditions for triggering this rule,” but it seems to only trigger on the change of conditions part. Our condition is just if a particular field is “Yes” and the “If yes” part uses the “Show elements” action while the “If no” part uses the “Hide elements” action. It works if the field is manually updated, but it doesn’t seem to run the rule when the form opens.
My thought was to run the rule on a button click that is part of the form navigation anyway. I will see if I can come up with another way to make sure the rule applies like I want it to.
If I do resort to an action in the button click, is there a built-in action to hide an element from Custom JS?
Hi Alexander,
Can you provide an example of triggering a rule in Custom JS? I am struggling to figure out how to do that with Modern DFFS, and I may be missing it, but can’t seem to find an example (for Modern DFFS) by searching the forum.
Thank you for your help.
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!
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.
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.
Thank you. And thanks again for adding this web part. It is very useful and allows replicating what the form pages used to do.
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.
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.
