* User-facing links are gated; internal services are not.
* Adds view decorator data_sharing_consent_required
* Renames `get_course_specific_consent_url` to `get_enterprise_consent_url`,
which now checks `consent_needed_for_course` before returning a consent URL.
Firstly, we're now explicitly instructing the comments service to not
return thread responses/comments if the request isn't AJAX. So, if you
load the URL for a single discussion thread in your browser, this would
be a non-AJAX call and we'll avoid loading the responses for the entire
thread behind-the-scenes. Big win here for large threads.
Next, we removed a redundant "get threads" call which was also happening
behind-the-scenes. This call was redundant as the front-end JS also
grabs the thread list when a topic is chosen, so we were making an
extranenous call for no benefit. Poof, gone!
Finally, we added some caching of database queries that are required to
drive a lot of the permissions/cohorts machinery around discussion.
This will have a minimal effect but introduced a cleaner way to apply
general memoization at the per-request level which will let us further
cache things as we identify them as issues.
- Default of "desc" is all that is in use, and remains as-is.
- Discussion API keeps order_direction param, to minimize changes,
but it only accepts "desc".
- Discussion webapp simply no longer sends in the sort order.
We're often grabbing the metadata of a specific thread to then be able
to perform other operations, but we never need the actual responses or
comments of a thread unless we're displaying it in the normal forum
view.
This change sets a default of with_responses=False, which instructs the
comment service to not send back the responses/comments for the given
thread. We only ask for responses in the case of rendering a single
thread or inline discussion.
