Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Switch the "edit set for users" and "show answers" actions to form su…
…bmissions. 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.
- Loading branch information