it looks like your first choice component is a multi-select. Is that deliberate? I ask, because it complicates things a little bit.
if a user adds a “Suggested Local Break”:
– would this be in addition to the choices they’ve made from the first list, or instead of those choices?
– would you want their suggestion added to the first list for the next user that comes along?
it looks like your first choice component is a multi-select. Is that deliberate? I ask, because it complicates things a little bit. // Yes multi-select is deliberate
if a user adds a “Suggested Local Break”:
– would this be in addition to the choices they’ve made from the first list, or instead of those choices? // Perfect world also be addition to the choices, however it it’s a pain, we can make it Instead
– would you want their suggestion added to the first list for the next user that comes along? // Yes must add to the list the next time
Something else to mention, is that I’m not using sheets, but Glide Tables. As I was looking at the Column Array options
Okay, this is quite tricky. And I’m not sure that can give you a good solution right now. I’ll need to think about it a bit.
But let me try and explain the challenges.
First thing - whenever you’re using multi-select it’s always best practice to write the values as RowIDs. This is because a multi-select will result in a comma-separated list, and you can never be certain that your item descriptions won’t contain commas. And this is especially true if you’re accepting values entered by users and adding them to the list.
So ideally, you would have your first choice component configured to use RowID’s for the Values, and your location descriptions as the Display As. This way, you be certain that stuff will never be broken by a rogue comma, and you can also safely change your location descriptions without fear of breaking existing relations.
So, if we are to follow my above advice, then…
This is a challenge, because we don’t yet have a RowID for the suggested item. So the only option would be add the text as entered. But then as well as running the risk that the user might include a comma, we’ll also have plain text intermingled with RowIDs in a single joined list. And that will present its own new set of challenges.
This is not too bad. We could simply add it to the list with the Submit action, and Glide will generate a RowID for it, ready for next time. But we’d still have the problem that we’re saving this as plain text, so it won’t be compatible with the RowIDs that we’d normally save.
Anyway, I hope that’s explained the challenges, and as I say I don’t have a good option off the top of my head. We could probably use a bit of funky if-then-else logic to deal with the plain text/RowID incompatibility, but I’ll need to give that some thought.
In the meantime, quite possibly somebody else will see a simple option that I’ve overlooked.
My family is in town and I created an app so everyone can have an overview of our schedule (a calendar view of what I called “slots”), a list of possible activities (which I called “activities”), etc. Note that slots and activities are two different tables: a slot is an entry in a calendar/agenda, an activity is something to do but does not include any information as to when the activity might happen (if at all).
When adding a slot in the form screen, the user can select from a list of predefined activities or add his own description of the slot, though this will not add an activity to the activities table. The situation is similar to yours I feel.
It’s good enough for my use case. Below is how I displayed the components in the builder. There are other components in the form, in particular start and end date-times to define the slot. This screenshot though seems related to your use case.
That explains the multi-select, I think. So when I submit the form, are those locations tagged to me as a user (rather than tagged to a photo)? They must be, I guess, because I don’t see anywhere in that form to upload an image.
Do these then become the Locations that I am “following”, or?
Apologies for bombarding you with questions, I’m just trying to get a clear picture in my mind.
Yes, I definitely think you need to be using Trebuchet or some variation of it.
But I’m still not sure about the best way to handle the mix of current values and a new (optional) value being added in the same step. I’m thinking that you probably need to be creating a row for the optional value, and then using the generated RowID in the same action sequence to update the joined list. But I’m not really sure if that would work, or how reliable it would be if it did work. I’d need to experiment with it.
Is there any chance I can get access to a copy of your app to experiment with?