Issue with rule logic

[Travis Goodman]

Hi Alexander,

Upgraded to the following version a couple weeks ago: Dynamic Forms for SharePoint v4.4.5.27 – June 28, 2021|CSS version: 4.51 / |spjs-utility version: 1.352|Loader version: v2

I can replicate the problem with just 2 rules.

This is on the Edit form after an item has already been added.

I have a set of fields that I put in a groupID called “readOnly” in a rule that runs “When the form is ready”.

When the form is ready > Read-only fields I put tabGroup_readOnly

By nature of using “The form is ready”, I expect this rule to run last.

In rule 2, I have a normal “if this column equals this value” rule, and when the result is true, at least one of the fields in my tabGroup_readOnly becomes Required.

This causes the field to actually be editable on the form, even though it is supposed to be read only.

So to summarize, a field I want to be read only and is set that way with “when the form is ready” becomes editable if there is another rule that makes that field a required field.

Not sure if an actual issue, or a feature, but logically to me it is not behaving as I would expect.

I can work around this and simply not make the fields required if this is by design. I understand logically you’d want to make it editable if it’s required, but in my case those fields are required on New Form, so they should already have values in them on the Edit form. I make them required again on Edit form because I’m an overly cautious guy, but like I said, it does make sense if this is by design going forward. It just didn’t work like this before I upgraded.

[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]

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]

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 ago by Travis Goodman.
• This reply was modified 3 years ago by Travis Goodman.

[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]

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.

[Alexander Bautz]

Hi,
I looked into it and there is an issue with “The form is ready” rule – it is actually not triggered last if it is not placed as the last rule (highest index).

This is a bug that I think must have been introduced a long time ago – not actually sure which version I could have broken this in.

In any case I’ll get it fixed and release a new version later this weekend, but you should be able to work around it by moving the “The form is ready” rules to the bottom of your list of rules.

The rules triggering on user group membership does not reverse – if you look at the debug output it is marked as non-reversible (No reversing of this rule: true), but I’ll mention this in the contextual help also.

Alexander

[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]

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?

[Alexander Bautz]

Sorry, forgot to mention that setting a field as required will force it editable to ensure a form where an empty readonly and required field doesn’t prevents the user to saving the form.

I might add a check to only force it editable if the field is in fact empty.

I’ll look into it and get the new version out in the beginning of the week.

Alexander

[Travis Goodman]

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

[Travis Goodman]

Tip sent, receipt # 541777105F251913G

Thanks for providing such great support and an amazing product.

[Alexander Bautz]

Thanks!

Best regards,
Alexander

[Author]

Posts