[somiaj]

When editing a set problem, grab the seed from the effective user instead of the current user, provided the problem is assigned to that user. Fallback to the current user (if it is different) before finally using the default seed as needed. This way when hitting the "edit" button while viewing a user, that user's problem is shown. I too have wanted this ability, to make testing a user's seed easier.

This was requested in #3253.

[somiaj]

Note, I went with the approach of always looking for the effective user's merged problem. This does have the side effect that the default seed will be used a lot when working on a problem from a set not assigned to a user if you happen to be acting as a user.

Another approach would be to add a problemSeed parameter to the edit buttons in various locations, and update the editor to not override the problemSeed with the problem record's seed if that parameter is present. I went with this approach as I couldn't think of any down side, and it doesn't require adding problemSeed parameters to the various links to the problem editor when acting as another user.

[drgrice1]

Another approach would be to use the effective user's seed if assigned to that user, then fall back to the current user's seed if that user is different and assigned to that user, then fall back to the default seed.

[somiaj]

I did think about that, but figured it wouldn't be worth an extra database call. Do you have a preferred suggestion?

[drgrice1]

I think a database call in the case the user is different is minor here though, and it would reduce the cases of the default seed being used.

[somiaj]

Added a fallback to the current user as well.

[Alex-Jordan]

Thanks for this. I will test soon, but I'm sure it's good. Maybe people want to discuss which alternative approach is favored most?

This has made me think of something related (but different, possibly for a separate future PR). If you are editing a set problem, then consider the place in the editor where you can set the seed. Have some tool at that place (a select list) that lets you select from among the users (for which that set has been assigned) and use whatever seed that user has.

[drgrice1]

This also made me think of another possibility that would require a somewhat different approach. If you are editing a set for a user on the set detail page and click on the "Edit Problem" button for a problem, it would be nice if the seed for that user would be used. That would require that the seed (or the user) be passed as a URL parameter though, since the effectiveUser is not set to be the user that is being edited in that case. That could also conflict with this, as the effectiveUser could be set to a third user (the instructor could be acting as one student, and editing the set for a different student). That last case could get confusing also, and that is why we need to rework the effectiveUser (or "acting as" another user) and not show the "Acting As ..." and "Stop Acting" button on pages where the effectiveUser actually does not have effect.

[somiaj]

The editor already accepts problemSeed as a parameter, but that is overridden by the problem seed of the current user's problem. My first approach was to actually just use that parameter and keep the editor from overriding it if it existed, and then set the parameter in the various edit button links. So this lead to tracking down all the edit problem links.

One thing that came up is when viewing a problem as a user, there is the "edit" button link and there is also a link to that problem in the problem editor in the navigation menu. Should both go to the effective user's seed (I was leaning to yes) or only the edit button.

This did lead me to the edit button when viewing a set for a user on the set detail page, and adding the seed there too as one of the many links to update. As I started getting into the weeds of that, I wondered how often someone on that page would want to edit a specific user's problem with their seed from that page.

So I back tracked, and instead of updating every link, just update what was currently being done vs try to redesign it since it was a small and simple change. I can go back to that other approach (make an alternate PR) if we think that will be more useful.

In my use case, I have wanted to be able to edit the problem with the seed of the user I'm acting as to work on a bug with that seed, but I haven't really wanted to do this in the other cases that have been mentioned, and in the case I'm acting as a user and hit the edit button on the set detail page, not really worried about what seed I get.

I am up for doing the work for whatever method everyone else would prefer. I just went with simple to start with since it would probably cover the case @Alex-Jordan and I would use it for.

[Alex-Jordan]

I lean toward whatever is simplest here, because in the end, I think the best thing would be to have a tool like I described in this thread. However you reached the point where you are editing a set problem, make it easy to jump to any user's assigned seed using a select tool.

[somiaj]

One possible drawback of having a drop down menu to select the user's seed you want, is you would have to call the database to load all merged problems for all users assigned to that set so you can get the problem seed. Also what about test versions, should all seeds for all users and versions be shown too?

Not that I don't think such a thing would be useful, but I would rarely need it, so it is a lot of database calls for the rare case I want to quickly get to a specific user's seed.

[Alex-Jordan]

Maybe there would be no database call until a button is pressed. Is that kind of thing possible without reloading the whole page?

[somiaj]

Possible yes, but I don't think there is currently an API call that requests all problem seeds. One could be added (unsure if that would be better vs update a current one). But that would make it so the database calls only happen in the case someone actually wants those seeds vs every time the editor is opened. Which would be better IMO.