the 3rd action (set column in this row) is not necessary I just added it to trace the custom action and find out where and what actions were breaking & why. I wanted to see if it was possible to set columns in the current row if the previous action was a set column on the user profile table.
In brief, this is part of a custom checkout, there is an orders table with a row for every order a user makes.
since the orders table has row owners, hence cannot place a buy button in an order details page. every order has a relation to a payment row in a payments table which has no row owners. The payment screen is where this custom action sits.
at the end of a payment this action should:
update the user profile table of the user with the status of his current checkout.
update the order connected to the payment with the payment details.
delete the payment row from the payment table
OK, I thought maybe the two conflicting actions on the same row was possibly a problem, but sounds like it isn’t.
I’ve seen a few posts with people having issues with the Delete Row action, so I’m not sure if it’s a bug or some technicality with how actions runs. I wish I knew the mechanics of how custom actions are executed, but it’s a bit of a mystery to many of us.
Can you explain further why you can’t place the buy button on the order details and need the secondary payment sheet? I don’t see why that would be a problem. I don’t have any answer as to why the Delete doesn’t work, but I think a slight restructure would remove the need to have a payments table.
yes it would be nice to know more on how the custom actions are actually being executed.
i can’t place the buy button in the order details because the orders table has row owners in it. I went down that road and found out that Buy Button’s dont work on tables with row owners. If you place a payment, an error will be returned.
Row Owners is necessary in this table as you don’t want users orders to be seen by other users, they contain shipping information and contact details
I also found this much older post that seems to contradict that theory and only indicates that there would be an issue if a user is not signed in and doesn’t have a row to reference.
But more experienced people agree that you can’t do it with Row Owners enabled.
So, I guess I’m not really sure. I’ve never used the Buy Button myself outside of some very brief testing to see how it works. The main thing I know about the buy button is that it can’t use computed columns. Beyond that, I have no idea what else is required for it to work correctly.
Anyway, have you tried moving your delete before any other action? I know it seems wrong, but it may be something to try.
I’m not finding it right now, but I seem to recall a post a while back that mentioned the pointer to the row getting lost sometimes depending on what actions your are doing. That theory doesn’t make sense though since your Set Column action still works. It may just be a bug with the Delete action since others have had issues too. You may want to submit a bug to Submit a request – Glide.
yes i’ve moved the delete to the top, but then none of the other actions are performed. which makes sense as when the row is deleted. Glide probably no longer finds the relation columns in the other actions.
if i delete the set columns in user profile table action. then all the rest work. there must be something about setting columns in the user profile table