feedback form now POSTs much more information - for Q&A site

[drdrew42]

When $courseURLs{feedbackFormURL} is defined, this PR introduces an expanded set of data that is submitted to the feedback form URL. This update is necessary for any institution who wishes to integrate with our (soon to be released?) Q&A plugin for WordPress or CBOX-OL. (Our current implementation is here.)

Nothing from the existing feedback form has been removed, we have only added more fields:

• problemSource => the path to the problem's pg file, if submitted from a problem's page in WW
• randomSeed => the seed for the current user, if submitted from a problem's page
• studentName => the name of the current user
• problemSetID => the name of the problem set
• courseID => the name of the course
• emailURL => the URL traditionally included in the 'email instructor' feature that leads back to the student's problem page
• returnURL => the URL to provide a link back to the WW page that this information came from
• emailName1(2...) => name of first (second...) authorized recipient of emails from this course
• emailAddress1(2...) => email address of first (second...) authorized recipient of emails from this course

Much of this data was previously being parsed from the referring URL (which is already problematic because of private browsing).

In addition, the problems' source paths are being used as unique identifiers (around which we aggregate questions), and in the latest update, the default WW setting was changed to not include the file path in the body of the problem. I'm totally on board with this change, it is really the way it should be - after all, who really needs to know the problem path? - but it is perfect for identifying questions about the "same problem", and we really need to have access to it.

We also needed to collect the email addresses for notifying instructors (TAs, etc) that a question had been posted on our Q&A site. There was no other way to effectively communicate those recipients given the existing form submission. (We have been hardcoding them, and updating each semester - gross!)

We are moving towards an initial (limited) roll out of our Q&A plugin for WordPress for the Fall, and expanding the amount of data provided by the feedback form would make this integration more robust.

[mgage]

I'm somewhat confused as to how you are using this form -- where it is being sent to and who will see it? Originally feedbackMacro_form() was written for the custom use of mathnerds which was an online help session. (They worked out of Lamar University). It is probably not the best design to copy.

Why are you not using %params to define the key value pairs you want to transmit? Defining the
%params would be the task of the calling module (as for example Feedback.pm). If this is complicated you might want to define a FeedbackQAForm.pm module to set alongside Feedback.pm. Does that make sense? I don't think it belongs in the top level object ContentGenerator.pm. Perhaps some other parts of the feedback process don't belong there
either and we should take this opportunity to rethink how feedback is handled and lay it out
in a way that is easier to extend and easier to maintain.

I also note that in the hidden fields you are supplying both the source code and the seed number so a student could completely reproduce the problem just by Viewing the raw HTML. (If this is being printed to a page that a student can view.) Is this a danger?

[drdrew42]

Our service is (I assume) similar to mathnerds. Clicking the feedback button sends this data to our WordPress plugin, which checks the incoming problemSource path to see if any other questions have already been asked/answered about this problem already. If so, the student will land on a page of questions and answers addressing (probably other randomizations of) their problem - if their question is still unresolved, they are also able to ask it from that same page. If no questions have yet been asked about that problem, then they get to be the first.

No matter what, the problem path is never visible to the end user (though I suppose it could be found in the HTML source with some effort). And perhaps it's the name of the variable that is misleading, but the problem source is not exposed in any hidden field - only the path to the pg file is sent. (We also included the random seed because we briefly considered having WeBWorK re-render the students' problems for our site instead of parsing out the base64-encoded version problem. I think we've scrapped that plan, so we can drop the randomSeed.)

Either way, if the student posts a question, our plugin then pulls the email recipients from the POST data - as well as the emailURL and student's name - to assemble a notification for the instructor (and/or TAs) that their student has asked a question, including a link to the WW problem for that student (arguably the most useful part of "email instructor"). In the meantime, the student's question is posted on our site and tagged with the problem set and course name - which allows for a certain amount of "drilling down" on these categories from the front page of the site.

I see what you're suggesting -- about adding the desired information to the %params hash when called by ContentGenerator/Problem.pm, but I think I'm still going to have a hard time grabbing the email recipients that I need. Though, following your suggestion, the rest of it will be greatly simplified.

[mgage]

OK. I understand a bit better. One difference between your use case and the email the professor case is that email the professor pops up a form and collects the students question before performing the action of emailing things to the professor.

I still think you should make another module and probably the ContentGenerator family is the right place to put it, even though this module might not actually emit anything to the student's browser it is sending info to a public place. (The original purpose of ContentGenerator was to contain all modules that posted something to the web. The idea was to make it easier to keep track of security holes. )

Try, but not to hard, to make it in such a way that we could direct to a similar forum, say in
a moodle forum without rewriting too much code. The MathNerd code was done in a hurry as a one-off project over a decade ago but it would be good to have a more thought out way to extend and re-purpose the Email the Instructor button. I can already see that it would be useful for the plans that LibreTexts has.

[drdrew42]

This PR has been replaced by #986 - closing.