Change of linked cells is not recognized as change

Good evening. I just found some strange thing happening to me:

I have a table with linked columns. Now i want to have an automation rule, which monitors changes in 2 of them like “if linked column 1 is not empty AND linked column 2 is not empty” … do stuff.

I can change those linked columns all I want, the action never fires.
But, as soon as I put links in those 2 AND THEN change a “real” data type column in that table, like a file column, it fires.

Any clues, walk arounds?

Hi @Gerald.

Well, the trigger only fires if both columns have been changed at the same commit. If you change only one column the trigger does not fire because the other column is still the same.

Since you are checking if both columns are NOT EMPTY you could add a third formula column which checks if both columns are NOT EMPTY and returns the value TRUE. So if both columns now have values that third column value has changed where you can put a trigger on.

Formula of column “changed”: and(not(isempty("Name")), not(isempty("Second column")))

The automation rule could change a fourth column like this:

It’s more a logical thought :slight_smile: I could be wrong but it woudln’t make any sense.

Actually, I find the behaviour strange though. Why is a rule not checking all its filters on each and every commit?
But then, if I switch the rule to a periodically one and fire it manually, it checks out ok.
Yet, i cant use a periodically one, as those cant change data fields… it’s a mess. Will try your solution now and report back.

No, it does not check out. It seems, that the checking of the filter value is not started at all, if the data is, or derives from link columns. This is the filter now:
image

If I convert the rule into a periodically one and fire it up manually, it works. So the filter is fine. Point is, filter is not checked at all after commit, as it only derives from changes in link columns and formula columns.

If changed to a periodically rule and filter check is forced either by clicking “do now” or by the time event, it works.
Well, i could work with that, if only periodically rules could also alter data, so I could set “message sent” to true… argh

Same is true, if I include a column with real data, like a file or a text value into the filter and change that. Then the event is fired correctly, and the filters are checked just fine.

Update. I checked on the list of available columns for filterchecks
image
And guess what? There are only those listed, which are not of type Link or Formula.

So that is the culpit. Only question remaining is, is that intended or a bug? And maybe a second one: How to get around that?

Maybe there is a bug with the periodically and manually check, I don’t know. Those are internal logics I cannot explain.

Yep, there are no filter column to watch, it would be a big improvement though. But since you could put a trigger on the two other columns you should be fine. But you have to check the third column if it is true to make sure the trigger only fires if both column have values.

Do you mean formula columns?

Formula columns cannot be watched because they are computed on-the-fly in the browser.

Yes, that is what I meant

Indeed. For the formular coloumns, I already suspected, that the “client based character” of those would prevent filter usage. For linked columns, that seemed off.
I heared, that the filter watch for link columns should come in one of the next updates. So will see how it goes.

Formula columns could be watched too, if the backend would create text columns to hold the calculated data in it. Surely, there is not one formular column, that changes every second and would overload seatable servers… one could even check, if the browser calculated value still matches the one, loaded from backend and only change if not… but yeah, future music.

Or one could compute them server side, if used in automation rule filters, as the given formulas are stored on the server, right? ^^

Link column support in automations has been added in SeaTable 4.1. Please consult our release notes:

If there weren’t these real world constraints … :wink:

Yes, nice. My employer will update to that soon.

I take the liberty of marking this topic as solved as - imho - all relevant aspects have been covered.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.