Switch the "edit set for users" and "show answers" actions to form submissions.

[drgrice1]

Any action on the instructor index page (the Instructor Tools) that possibly includes multiple users or multiple sets can not be a GET request (i.e., a redirect). They must be a POST request (i.e., a form submission). This is because GET requests limit the amount of data that they can contain 2-8 KB (depending on the browser and server). If a large number of users or sets are selected this can easily exceed this size limit. The "show answers" action makes this even worse by including the problem ids. POST requests have much larger limits depending on both the browser and the server. Mojolicious limits this to 16GB by default, and it varies with the browser. In any case it is quite unlikely that this limit will be attained for any of these requests.

This issue came up with this page previously when all requests were redirects (GET requests). There was an issue reported several years ago about this when an instructor selected all users in a large class. So I fixed this by using a direct form submission via the formaction atttibutes on the respective submit buttons for which this was a problem. In some cases, since the parameters don't always match up with the page the form will be submitted to, javascript fills in the required parameters.

At the time I did not fix the "edit set for users" action (i.e., "Edit one set's details for some or all users"). It was more challenging than the others, since it needs to post to a different URL depending on which set is selected. I have a little more experience now, and figured out how to do it this time by using a regular expression replacement to add the correct set to the URL (and preserve URL parameters like effectiveUser and such -- Although I think these aren't actually needed since they are in the form).

The "show answers" action (i.e., "View answer log for selected users, for selected sets") is new, and I missed this when it was added. Although, that one is even more challenging, because it needs to have the problems ids of the selected sets. Those problem ids are now added to the page in hidden inputs that the javascript can access to fill in the needed information. I also added the formtarget => 'WW_Info' in this case. That means that the answer log will open in a new page like it usually does. I don't exaclty like this though, but if this is not done, and then the instructor clicks the "Display Past Answers" button on the answer log page then another window is opened with a second instance of the answer log. Perhaps it is time to stop opening pages in new windows like this? This is considered bad practice in many circles.

[pstaabp]

It appears that functionality hasn't changed at all--just the mechanism. Using javascript to build up the POST requests instead of perl?

[drgrice1]

That is correct.

[Alex-Jordan]

Note conflicts here now from a recent merge.

[Alex-Jordan]

Tested and is working. Did not test in a situation with tons of users, but I trust this fixes that issue.

How about the thing where if there are, let's say, 200 users, and you visit the Accounts Manager, at first it shows no users? I get it to show the users by clicking the filter action for all course users. This was not meant to fix that, was it? It seems like some sort of related cap in involved with that.

[drgrice1]

No, this is not intended to fix that, nor is that technically considered a bug. That is intentional behavior in the code. The point is that when there are a lot of users, it will take the page a long time to load. So if you really want to wait on that long page load, then you must click the filter action to make it so. For the placement exam server at my institution which has more than 20,000 users, it takes the page something like 5 minutes to load if all users are shown. The server doesn't take long to render the page data, but the browser takes a long time to render it all.