[Travis Goodman]

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:

1. 

   rulelogicissue.png
   

[Travis Goodman]

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?

[Travis Goodman]

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.

[Travis Goodman]

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.

[Travis Goodman]

Tip sent, receipt # 541777105F251913G

Thanks for providing such great support and an amazing product.

[Travis Goodman]

Thanks, I’ll be sending a tip your way.

[Travis Goodman]

What are your thoughts on my scenario for my comment above, ID#34574

A field that should be read-only based on a rule with a high index becomes editable if there is a lower index rule that makes it a required field?

[Travis Goodman]

That makes sense because I have always had that rule at the very top of my rules since I knew it always triggered last anyway, and I wanted the form load rule at the top for easy access. I will let you know which version I had previously when I’m in the office next, but off memory I believe it was March 2019 or May 2019. Somewhere in there, and it was working then, so yeah sometime after that.

Also, in that version the user group rules did reverse, is there a technical reason that was changed? I used that a lot in my previous version before upgrade. No big deal, I’ll just add a “is NOT in user group” and set it to the opposite rules as the “Is in user group” to mimic reversing.

[Travis Goodman]

The very first issue I reported at the top is also legitimate. If you have fields set to read-only in the rule for when the form is ready, but then also have a rule to make that field required, it makes it editable even though it should logically be read only.

[Travis Goodman]

I think I figured out the issue!!!

Rules are not reversing when using “User is member of group”.

As a test, I made a rule that simply says if user is in group members, if true then make all fields visible.

The expectation is that if I’m not in the group (which I’m not), then it would automatically reverse the rule since it is false and hide all fields.

It’s not doing that.

This is definitely the issue, thanks for looking into it!

[Travis Goodman]

Ok, here’s my final example.

I have 2 columns, Request Status and Assigned To. In the tabs, I have them grouped to tabGroup_wfm.

Rule 1 (named Completed) = If Request Status = Completed

That’s it, I’m using it as a validation for Rule 2.

Rule 2 = If user is in group with name “Site Members” and then in the linked rules and functions section I have ~Completed, then tabGroup_wfm is editable.

So my expectation is that only users inside of Site Members should be able to edit the Request Status and Assigned To fields while Request Status is not equal to Completed.

To test, I took myself out of the members group.

The item Request Status is set to Submitted.

My expectation is that I should not be able to edit Request Status or Assigned To because I am not in the Site Members group, but I can, and I don’t know why.

Here are the two rules:

Rule 1:

{"friendlyName":"Completed","note":"","ruleDisabled":false,"ruleDisabledIn":{"n":false,"d":false,"e":false},"ruleDebug":false,"triggerField":"Request_Status","operator":"Eq","triggerValue":"Closed|Completed","validateOn":"b","siblingRules":"","siblingRulesTriggerOnChange":false,"noReverse":false,"stopAndExit":false,"jumpToRule":"","mandatoryFields":[],"optionalFields":[],"hiddenFields":[],"visibleFields":[],"readonlyFields":[],"editableFields":[],"hideSaveItemBtn":"","hideCancelItemBtn":"","hideEditItemBtn":"","setFieldValueArr":[],"displayMsg":{"fin":"Request_Status","val":""},"alertMsg":"","oldStyleAlert":false,"selectedTab":"","visibleTabs":"","hiddenTabs":"","runThisFunction":"","sendThisEmail":"","hiddenHeadings":"","visibleHeadings":""}

Rule 2:

{"friendlyName":"Workforce","note":"","ruleDisabled":false,"ruleDisabledIn":{"n":false,"d":false,"e":false},"ruleDebug":false,"triggerField":"DF_CurrentUserInGroup","operator":"","triggerValue":"Home Solutions Scheduling Members|Home Solutions Scheduling Owners","validateOn":"b","siblingRules":"~Completed","siblingRulesTriggerOnChange":false,"noReverse":false,"stopAndExit":false,"jumpToRule":"","mandatoryFields":[],"optionalFields":[],"hiddenFields":[],"visibleFields":[],"readonlyFields":[],"editableFields":["tabGroup_wfm"],"hideSaveItemBtn":"","hideCancelItemBtn":"","hideEditItemBtn":"","setFieldValueArr":[],"displayMsg":{"fin":"DF_CurrentUserInGroup","val":""},"alertMsg":"","oldStyleAlert":false,"selectedTab":"","visibleTabs":"","hiddenTabs":"","runThisFunction":"","sendThisEmail":"","hiddenHeadings":"","visibleHeadings":""}

• This reply was modified 3 years, 6 months ago by Travis Goodman.
• This reply was modified 3 years, 6 months ago by Travis Goodman.

[Travis Goodman]

The more I play with it, the more inconsistent it gets. I’m wondering if the form is loading before all my rules trigger. Let me play with this a bit more. Like when I refresh, the fields I see are inconsistent with what I would expect.

[Travis Goodman]

Actually, yeah this is a legitimate problem. Consider this scenario:

Form has a column called Status. Status is a choice field with Submitted, Pending, Completed choices.

Rule 1 = If Status is equal to Submitted, then field Assigned To should be optional. This will automatically reverse Assigned To to be Required if the rule is false. Perfect.

However, Rule 2 = If Status is equal to Completed, then all fields should become read-only so no one can go in and change anything after the item was already marked completed.

Expectation with Status = Completed is that Rule 1 would make Assigned To required, and since the item is completed, Rule 2 would make it read only so no one can manipulate it.

Reality is that Assigned To is left editable because Rule 1 makes it required, which is making it permanently editable.

Problem.

[Travis Goodman]

I can’t believe I forgot to mention this before, but I’m using SharePoint Online. Pretty important detail I failed to mention.

[Travis Goodman]

So I’m running into an issue. When I copy the link to the DFFS_Installer_CDN.html file to my CEWP in my target site, the CEWP throws back the following error: Cannot retrieve the URL specified in the Content Link property. For more assistance, contact your site administrator.

I assume it’s being blocked because it’s cross-site. Not sure how to get around this. It’s definitely not permissions, because I have the centralized site set to everyone.

[Author]

Posts