Hi,
We have a user picker that needs to be able to have an "other" option. This is because many of the users won't have accounts as of yet, as we are using SAML.
We have found 2 potential ways of doing this but are unsure on which would be best practice or if there is another option:
1. User a userpickerfield and create a user called "Other"
2. Use a customPickerField with with a rule that gets all users in a group using groupMemebers() and append "Other" to this list. However, due to the fact that we could have over 10,000 user groupMembers() won't return them all so we would need to have a rule that gets the first 10,000 then the next 10,000 and so on using the start index on the paging info.
Thanks,
Niki
Discussion posts and replies are publicly visible
We have a mandatory question in a form which asks for a name. This name should come from the list of users, however, in some cases that user may not have accessed the environment yet and so an account would not have been created yet for them. In this scenario we need an 'other' option for them to select so that they can populate a text field the name of the person.
I agree with Stewart - in particular, the way I would consider approaching this is by adding a side-by-side control next to the user picker field, something like a checkbox labelled "other" or "user not yet in system", etc. Upon checking this box, the original user picker field would gray out and another field could appear allowing free-text entry. Or if you feel like slightly more juggling within the SAIL code, you could make the user picker field itself "switch" to a text field when that checkbox is checked (in the background you'd just have both components shown/hid conditionally on the value of the checkbox).
Secondarily - will you not be keeping a database table with information on your current users? If you did, you would have an easier time with the custom picker field, but more importantly, you'd have other options like showing a filterable grid of users that the person filling out the form can select from, as this would provide easier visibility into when the details they attempt to enter don't match a current user (and AFAIK there is no 10,000 item limit when dealing with filtered&paged queries like this).
I had the same thought as - if you're committed to using a picker here, and it must include "~~other~~" or some such, you'll need to configure a custom picker, not a user picker.
Agree with Stewart Burchell as well, here.Prioritize your objective over the implementation details. There more than one way to skin a cat, as they say.