The link to the calendar page is missing in the navigation block in
classic which causes a behat failure in the 'Set availibility dates
for an assignment' feature. The fix includes adding the calendar block
to the Course page which can be used to navigate to the calendar page.
Both in unit tests, but also in other areas (say blocks, for example)
it's possible that page->url has not been set yet.
So, let's change current code to always check if we have something
(page->url) to compare.
Note the use of has_set_url() is needed, because page->url is magic
method and it doesn't work as expected. Hate magics!
We used to display capabilities like "Manage any calendar entries",
"Delete evidence", "Manage competency frameworks", "View hidden courses"
and others as "Missing capabilities" for the mobile app service tokens.
This gave dangerous impression that the app will not work for students
without these capabilities granted. There are known cases of admins who
started to grant all these caps to the Authenticated user role because
they were afraid the app would not work for them.
The problem here is that the official mobile app service includes some
functions that have these capabilities declared as required. But they
are not really required to use the app. Either the app makes its own
clever checks of capabilities before calling the functions, or sometimes
the capabilities are not even correctly declared.
It is safer for everybody to display this information for custom
services only where the risk of the falsely missing caps is lower and
the information is more accurate.
Also, the help text has been improved so it does not suggest that these
capabilities must be always added. We do not know why the service has
them declared. In some cases, a service has capabilities declared just
because it makes use of them in the if-then fashion.
Additionally, the patch also displays the service short name because it
is actually needed to know.
The patch adds ability to filter the list of token by the token value,
the user and the service. Also the button to create a new token is made
more prominent and easier to spot.
No need to have a dedicated admin_setting_managewebservicetokens admin
setting subclass, and yet do not use almost any of its features. So the
patch merges the list and the forms handling into a single external
page.
Similarly, it feels like overkill to have a renderer method for a
simple confirmation widget - especially given that the URLs were
hard-coded in it. So that one was dropped.
The patch improves the display of the missing capabilities on the Manage
tokens page and the Select authorised users page. The list of
capabilities is rendered in a collapsible area and does not occupy too
much space by default.
Additionally on the later page, the patch improves the display of the
list of existing authorised users so that it respects the configured
identity fields.
The previous implementation falsely reported all implicit capabilities
inherited from the authenticated user archetype. That caused a lot of
capabilities reported as missing, even if they were correctly granted.
This new implementation uses a different logic. Instead of seeking for
explicitly assigned capabilities, it searches for capabilities that are
not assigned to any of the user's role across the system.
Please refer to the inline documentation. This should be still used for
informative reports only, not for actual permissions evaluation. The
context has been ignored here, as well as all the overrides etc. This
patch just makes it a lesser evil.
The purpose of this external function is to provide data for
asynchronous user selectors and similar widgets. It allows to search
users matching the given query in their name or other available identity
fields.
I suppose the original reasoning was that the web services protocols are
pluggable and that plugins can provide external function. But those are
not good reasons to put the whole Web services section under plugins.
Web services are not a plugin type and they always felt very
counter-intuitive there.
From the server administrtaion perspective, web services are similar to
scheduled tasks and therefore, they should live in the same section.
