Avoid the use of "Yourself" when refering to the draft state of a blog
post, as it can mistakenly be interpreted as referring to the current
user (rather than the user who authored the blog post).
Previously, the type of share (course/activity) was being injected into
the string, but not from a translation, so did not fully translate. The
MoodleNet type (resource) was working, but has also been replaced here
to avoid inserting one string into another (this was also unnecessary
while resource is the only possible option). This also meant the latter
string could be deprecated.
In this commit, the front-end experience for grade item weights in the
gradebook setup page is refined, building upon the improvements made in
the previous commit.
Firstly, overridden weights are excluded from automatic adjustments.
This enhancement guarantees that user-specified weights remain unchanged
by front-end calculations, thereby preserving the flexibility of custom
weight assignments.
Additionally, front-end form validation has been introduced to enhance
the user experience. Now, users will see validation errors if they
submit invalid values, giving them the opportunity to correct the values
themselves. This ensures that weights are not automatically normalised
by the back-end code, preserving the values as entered by the user.
Introduces a base js class that bulk actions area implementations need
to extend. This class contains all common selectors, event listeners,
methods (including abstract) that each implementation would use.
Also, introduces a common template for the bulk actions area.
* When toggling bulk editing, updating the page's title can help users,
especially screen reader users, to determine the current editing state
of the course homepage.
* Create 'editing' versions of the coursetitle and coursesectiontitle
lang strings used for the page title of the course homepage and use
these when editing mode is turned on to provide immediate information
to users, especially screen reader users, the current state of the
course homepage.
1. Modified the password related forms
2. Added a new constant in moodlelib.php called MAX_PASSWORD_CHARACTERS
3. Added a new method in moodlelib.php called exeeds_password_length
4. Updated the upgrade.text
Now Oracle can use longer table names, like all the
other databases, and the very same 10 characters limit
for $CFG->prefix applies.
As far as it's already checked by the environmental checks
we don't need to verify anything in the driver any more.
Also, deprecate the prefixtoolong,error string. I was tempted
to straight delete it but imagined some custom database driver
extending the core one so, it doesn't harm much to keep it as
deprecated some time.
While, right now, sites using long (> 10 chars) $CFG->prefix
can continue working (because we still don't have any table
> 28 chars), as soon as some new table with long name is added,
it won't work with PostgreSQL anymore (if the 63 limit is raised).
Hence, this environmental check will verify on both install and
upgrade that the $CFG->prefix is always <= 10 chars.
Sites with longer prefixes will need to rename all their tables
(and maybe other objects, depending on the dbtype) to use a shorter
prefix.
