- 24 Mar, 2021 1 commit
-
-
Tomo Tsuyuki authored
-
- 19 Mar, 2021 3 commits
-
-
Eloy Lafuente authored
-
Eloy Lafuente authored
-
-
- 18 Mar, 2021 13 commits
-
-
-
-
git://github.com/peterRd/moodlejun authored
-
-
-
git://github.com/aanabit/moodlejun authored
-
-
AMOS Bot authored
-
-
-
-
-
-
- 17 Mar, 2021 9 commits
-
-
https://github.com/stronk7/moodlejun authored
-
Brendan Heywood authored
-
Peter Dias authored
-
Peter Dias authored
Implement the new secondary nav and curate the nodes from flatnav and settingsnav
-
Peter Dias authored
-
sangnguyen authored
-
-
-
-
- 16 Mar, 2021 14 commits
-
-
David Mudrák authored
Credit goes to Andrew for Behat data generators for webservices. Co-authored-by:
Andrew Nicols <andrew@nicols.co.uk>
-
-
-
-
Mihail Geshoski authored
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.
-
Eloy Lafuente authored
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!
-
David Mudrák authored
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.
-
David Mudrák authored
On sites with many users, the fullname itself may not be unique identifier of users. Display the user identity fields below the token owner's name.
-
David Mudrák authored
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.
-
David Mudrák authored
-
David Mudrák authored
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.
-
David Mudrák authored
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.
-
David Mudrák authored
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.
-
David Mudrák authored
We can now use the autocomplete element to select the user. No need to for the legacy behaviour.
-