Forum Replies Created
-
Posts
-
Oh, duh. Now that I’ve had my morning coffee, that makes total sense lol. Visually seeing it at first looked funny.
SharePoint Online
Version information
DFFS Loader: v2
DFFS frontend: 4.4.5.34 – October 15, 2021
DFFS frontend CSS: 4.64 /
Autocomplete: 1.6.52 – April 25, 2021
Cascading dropdowns: 3.7.48 – September 22, 2021
jQuery: 1.12.4
Lookup: 1.1.20 – March 10, 2020
Resource management: 2.4.5 – August 29, 2019
SPJS-Utility: 1.354 – October 15, 2021
vLookup: 2.2.162 – October 12, 2021One thing I noticed, I copied some text from a different source, and then tried to copy the text from the multiline and paste it, and it pasted what I copied from the other source. So whatever it is, the copy within DFFS is never reaching the clipboard since it’s not overwriting what I copied previously.
Also, just out of curiosity, the version you referenced the fix was in is 4.4.5.5, so why is the October 15 2021 version a lower number at 4.4.5.34?
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!
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.
Awesome! I am taking an extended weekend out of the office, but I will follow up with you on Tuesday. Thanks for everything Alexander, and the swift updates! Your customer service is outstanding!
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:
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!
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!
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.
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.
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.
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:
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?
