I’d like to be able to make a field rendering conditional based on a secondary model on the page (not the one that the field is associated with). In my case, it is to make a field optional based on the User object (based on the logged in user), but on a Case field editor (which is a new empty case). Currently the field rendering feature does not allow this capability - something to think about for a future release…? I can use a snippet to examine the secondary model, and go into the DOM and hide the fields (or even easier, hide the entire Field Editor). But of course the field validation still runs - causing the page to be impossible to save. The best answer I’ve found … though I’m a bit worried about my approach … is also use a snippet to locate the model, traverse into registeredLists and locate my Field Editor, and within that locate my fields within the requiredItems object and delete them. Which does seem to work, though I’m diving pretty deep into your data structures. Is this a bad or good practice? Should I be worried about side effects and/or future updates breaking me? I’ve seen other comments here about using a custom field renderer, but the validation strategy always seems to be to use an alert(…) call - which is a different user experience for the validation than the other fields - something I’d like to avoid. Is there a better way to approach conditional field validation across models? Thanks, - Chris
+17- Nintex Employee
- 3763 replies
Chris, this won’t be completely satisfactory but its an Idea. Rendering conditions of items within a component will only be able to listen to the model that drives that component. But Rendering conditions of components themselves can listen to other models.
- So the sections and the fields themselves in a field editor can only listen to the model that drives the field editor.
- But the field editor itself can be shown and hidden based on data in other models.
You can have as many field editors as you want on the page, and you can achieve some pretty sophisticated results with panelsets and multiple field editors. And you can turn them off based on rendering conditions on other models.
Let me know if this helps.
+7Yes - that is cleaner but does require some extra CSS work to make it seamless … but does avoid having to dive deep into your structures. Thanks!
+13We are finding a consistent need to be able to conditionally render fields in field editors (and columns in tables) based on data in secondary models. In our particular case, there really is no manageable workaround.
One Example:
- SFDC Objects have 3 “quantity” fields: 1) In the Unit of Measure selected for the Order; 2) Value Converted to Kilgograms; 3) Value Converted to Pounds
- Based on a user or system preference (e.g. User Object, Custom Settings, etc.) the page would display 1, 2 or all 3 of the values
- At the top of each screen, there are 3 checkboxes that can toggle the display of the 3 values with the default checked/unchecked value of the checkbox established based on the user preference
Within a field editor, not being able to conditionally render on a field results in a custom snippet along with javascript/jquery/css or several different versions of essentially the same field editor. Having Unique ID and CSS Class properties for individual fields would make this a little easier but still require javascript/jquery/css.
Questions:
1) Are there any plans to provide conditional rendering of fields, columns, etc. in the (near) future?
2) In lieu of that, any other suggestions for how to best achieve the desired result?
3) Are there any plans to provide “unique id” and “css class” properties for individual fields and columns?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.