here’s a rather special widget for you to fiddle with: the “autoaction” widget! It allows you to have one or multiple “UserActions” get executed whenever you reload the page or select another record. In other words, this is like an action button that clicks itself. Needless to say, it’s enourmously powerful but also very dangerous to use.
So what is this good for?
Well, this should come in handy when you absolutely need something to happen whenever people load up the page. For example, you could have a “current time” column that updates as soon as the page reloads. Or you could throw some switch (meaning a toggle column) each time, to trigger other stuff. The possibilities are endless but you really need to be careful what you’re doing. Obviously it’s easy to screw up your entire document with this.
I came up with the idea when working on my docxtemplater widget. The example implementation I provided there has one drawback: Due to the use of ‘PEEK()’, the placeholder mapping doesn’t get updated automatically when you modify something on the source record. So, “autoaction” to the rescue! Now everything gets updated as it should.
Known limitation: ACL
Executing a “UserAction” needs full access to the table you’re trying to execute it on. Providing the widget itself with “full” access isn’t enough - your user account actually needs to have every permission for said table or it won’t work.
See the whole thing in action here. (Notice how the document “auto forks” itself once you load it. That’s because the autoaction widget kicks in, effectively modifying the document right away.)
Haha, how great is that? To be honest, I was kind of surprised to find nobody had made this yet, seeing how long the action button widget has been around.
I had seen JPeron’s post but I hadn´t seen much use for it when using the Action Button method I created for the automatic filtered dependent dropdowns.
But I changed the method and I suppose this will be awesome for the new method!
Meanwhile (till @TomNit updates his widget), I made a sample from your document here: Filtered Reference DropDown(1) - Grist (as I couldn’t create a new one on your instance), based on pug_py widget.
You should have a look at the collapsed “Update on form select” widget, and open configuration to see how it’s made. The difference with @TomNit’s widget (and Action Button) is that the action is defined directly in the widget (so no special Action column).
To optimize storage, I replaced the date update column in Form by a mere reference to Country id, and put the access date into the Country table.
there is something wrong… I changed countries like two times and the cities remained Germany ,then I changed a 3rd time and it changed to brazilian cities, now they remain brazilian cities even as I change countries.
Sorry, I defined selection from the table below. Fixed it. Nevertheless, I get a strange bug that triggers a sequence of several updates ; the last one is the good one though.
Perhaps the bug comes from the fact we are two on the same database: this is a drawback of this method. There would be a workaround though: defining a per-user last access (with an Any column instead of a Date).
Just a quick heads-up for anyone interested, I updated the widget with more features.
Actions can now be run repeatedly at a configurable interval, and you can also configure whether they should only get executed for the record that’s currently selected or not. All options are detailed in the README file. These changes should make the widget a lot more versatile.
To be honest, I was kind of surprised to find nobody had made this yet, seeing how long the action button widget has been around.