- This topic has 23 replies, 2 voices, and was last updated 3 years ago by
.
-
Posts
-
-
So I’m noticing some odd behavior I cannot identify the root cause of. I have fields in tabs, some fields are in more than 1 tab. Not sure if that’s the issue, but anyway, when I click back and forth between tabs, the fields are not in the same place they were to begin with.
Here are screenshots showing the same tab. One is what it looks like when the form loads, and it’s correct. Then the 2nd one is after I went to a different tab, and flipped back to the original tab. It’s happening on all tabs though, the fields are jumping around.
In the “BeforeChangingTabs” screenshot, that’s how it’s supposed to look. In the “AfterChangingTabs” screenshot, the fields have moved. Description is now at the top, the row of fields that were originally at the top of the form are now below Description, and then the fields that you see at the bottom of the “BeforeChangingTabs” screenshot are now at the very, VERY bottom of the form below all other fields.
Again, some of the fields in the screenshot are shown in other tabs, so I’m sure it’s related somehow.
Attachments:
-
What version did you use before updating to this latest one? If you had a recent version already it must be related to the changes I made to fix your readonly / required field issue.
If you updated from an older version I need to know a bit more to be able to set up a test to try to recreate it.
Alexander
-
Hello,
I can’t say it was any change you made in the last version, because this is something I only just now noticed. I have over 100 lists with DFFS, and I just upgraded to your new version. The version I was using before I upgraded is this: Dynamic Forms for SharePoint v4.4.3.64 – March 13, 2019|CSS version: 4.46 / |spjs-utility version: 1.332
So it could have been introduced in any version in between those. I just happened to notice it on this list. I haven’t upgraded all my lists to the new version, so I’ll follow up if I see it on any other lists.
-
Update on this — in playing around, I notice the fields only get moved around if they are re-used in another tab. I made a test tab that did NOT re-use any fields from my first tab, and toggled between them rapidly and the fields did not move at all. They did get re-arranged as soon as I flipped over to the 3rd tab which did re-use fields from my first tab.
-
-
I haven’t been able to recreate it – can you confirm if it is related to using the side-by-side and also possibly having some of the fields readonly?
If possible, recreate it in a new test list so I can set up a similar test list to recreate it.
Alexander
-
Ok, I will conduct that test later this week. In the meantime, I have another issue that seems to be cropping up.
So backstory here, I am upgrading all my forms from the v4.4.3.64 – March 13, 2019|CSS version: 4.46 / |spjs-utility version: 1.332
to the newer v4.4.5.32 – September 29, 2021|CSS version: 4.51 / |spjs-utility version: 1.353
So everything I report is just differences I’m noticing between those two versions, the fault could have occurred several versions ago.
So for this one, using the curly braces method to use the field value, it’s not working.
So say on Edit Form I have “When the form is ready, set Title to {RequestType}”, the title literally just says {RequestType}. It does not use the value of the field. These rules have been in place for over a year, it’s just some functionality isn’t working in the new upgraded version.
Can you look into that?
-
I have another scenario I noticed.
Setup to test:
Claim Type (choice field — Active STDB, Active LOA, RTW)
Claim Status (choice field — Approved, Denied, Pending)I then have 5 fields:
LOA Applied (Choice — put whatever choices you want, not relevant to test)
LOA Begin Date (Date)
LOA Approved Through (Date)
LOA PCR Type (Choice — put whatever choices you want, not relevant)
LOA PCR Requested (Date)I then have those 5 fields grouped together with group ID loa, so I use tabGroup_loa in my rules.
Rule 1 — ClaimDenied (on load and on change):
If Claim Status = Denied
That’s it, I’m simply using it as a “linked rule and function” qualifier.
Rule 2 — ActiveLOA (on load and on change):
If Case Type = Active LOA
Same as above, no other settings applied, it’s going to be used in my 3rd rule.
Rule 3 — Linked rules and functions with “let linked rules evaluate parent rule on change” checked.
ActiveLOA|ClaimDenied
When Rule 3 is true, tabGroup_loa is placed in “visible fields” and in “editable fields” so that they show on form and I can provide values.
Here is where it gets messy….
Set it up so that you have an item already created that would make rule 3 be false when you next open the item. So for me I have an item where Status set to Active STDB.
That makes Rule 1 false on load, which makes rule 3 false.
So I can’t see tabGroup_loa right now. That’s expected.
Now, when I change Status to Active LOA, tabGroup_loa columns appear, but they are read only even though Rule 3 is true and they should be editable. Even debugging shows the fields should be editable.
I cannot find the flaw here. I’ve attached a screenshot showing the setup with the issue, and the debugger.
Attachments:
-
Update on this issue, I have identified the root cause!
These are underneath an accordion heading as seen in the screenshot. That heading is set to initially collapsed because I want it to be.
Turns out if I turn the expand/collapse to either off or initially expanded, the fields are editable as they should be.
So it seems there’s an issue where if fields are beneath an accordionHeading and it is set to initially collapsed, the fields will appear when the rule validates, but will remain read-only.
Seems like a bug.
-
-
-
-
Thanks, and tonight I found another issue that the only thing I can think of is that Linked rules and functions is not reversing.
Here’s the setup, create these columns:
Request Type (choice: create any choices you want, but include Info Change as a choice for the demo below)
Change Type (choice: same as above, but include Name Change for the demo)
Employee (peoplepicker)Rule 1: InfoChange
if Request Type = Info Change
Rule 2: NameChange
if Change Type = Name Change
Rule 3: Linked rules and functions (let linked rules trigger parent is checked)
InfoChange|NameChange
If Rule 3 is true, then make Employee Visible and Required.
It works the first time, but say I change those dropdowns so neither rule 1 nor rule 2 are true, Employee remains visible and required, even though it should reverse and be hidden and optional.
-
Seems like even though let linked rules trigger parent is checked, it’s just not re-evaluating. Not sure.
My temp solution is to create rules for when the Request Type is changed and another rule for when Change Type is changed, and in both of them I put into the “Run these functions / evaluate these rules” section to re-evaluate Rule 3. That works, which makes me think it’s either the reversing not working, or it’s not re-evaluating like it should when the dropdowns change.
-
-
All these issues have been fixed and I’ll try to get out an update tomorrow.
Thanks for the detailed description – this kind of bugs are impossible to fix if I’m not able to recreate them!
Best regards,
Alexander-
You are the MAN!!! Another tip coming your way from me, thanks for all you do.
And no problem, happy I can be of help. I’ve been using this product for years, and champion it around the company and push teams to buy licenses from you all the time. So I’m happy to contribute any way I can. You’ll probably see an influx of posts from me for the next month or two as I manage many site collections at my company, and we are finally migrating from SP2013 to SPO. That is what prompted me to upgrade from the older DFFS version I had to this new one, just to give you some context. So things that have been working, I’ll be able to tell fairly quickly what broke, and work to include detailed descriptions of the setups for recreating them.
I also want to be more active in the forums anyway given how much I use DFFS. Can’t wait to see what the future holds for it.
Thanks again!
-
-
Thank you for your donation! – I have now published the new version: https://spjsblog.com/2021/10/13/dffs-package-updated-to-v4-4-5-33/
Let me know if you still have any issues after updating.
Best regards,
Alexander-
Just downloaded and installed the update, thanks! There is one issue that is still not working, and it’s a really major one for me. It’s the “Set field value” at the bottom of each rule, when trying to set a field with the value of another field.
So like say I have a choice field called RequestType. I then have a rule that triggers when RequestType is changed I want to use the Set field value section to set Title to {RequestType}.
It’s not working correctly. It’s setting the Title, but it is literally setting the value as {RequestType}, it’s not converting to the actual value of the RequestType field.
So like if my RequestType dropdown value = Access Request, then I expect Title to update to Access Request. It’s not, it literally just says {RequestType}, curly braces and all.
It doesn’t seem to be dependent on any kind of scenario, it’s just not working period. I even tried it on a “When the form is ready” rule to set Title to {RequestType}, it simply doesn’t work.
I have many forms that depend on that functionality, so hoping for a quick fix for that. Really appreciate you!
-
I’m not able to recreate this issue. I have tested with dropdown and radio buttons choice lists and a rule triggering on both types of change, but the value in the Set field value is set correctly.
Can you email me some more info (screenshots) so I can ensure I have replicated it correctly?
Alexander
-
Hi Alexander, attached are 3 examples with snippets of screenshots in each and some additional commentary from me.
I’m pretty good at troubleshooting, but I cannot find a root cause with this one. This isn’t happening in every list, in some lists the curly braces are providing the values properly, so it’s something that’s going on, I just don’t know what.
Look at Example 1 — I am setting a single line of text field using 3 different fields as curly brace references. 2 of them work, 1 does not. The one that doesn’t is a single line of text field that is being converted by DFFS to a cascading dropdown. It is the first dropdown in the cascading order. The source column is a lookup column in another list. So I reference it as CaseType/Title in cascading dropdown configuration.
Example 2 is a choice field. Simply wanting to set the value of a multiline text field to the choice value for automatic note taking. This is something I’ve had for a year or so, and once I upgraded it is no longer working. That was version 4.4.3.64 that I had prior to upgrading to this latest version.
Example 3 is a date field, and that column was created with a space by another admin, which is why the FIN is ugly. Either way, it used to work, but yeah, same problem.
There’s no similarities between any of these. All 3 examples are from 3 totally different lists too. That’s why this is so hard to troubleshoot. Especially since it’s not a total failure, some curly braces are working.
Attachments:
-
-
This error was caused by a failed attempt to ensure no duplicate fields caused by copy-pasting HTML code from a form into a rich text editor were processed by the internal functions in DFFS.
In this case it skipped all fields in a side-by-side configuration when trying to fill in the value based on the keyword {name_of_field}.
Let me know if there are still issues with this version: https://spjsblog.com/2021/10/15/dffs-package-updated-to-v4-4-5-34/
Alexander
-
-
Hi Alexander, I have confirmed that the issue with the curly braces setting fields issue is indeed caused by virtue of the fields being in the side-by-side configuration. However, the updated DFFS files still presented the issue to me.
When I removed the fields in question from side-by-side configuration, the curly braces worked, but when I returned them to side-by-side, it went back to just posting the actual curly braces with the FIN in the middle.
Not sure how to troubleshoot.
-
-
Thank you, we’re good now. So what I did was is I simply downloaded the updated package, and only replaced the specific frontend and backend JS files needed, as well as the updated spjs-utility. While I thought that’s all I would need to do, the frontend was still showing the 10/12 version instead of the 10/15. So I went back to my installer, and just went to the re-install tab and ran it. That did the trick.
So let me know, is that the proper way to update DFFS? I plan on keeping it up to date in SPO, whereas previously once I found a stable version, I just kept it basically forever.
Thanks again!
-
You don’t need to reinstall any of the forms. To force the browser to release the cache you must go to the DFFS installer (v2) you used to install that form – select the first tab and hit the “Update loader file”.
This will write a new timestamp to the script tags to force the browser to update.
Alexander
-
-
- You must be logged in to reply to this topic.