yes, learnt it the hard wayā¦
Waaoovā¦
Thanks to Glide Team!
We will see a lot of thing i think in the future.
I echo this, we should have a list of actions and direct link to the view that controls it to be able to edit directly or delete it, or even duplicate it
Secondly if the action element is deleted by mistake specially when you work with multiple developers it wonāt be retrieved back easily
@Lucas_Pires I think one of the most important parts here once the new row is released is the in App notification In-app Notifications š
You presented before and now once a user view a certain notification then we can push a backend row update column to hide it from notification in app
Also you can add up Mark as unread function to shoe it again
That what am planning for so far
Hi all. Iām a bit late to the party playing with this (damn customers) but it all looks very positive. Clearly the killer will be the introduction of the new actions. Iām wondering if these will solve a scenario that Iāve been struggling with:
I want to be able to restrict a submission based on some logic. Itās to do with bookings and avoiding resource conflicts. Currently I have logic that knows when thereās a conflict (by using a relation) and I can show a message to this effect, but I canāt stop the submission.
Do we think that any combination of the new actions will allow me to solve this? Perhaps by adding a āsubmitā action to a button (and hiding the ātop rightā submit link) so that I can use visibility based on my existing logic? Or perhaps using some variation in the āadd rowā action?
Thanks in advance for any input.
If youāre doing the relation outside a form I believe you can just hide it using conditional visibility or show a button with a reshuffle action (so it does nothing).
Tks @ThinhDinh. The logic is checked inside the form since I am adding a ābookingā. Within the form the user can select a resource, a date and a āslotā during the day. The relation-based logic tells me if this slot is already taken so I can use visibility to show a message BUT I canāt see a way to stop the Submit, since right now the only thing that can stop a Submit is a required field being (a) visible and (b) incomplete.
This is great with so many use cases. Just checking - Is the āset columnā action only in staging still?
Yes thatās true.
Yeah I donāt think we can stop that.
@Robert_Petitto Have you stumbled across a solution for this one whilst playing with the new Actions capability in staging (or even elsewhere)? Cheers.
Canāt wait to have a clear action (hope it will follow the row_owner system i.e. only clearing the current user data), 'cause Iām doing over-complicated zapier or Google Script for that and thatās very painful.
Also the Show Notification will be a big help because some users donāt really read the current āSentā one 
Nothing prevents a submit except for a required fieldā¦best bet is to do the logic outside of the form button.
Maybe a lead here
That might make sense. The inequality operators (< >) in a condition seem to make the button disappear. Weird. @Mark?
Donāt forget itās weekend too, Robert 
Oh I know. Itās a rainy Saturday here with nothing to do though but Twitter scroll the election and brainstorm Glide.
Have fun!