no issue
- this has a big underlying problem
- each task in the pipeline can modify the options
- e.g. add a proper permission context
- if we chain after the pipeline, we don't have access to the modified options object
- and then we pass the wrong options into the `toJSON` function of a model
- the toJSON function decides what to return based on options
- this is the easiest solution for now, but i am going to write a spec if we can solve this problem differently
no issue
- Consistent naming for postLookup
- makes it easier to search and inspect the various usages
- Cleanup unneeded code
- Make res.render calls more consistent
- add some consistency to the calls to res.render
- Remove ancient reference to dataProvider
- Let's call it models everywhere now...
- Use consistent formatting across the API
- we're no longer using alignment in vars
- Misc other consistency changes in API
- always refer to local utils as apiUtils
- logical grouping of requires - dependencies, utils, "lib common" etc
- use xAPI to refer to API endpoints, e.g. mailAPI, settingsAPI for clarity
no issue
- extract handlePermissions to utils
- added NoPermissionError when canThis() rejects
- omitted users.js because it uses special permission handling
refs #2758
- add a set of default options to utils
- update validation function to only pass through permitted options
- pass permitted options into validate where necessary
- setup basic validation for each known option, and generic validation for the remainder
- change slug to treat 'name' as data, rather than an option
closes#3426
- added transfer ownership endpoint
- added owner to roles.permissible
- manually removed owner from roles.browse
- removed hard coded author role
- fixed tests that were passing due to hard coded author role
- added testUtils.setup(‚roles‘)
Closes#3083 Refs #3229
- Populates the dropdown list in the invite user menu with the
list of roles a user is permitted to create.
- Users API now checks the invite user request for allowed roles.
- Change API response from 200 to 201 on successful invitation.
- Change API response from 500 to 201 when the user was created but
the email was not sent. The client will show a warning notification
when it sees 'invite-pending' as the new user's status.
- Add support for "?status=all" to the /users endpoint.
- Refactor the route and controller for the /settings/users page so
that there's only one network API call to load users instead of two.
Closes#3196
* adds `/roles/` endpoint
* is given the current user as context
* wraps everything in a canthis.browse.role
* gets all the available roles (should "Owner" be filtered out?)
* optional parameter: `permission=assign`. Gets all roles authenticated user could assign
* if we're not signed in, gives a "please sign in" (standard) error
* if we're signed in, but user is not in the context, gives a "there was no user in the context" error
* if the user is an "Author", gives a "there are no available roles to assign" error
* implemented hacky filter because when.js produces heisenbugs past 3.2.3 (when.filter not available)
* added extra fixtures to `permissions.json`. Might need a migration.
Caveats:
* there are no tests
* for some reason the setup functional test was failing for me locally
