We have a bunch of equipment, with a form for our guest users, so they can book items.
We would like to add a button to our Equipment database that says “Book Now”, which would open our booking form, and prefill the equipment selection option with the item you were viewing.
Our idea was to use Javascript to open a URL with the Entity UUID to set the initial field value. However, opening URLs is not possible with the Fibery Javascript Editor.
What would be the best way to do this?
All we want is:
A Button on a Equipment Database Entity Page that Open the Booking Form and Prefills the Equipment Field
I think you can just use a button automation and use it to create a new linked entity in the Booking db (or whatever you call it).
If there are other fields to be filled in, e.g. date, person, etc. you can either use a formula or the ‘Ask user’ option
Well, if it has to be guests, it’s not possible to implement as solution as you described, since
guests cannot press buttons
guests cannot create new entities and be attributed to them (they can only create entities anonymously via a form) so there is no way for Fibery to know who made the booking
You could create a url field which contains the url of a form, with qualifiers to specify a particular item (using a hidden field). It would be clickable but not a button per se.
You’re still faced with the problem of not knowing who submitted the form though (unless you expect people to choose themselves as one of the options in the form, which opens up to abuse and the disclosure of user details in a public form).
We didnt realize the buttons were not available at all for guests, we were hoping that that was only the case for buttons which directly impact a database.
The user name is indeed a downside that we are looking at right now. We will have quite some team members who will only submit issues (Researchers, Testers, and Externals who use the tools we develop, but never do anything apart from that), and knowing who these users are is great, but its not worth providing them with a paid account as their input is highly incidental.
We will try to find another solution.
Thank you for the clarification
We are thinking about use cases related infrequent/low-level stakeholders, and how the pricing model can support them, so keep your eyes peeled for updates.