Depend On Field - Many to 1 relationship?

Hey all - I'm new to Membership Pro. Very impressed so far.

I have a client whose enterprise is broken up into many jurisdictions. Each jurisdiction has a number of conferences.

The user only gets to select/attend one conference and it must be from their jurisdiction.

The list of all the conferences is very long and we do not want users to choose conferences that are not included in their jurisdiction. We thought the the Depend on Feature would be ideal to limit the list of conferences to only the conferences that are appropriate for a given jurisdiction. What we have currently is a lot of conference fields; one for each jurisdiction.

Ideally we would like to have a single conference field field that gets populated with user's conference selection, which can come from any of the various conference lists.

In other words, it there any way to set a many to one situation where any of the dependent conference lists can populate a single master conference field?

TIA - SL

Hi

Please read documentation at membershipprodoc.joomservices.com/basic-...tional-custom-fields and try to setup

I think custom fields dependency would be solution for your requirement. However, please note that in Membership Pro, we only support one level of dependency, mean we can have field B depends on field A but then not field C depends on field B

Regards,

Tuan

Hi Tuan,

Thank you for your response.

Of course, I have read the documentation and it seems my understanding is correct: each option in Field A requires a unique Field B in order to generate a dependent list. I have already created this solution. I was hoping that there was a a way to roll-up a series of fields (concatenate the text) into a single master field, along the lines of the Fee Formula, but for string data. No worries. We'll make this work for now.

Thanks, again, for the great support!

OK. Please continue to setup and if you have questions, please don't hesitate to ask

Regards,

Tuan

I have implemented this solution, but its not great. Let me share an example that might clarify my concerns.

Let's assume you want to force users to choose their city name from a list of cities based on their postal code, to be sure you have accurate postal code: city paring. The user enters a postal code which forces a depend on field related to that postal/zip code displaying a list of the related cities. The user chooses their city,

Presumably for a given state, there will be dozens of postal codes, each with their own set of cities. So while a single field will exist to display/reference the user's postal code, there will likely be dozens, potentially hundreds of city fields.

Forgive me if I have overlooked your approach to this, but how would we ascertain the user's city information within MembershipPro, when the city data exists somewhere in a set of many possible "depend-on" sibling fields?

it seems like a summary/calculated field, or some other way to roll up this sibling field data to feed one definitive master field, in this example THE City field, would be highly useful for reporting, export, mail merging, etc.