I have a form that gathers a set of information from users and makes what is known as a posts page and it has a mix of text, number, choice, boolean, etc. and I display this back as an Inline list. Which is pretty straightforward.
But when doing a form edit can we make only certain fields editable and not all fields. Like, make only title or description editable and nothing else. Now sure if anything related to conditions works here.
That will work, but be aware that you may be updating values in real time as you enter them and the submit with set columns is redundant and you end up setting the same values that you had already set…unless you using temporary user specific columns to hold the values while you are editing and loading/unloading those temporary columns when going in and out of the screen.
Just be aware that there is also an edit mode for a Details View that you can enable and places an edit pencil at the top right of the app. Edit mode is much simpler, and allows a user to cancel any changes, but has its own restrictions, so some of us create custom edit or form screens like you did.
I just want to be sure that you’ve tested making a change in your edit screen and then back out without submitting and calling the set column action. Do the values still get set, even though you didn’t submit?
I think it will overwrite just like what you told in the first part of your comment.
My worry here is that I can’t control what the user should edit and what he shouldn’t
I get what you are telling - I guess whats what will happen.
I think I should try this.
Let me check and get back,
Also @Jeff_Hager what is the best way to understand “user-specific columns” were to use when to use and probably how to use. I somehow seem to get carried away by this though I know its powerful and good to use.
@Jeff_Hager Thanks a ton. Made the changes to use the “Edit form” with required fields & visibility conditions instead of the link to the screen and adding components. It worked perfectly. Didn’t even try the temp storing of values method (yet).
Just as you mentioned the values when I was using the older method were getting updated in real-time across all users and yes even without hitting submit. If I go back the new value was saved instead of reverting to what it was originally. Basically, it was so evident that it was destructive editing ( as we call in photo/video editing ).
“User Specific Column” looks like I need to spend some time going through the docs and also the forum to see what I can do. My use case does revolve around a multi-user platform where each user contributes individually but they should not be able to edit another users ’ posted articles.
This is a good source for understanding custom forms that use user specific columns as temporarily placeholders.
In general I usually use user specific columns for some UI control, so for example, I have a choice component that controls the visibility of other components that display on the screen (kind of like tab navigation, but my own version). All users can view the same main records, but I don’t want one user to change the choice component and have it affect all other users. That’s where user specific columns come in to hold each user’s choice independent of anybody else.
Much like the choice component in this image. Multiple people can view the same student, but what is displayed is controlled by the choice component and each user can view different sections for the same student without affecting other users viewing the same student.
If multiple people can change a value in the same row, without others being able to view it and keeping it unique for each user, then that’s when you want to use user specific columns. If everybody should be able to see the change, then you don’t want to use user specific columns. It’s one of those things that I think is fairly obvious when you do or do not need to use it.