I have a working table that I am using as they fill in values, all with USC. It is working with the relation I have set up by user, so whatever students the current user has in his class show as selectable items.
But if I change the “class” on the screen, the USC is not set (presumably not until I am doing the “submit”)
What I would really like is for a substitute teacher to be able to select based on the CLASS, but of course defaulting to the students in the default class, which is his. Been trying a lot of stuff, but have hit a dead end.
User “Curtis” teaches algebra, and these are his students.
This is all happening on a record add using a working table – but presumably I’d have the same issue on any record add. All my columns are defined as USC.
You should be able to use Screen Values to apply dynamic filtering.
Mixing user specific columns with a native form screen is a little odd, and not something I think I’ve ever done. I’m not exactly sure what the expected behaviour would be here. @Jeff_Hager might have something to say about this.
First of all, anything filled inside of a form doesn’t exist anywhere except on the screen. No data is written to the table until you submit, and as such, no relations, or any other computed column will work until that data actually exists in the table.
In response to @Darren_Murphy, user specific columns are reliant on row ID’s to connect that user specific value in that row/column to the hidden table that holds the user specific data. For that reason alone, I don’t trust filling a user specific value in a native form for a row that has not yet been assigned a row ID. Maybe it works now, but I feel like people have had issues in the past. Without knowing how that’s handled behind the scenes, I feel like I can’t reliably trust doing something like that. I think for a lot of reasons, it doesn’t make sense to fill a user specific column in a form if it is creating a new row on each submission anyway. Obviously, that’s not always the case for everyone.
I think I need more clarification here. Is this a native form to add a new row or is it to edit an existing row? If you are just editing the row, then it would make more sense to avoid the edit screen and just place entry components on a detail screen, so that you are updating the user specific columns in the table in real time.
PS, Screen Values would be in the filter for your list to filter the list based on the chosen choice value.
Is that the Class choice component you are showing? I assume you would want to be filtering your list of students instead, which is where you would see the screen values. I can’t tell which component you looking at.
My choice component is based on the student table, and the default entries are the students that are in that teacher’s class. I was hoping to base the students listed based on the class selected on THIS screen, instead of the teacher’s class. You see I have removed the filter, so instead of only showing the students in that teacher’s class and defaulting to the same, I am now showing all available students. That’s cludgey, but works for this small school with only 8 students.
Just to make sure …the Screen Values will usually be in the second part of the filter condition. The first part is all of the columns in your students table, and the second part of the filter should include a screen values. Looks like you are showing the first part of the filter.
Does your form add a row, or edit an existing row?
OK, Curtis is the Algebra teacher (5 students). Now when I set the filter based on Student (CLASSES) includes Screen[CLASS}, I get what I’m after (the 3 geometry students)
Thank you and @Darren_Murphy for looking at this. I was starting to think I wouldn’t be able to do this way. I am not able to set the defaults if they change to entering a class for a different teacher, but this should be rare enough that it won’t matter.
