In EnumList, separate the Dropdown list and Validation expressions

[WillowMobileSys]

EnumList is the only column type that allows selection of multiple list items. There are many times when there is a need to provide a dynamic dropdown list AND apply Validation on the selections. This is not an issue normally for a single choice list as the dropdown choices ARE the valid choices. No further validation is necessary (normally).

One simple validation in an EnumList is limiting the number of selections. For example, if I had an app to create Teams, I would likely want to limit the number of persons per team. I want to show a dropdown of ALL available people to choose from but then force the number chosen to be equal to the Team size - no more, no less.

Another use case might be assignment of, say, Departments and Teams to a user. I may wish to allow assignment of multiple Departments but in another EnumList force Team choices such that there is at least one team from each Department. All rather than the tedious activity of assigning each Department and list of associated teams in child table rows.

Because the Valid_If is used by the dynamic dropdown lists, it cannot also be used to limit or validate list choices in the manner described above. A workaround I use is adding another column that performs the validation and is only shown when an error occurs. But this is not ideal.

My request is that for EnumList column, separate the dropdown expression and the validation expression as two distinct properties so they can be applied simultaneously to a column’s definition.

[1minManager]

Possibly dumb question. Can’t you do this via the Valid_IF and the Suggested Items options?

[MultiTech]

1minManager:

Can’t you do this via the Valid_IF and the Suggested Items options?

Yes you can, but it allows people to add things

• Now if they hard-tied the ability for people to add things to the list to the actual toggle inside the EnumList settings:
  • Then we could use valid if however we wanted (to create the list OR enforce validation)
  • We could use suggested values to create the list
  • And the toggle to “Allow adds” would control if people could add to the list
    • This last point seems hilariously common-sense to me… probly why it’s not happened! lol

---

This is something that I’ve been complaining about for-ev-er

[WillowMobileSys]

MultiTech_Visions:

This last point seems hilariously common-sense to me

Agreed. By this same token, Suggested Values means, well, suggested values i.e. it implies to me that other values are allowed.

It rarely turns out good to have a property perform double-duty. It’s fine until it’s not then sometimes “fixes” just make it worse. It thinks it’s better to unwind things then apply, as you say, a common-sense approach.

[MultiTech]

Over the years there’s been deep discussions about this with @praveen; the reason it hasn’t been “fixed” is because of backwards-compatibility. There’s already SOOOOOo many people that have built their app around that sort of functionality, trying to change it now… would be a big ask for some people.

• I think we should have ripped the band-aid off years ago, but I can see why the hesitation.

[WillowMobileSys]

MultiTech_Visions:

is because of backwards-compatibility

This has never really been a valid argument. The changes CAN be made. It’s more a question of value. Does the pain and benefit to switch outweigh the pain to leave as is??

The way to handle these situations is using the “deprecated” model - kind of like Workflows versus Bots. I.e. allow the old to continue to work, only allow new implementation, changes require migrating to new and actively encourage developers to switch to new.

Eventually, the numbers are low enough that with ample fair warning(s), the plug on the old is pulled, chaos ensues for those procrastinating few until they put their apps right again. Then the sunshine and rainbows appear - until the next deprecation!!