Confused on unlinked selection box

[daneyul]

I have a selection box element. I gave permission to add new entries to the user.

I've got 3 "mirrors" of the list it's in. They are unlinked.

User added a new menu item entry on the Form for one of the child elements and selected it. But, on the read-only details view (which is based on a different one of the duplicated lists) their selected value doesn't show--in fact, it defaults to the first value available in the list. (It actually DOES show in the list view which is really perplexing.)

Now--if I go and manually add that same entry in the details view and list view, everything works fine. But the functionality of letting the user add an new value doesn't seem to work on just the form element when using a copy of the list for the detail view--though to my thinking, once the entry is made and put in the db the List and Detail mirrors of that element should see the data, even if they weren't edited to include the entry in their version of the element.

 

[cheesegrits]

Nope, once you unlink an element, it no longer inherits any settings from it's "parent". And the options in checkbox elements (or dropdowns, or radiobuttons) are settings of the element. So it's just like if you went in to the backend and edited the un-linked copy of the element, and added a new option - it will only get added to that unlinked copy.

So, when the form is saved in (say) the original parent, with a value which doesn't exist as an option in the un-linked copy, and you try and display it in the un-linked copy ... it has no knowledge of that value.

If you absolutely have to unlink your elements, the only way round this is to use a database join instead of a checkbox / dropdown / radio. Create a table which has the values and labels you were using. And enable "add on front end".

-- hugh

 

[daneyul]

OK, Thanks! I'll give the database join a shot. I understood the option wouldn't be there for "choosing" in the other list once I unlinked it--just thought a value once chosen (and thus added to the db) would be available to all since it's just a value in a cell at that point-- but now that I consider it, I imagine the name of the chosen value isn't what's being saved to the db, but rather the id number of its menu entry, which the duplicate list view doesn't recognize because it's not in its element.

 

[cheesegrits]

Exactly. We store the "value", not the "label" in the table. And the mapping of the values stored in the database to the labels is in the element settings.

So using a join element resolves this, as you are using a table to store your values and labels, rather than them being in the element settings. And you can still allow people to add from the front end, by enabling front end add, which gives a button that pops up the form for the list your options are in.

-- hugh