Fix subconditions and condition group form #2256

2025-05-18T04:12:26+08:00

ahatzz11 commented

2025-05-18 04:12:26 +08:00

(Migrated from github.com)

These 3 tiny changes took me hours - this was really weird and as a rails/ruby novice I got tripped up on a lot, but it's working now!

There's ultimately a two main bugs fixed by this:

When saving 3 or more conditions, only the first 2 conditions are saved
When editing an existing condition, an extra subcondition is immediately rendered, meaning a validation error occurs if you were to change something else, e.g. a name or action

I noticed quite a few things debugging all of this:

When adding subconditions they were always given the same value. The html template also had the same value. This resulted in the form submitting with duplicate ids/names, so only the last one was saved. The first subcondition that automatically appeared had a value of 0, so it was also saved. This was a result of the top level rules_controller doing a replace_all on the IDX_PLACEHOLDER of both the condition and subcondition template. When the subcondition template was duplicated, it had the unique key from the parent no matter what - resulting in many subconditions having the same index.
Once I changed IDX_PLACEHOLDER on the subcondition to IDX_CHILD_PLACEHOLDER, each subcondition was properly getting the uniquekey from the conditions_controller, but the function there returned an alphanumeric string. After a bunch of chatting with o3, I found out that there seems to be something in rails that makes an alphanumeric key unpermitted. I updated the #uniqueKey() function in the condition controller to match the same function in the rules controller.
After this, all of the subconditions were created, but on an edit of the form you still got a new subcondition each time - and I think this was because the condition_group always rendered a new condition. I've updated this to only render persisted subconditions, and the controller still can dynamically add new conditions.

Here is a video showing some weird behavior before:

https://github.com/user-attachments/assets/fbdfa7fb-e65d-40b7-8526-bfc47d0726f4

and after:

https://github.com/user-attachments/assets/0706b89b-dce5-417d-bdb5-838316152c41

I still think there's some room for improvement on this page - like each rule showing that there is a condition group instead of a single condition from that group, but that's going to be outside of this.

fixes #2247
fixes #2248
fixes #2249

These 3 tiny changes took me hours - this was really weird and as a rails/ruby novice I got tripped up on a lot, but it's working now! There's ultimately a two main bugs fixed by this: - When saving 3 or more conditions, only the first 2 conditions are saved - When editing an existing condition, an extra subcondition is immediately rendered, meaning a validation error occurs if you were to change something else, e.g. a name or action I noticed quite a few things debugging all of this: - When adding subconditions they were _always_ given the same value. The html template also had the same value. This resulted in the form submitting with duplicate ids/names, so only the last one was saved. The first subcondition that automatically appeared had a value of `0`, so it was also saved. This was a result of the top level `rules_controller` doing a replace_all on the `IDX_PLACEHOLDER` of both the condition _and_ subcondition template. When the subcondition template was duplicated, it had the unique key from the parent no matter what - resulting in many subconditions having the same index. - Once I changed `IDX_PLACEHOLDER` on the subcondition to `IDX_CHILD_PLACEHOLDER`, each subcondition was properly getting the uniquekey from the conditions_controller, but the function there returned an alphanumeric string. After a bunch of chatting with o3, I found out that there seems to be something in rails that makes an alphanumeric key unpermitted. I updated the `#uniqueKey()` function in the condition controller to match the same function in the rules controller. - After this, all of the subconditions were created, but on an edit of the form you still got a new subcondition each time - and I think this was because the condition_group always rendered a new condition. I've updated this to only render persisted subconditions, and the controller still can dynamically add new conditions. Here is a video showing some weird behavior before: https://github.com/user-attachments/assets/fbdfa7fb-e65d-40b7-8526-bfc47d0726f4 and after: https://github.com/user-attachments/assets/0706b89b-dce5-417d-bdb5-838316152c41 I still think there's some room for improvement on this page - like each rule showing that there is a condition _group_ instead of a single condition from that group, but that's going to be outside of this. fixes #2247 fixes #2248 fixes #2249

zachgoll (Migrated from github.com) approved these changes 2025-05-20 01:33:57 +08:00

zachgoll (Migrated from github.com) left a comment

Thanks for tracking this down! Definitely a tricky one!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gavin/maybe#2256