Well, I think you kinda answered your own question on this one. I’d use the schedule workflow command, that’s what it’s there for. There might be other ways of doing it, but this is what it’s built for!
Yes, this is true and a good point @andrewgassen. I guess I was assuming that the requirement was to keep the current user from clicking on the button multiple times in quick succession while waiting for the result of the first button-click, which would imply that they’d still be on-page. Is this not the case, @carl?
Also, I imagine that navigating away from the page or reloading it will add other variables anyway - inputs required for the original API call being re-initialised, for example, so probably not good UX to keep them waiting for the button to become active after loading the page. Only @carl will know for sure, though.
The actual example by you, @louisadekoya, is simply awesome. I followed it and working great! The yes/no field seems not to work.
I do want to prevent user to click button multiple times in quick succession.
I am happy to know that this method is limited when the user go to other page or refreshes it.
And also, I assume the button’s deactivation is also per user basis, that is when one user clicks it, button is only deactivated for him, while other (who also viewing at same time) user’s button is not. If can make the behavior be same for all online users at same time, that would be perfect!
Yes, this is correct. Are you saying that this is not what you want? That you instead want the button to be disabled for all users even it was last clicked by someone else? If so then instead of a custom state you should use a database field.
I meant simply replacing the custom state with a database field, but having tried it, I note that a scheduled page-based custom event seems to be cancelled when you navigate away from the page. So given your requirement, I believe you do indeed need an API workflow. I have updated the example with a second button based on a database field, updated with an API Workflow.
I notice that someone else (I’m not sure who) has added a third button with an alternative method. This sort of works too but if you quickly refresh the page after clicking the button, i.e. before the 10 seconds timeframe elapses, the button does not get automatically re-enabled - not until you refresh again. Using an API Workflow gets around this.
Hey @louisadekoya, i was the one who added the third button. Was just testing an idea without using scheduled workflow. It kind of work but when the button changes from active to inactive the page will have to refreshed to make it active again after the time has expired.
The idea was to store the time the button is clicked in the database and have a condition on the button that checks that saved time against the current time.
But the page will need to be refreshed for the condition to be checked to reactivate the button for the current user. Though any new page reload will work exactly as expected.