This commit mimics 100% the behavior achieved with the
parent commit of this when using the advance option.
1) Rename the 'tohtml' option to 'topreferredformat' to better
represent what it's doing.
2) Always honor the preferred format (this is a new post).
3) Only perform the conversion to HTML when the preferred format is
HTML.
That way any user, no matter thy are using format MOODLE (plain textbox),
MARKDOWN (marklar editor) or HTML (atto and tinymce editor) will
get always the format correct and the contents ready to be edited if
desired. HTML ones converted to HTML and TEXT ones unmodified.
1) Always honor the preferred format (this is a new post).
2) Only perform the conversion to HTML when the preferred format is
HTML.
This way, users having HTML as format (because of their editor
preference) will get the inline-reply converted to HTML and the
editor displayed.
And users not having HTML as format (because of their edito preference)
will get the format set to their format (PLAIN, MOODLE or MARKDOWN) with the
contents unmodified. Of course, if anybody is using a PLAIN, MOODLE or
MARKDOWN editor... it will be displayed.
The messageformat and tohtml params have been added to the addDiscussionPost
method to send the original format the contents are written and to force
to convert them from "messageformat" to HTML.
While keeping BC as possible (format will be saved as FORMAT_HTML
as default and content not modified), this commit includes these
changes:
- A new parameter 'messageformat', defaults to FORMAT_HTML.
- A new option 'tohtml', enabling the function to convert content
in other formats to FORMAT_HTML before saving them.
Since the night of the times (MDL-16698) we have been performing
that simple empty($post->messageformat) check to decide if the
preferred editor format should be used, instead of any existing format.
Problem is that FORMAT_MOODLE == 0, so the condition evaluates
to to true and then the preferred editor takes the baton when it should
not. Exiting format must win always!
So this just makes the condition a little better, checking if the
attribute is set and that it's numerical (accepting both n and 'n').
That covers the FORMAT_MOODLE case and any other valid format. Only if the
conditions aren't met the preferred editor format takes the baton. Only
then.
In a Single Simple Discussion forum, the first post can only be edited
by a user with the manageactivities capability, but all other posts
behave as normal.
LTI 1.3 requires working openssl functions to generate a private
key used for the JWT. Some installs (e.g. windows) can have the
functions available - but require configuration in php before they
actually do anything.
Update the discussion_list vault to use the first post record from
the posts table join to get the author of the first post rather
than relying on it's own "userid" column which can be incorrect in
the case of split discussions.
If the site is installed, and then the wwwroot changed, the plugin
config value for platformid for mod_lti is then stale, resulting in
OIDC errors. Given this config value was set using the wwwroot, we
should just be able to use the value of $CFG->wwwroot direcly, thus
avoiding this problem.
