How to write automation script trigger for this case

#4

@tjerman thank you for your suggested approach

so I can’t use record.values.* with dynamic values?
for example oldRecord

would that be improved later? do you have plans for it??

thanks again

#5

You can use the values outlined in that document I’ve linked above.

None of us have thought about adding it so not as of now.
I’ll open up a discussion for it so we can discuss it, but I don’t see why we wouldn’t add it at some point since it makes sense to me.

#6

could you please help regarding this?
here is my failed attempt

old? old.values.manager != new.values.manager: false

#7

hey @tjerman, I think the old object has an issue (I’m using 2022.3.1)

to reproduce the error:
I created a field called test
the field has an expression like this old.values.customer_id
the field customer_id already exists in the record (not empty)
when I edited the record I got this error
Could not update record: check error messages on the form

when I use new object everything is fine

#8

To handle the case where old is not defined, you can do something along the lines of:

(old ?? false) ? old.values.computed +  new.values.base: new.values.base
#9

@tjerman I think I have unexpected behavior (or bug)

to reproduce the issue

  • I created a new module
  • I created a Checkbox field called is_update with the following expression (old ?? false) ? true : false
  • I created a Checkbox field called is_create with the following expression (old ?? false)? false: true

the result:
when I create a new record or update an existing one the is_create field is always true and is_update field is always false

so this expression (old ?? false) always returns false which means the old field is always null even with update operation

#10

@tjerman any luck here?

#11

Hi.
Any news for this case ?
Are you sure ( old ?? false) is evaluated correctly as a boolean expression ?

If old record is missing then it is clear (old ?? false) will return FALSE
but
If old record exists (old ?? false) will return old record. I don’t know if old record means TRUE

#12

hi @CezarRadan thanks for sharing your results

I think yes it will consider old as true
if I tried it in the workflow I would get the right results

#13

Just checked it out and can confirm this is a bug.

1 Like
#14

Hi @tjerman, how can we proceed from here?

#15

Hmm, nothing sane comes to mind (besides checking the value in a workflow/script) so let’s wait for this to get patched up.
You can expect it to get patched out the week after next (that’s when the next batch of patch releases is scheduled for).

#16

Better yet, it might already be available tomorrow (if the patch goes through the QA ok, the fix was fairly trivial).

2 Likes
#17

hey guys, I can confirm the issue has been solved in 2022.3.3 version

and regarding my use-case here the expression
(old??false) ? ((old.values.manager!=new.values.manager)?true:false): ((manager??false)?true:false)

so @tjerman so my original question
and I can define a trigger runs after this expression is evaluated to true … for example

  triggers ({ after }) {
    return after('update').for('compose:record')
      .where('namespace', 'crm')
      .where('module.handle', 'Customer')
      .where('record.values.field_expression', '1')
  }

this will help me register a trigger when a specific field has changed

do you have a better workaround to register automation for a specific event?
do you have a plan to make domain fields registered as constraints in a trigger?

I can give examples for the second question

#18

Refer to here in regards to defining trigger constraints, and here in regards to what constraints you can use based on the resource.

I’m not sure in regards to what this is; being able to check if old value equals the new value? Not as of now but I’ll open up a discussion if we want to add it (I’d imagine we would since it does make sense to me).

Please explain. If you want to use module fields as constant values then that could already be used; see here

We currently don’t have any automation triggering related tasks in our pipeline so I can probably answer that we’re not planning on doing it.

#19

I already checked the docs and I can use the module fields as constraint but it will be static
let me explain more

I can define a constraint on a module field like this
.where('record.values.is_customer', '1')
why this is static? because I hardcoded the value to be 1

  • what if I want an expression instead of hardcoding the value … for example
    if I wanna run the trigger if the record has updated and the field value has changed (no the same as the old value) for example: if a field called is_customer has changed from true to false or from false to true. I would assume I can do something like this
    .where('record.values.is_customer', '!=', 'oldRecord.values.is_customer') (tried this but it didn’t work)
  • what if I want to run a trigger if specific number field is an even number
    .where('record.values.number_of_orders%2', '0')

hope it’s clear

#20

It’s clear but the matching logic doesn’t support expressions so you can’t do this at the moment. This part of the system was defined quite a while ago and we haven’t yet had the need to extend it.
I’ll kick up a discussion around this to see what we want to do here.

In the meantime either check the value inside the script’s code or use the field expression trick.

1 Like
#21

all clear, thank you

1 Like
#22

hey @tjerman I wonder if I can check for null values like this

.where('record.values.user_phone', '')

would that catch the null values or just the empty ones?

#23

I’m not entirely sure to be honest; try your version, .where('record.values.user_phone', null), and .where('record.values.user_phone', undefined) and let us know what the outcome is.
I’m quite sure your version should catch just the empty ones and not the null ones.