Interaction with web app items.

You can do the emails with web forms ajax etc but you can not automatically disable or remove the web app item. The person that posts the trip will need to do that. The web app item is under their ownership so only either via the admin or by themselves logging in and editing can you disable them.

Option1) With this option you can have someone "accept" the trip and it disable the webapp item. You make sure in the webapp setup you have "anyone can edit" and "requires approval" checked. Now, when someone checks the button,  which actually edits the item, it will disable it automatically. However, this is assuming that all items are already created. What I mean is, initially, when the item is created, it does not show and someone on your staff has to go in and "enable" the item before it will display on the site. But, maybe this is enough info to get you thinking. And you can find a workaround.

option 2) There is another (not so desirable) way that would "appear" to do what you need. You need to have an extra field(preferably a checkbox field) in your webapp item that when the button is clicked, it will also "check" this field. This field is placed in the layout as a "class" or data attribute. So then you could {display:none} If this class exists. For instance... you have a container in your list/detail view <div class="wrapper accepted{tag_accepted}">content here</div>. So then your css would be .accepted1{display:none;}. Also, in your webapp setup, make sure you check "anyone can edit"

Option 1 note: Your missing the key thing. Even when you mark "Anyone can edit" - This is anyone who is logged in.

option 2 note: This wont work

Option 1: This will work. Obviously, the user who wants to accept the trip would have to login to do so, but it works and is a solution. The only issue is the site owner will have to "approve" all trip submissions within the backend. However, when different user comes along and "accepts" the trip, then this will automatically disable it.

Option2: Yes it will. I have done this. Again, the user would have to be logged in though.

I have to ask if you have done both?

If you have you will know the theory vs how BC works is a bit different in both those cases

Hey Liam, Yes, I have actually done both. Again, the first option requires someone to approve each trip that gets submitted. But, when someone edits/Accepts it (has to be logged in) It will get disabled. The second one loads all of the items, but hides the "accepted ones" with css. (again person has to be logged in). So, may not be the ultimate solution, but it is something to work with and expand on.

Also wanted to point out the theory and how BC works. Yes, with a little outside the box thinking, things are possible in BC that even BC doesn't know about.

Just there are two known bugs that wont cause them to work well. I know what your saying, but the login aspect and these makes it not a rock solid solution, and also the edit all concept with the control for me in the past has also been very ropey for clients in terms of real world use. For me I put a big focus on how something will work in the real world and think through it very carefully.

Yep taking in account they login - yep as a developer scope they are solutions. option 1 is the better option, but option 2 for me does not really work well in that real world scope.

That is all I am saying Your not wrong, just not my ideals. I think though we may fine the original poster was not looking for the having to login option. which leads you to the stealth login method which then falls for the two options, which in a core sense again does work but has problems