no issue
- extract handlePermissions to utils
- added NoPermissionError when canThis() rejects
- omitted users.js because it uses special permission handling
refs #4004, #5614
- added new public permission handling functions to permissions
- added a new util to handle either public permissions or normal permissions
- updated posts, tags and users endpoints to use the new util
- added test coverage for the new code
refs #3083, #3096
In order to implement advanced permissions based on roles for specific
actions, we need to know
what role the current context user has and also what action we are
granting permissions for:
- Permissible gets passed the action type
- Effective permissions keeps the user role and eventually passes it to
permissible
- Fixed spelling
- Still needs tests
refs #3087
- added ability to edit user/roles relation
- user is not allowed assign roles to himself
- only one role per user is supported atm
- added tests
This frees us up to enforce one single point of access, thus paving
the way towards allowing us to initialize the models at are request,
and not when it's require().
addresses #2170
- added role to user obj (only returned from the user endpoint)
- added `/users/?include=roles` and
`/users/?include=roles,roles.permissions` query parameters
- added and updated tests
closes#2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
Closes#2738
- Re-introduce the TargetModel.permissable interface check in the
regular permission flow path
- Pass loadedPermissions, hasUserPermission and hasAppPermission to
permissable interface to reduce logic necessary
- Refactor recursive call to pass original arguments but with actual
model
- Refactor canThis(this.user) use in api/posts.js to just canThis(this)
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
closes#2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
- Handle passing undefined user to canThis
- Add existence check to parseContext if statement
- Add unit test that passes undefined to canThis
- Allow internal canThis() checks
- Allow passing 'internal' or { internal: true } as context
- Do not lookup user permissions unless context.user found
- If context.internal, resolve immediately
- Add unit tests for passing 'internal' and { internal: true }
closes#2138
- Adds new models for AppField and AppSetting
- Removed permitted attributes from App model (handled by base)
- Added reference from Post to AppFields
- Added fixture data to DataGenerator
- Added integration tests for Apps, AppSettings, AppFields
- Added import for Apps
- Added app_fields to default fixtures
- Pass permissions loading to buildObjectTypeHandlers to eliminate
shared state
- Load both app and user permissions to check
- Check app permissions if present
- Create apps table and App model
- Move effectiveUserPermissions to permissions/effective
- Change permissable interface to take context; user and app.
- Add unit tests for app canThis checks and effective permissions
issue #1365
- added /*jslint unparam:true*/ to functions where absolutely necessary
- added /*jslint unparam:true*/ to functions in which keeping parameter
list added clarity to the underlying api, even when those parameters
are not currently used
- removed unused parameters in a few places
- This is a first pass at getting a more logical structure. The focus is on moving from admin/frontend to client/server.
- The location of the databases is highly important, this isn't expected to change again
In the future
- client/assets should probably become public/
- more stuff should be shared (helpers etc)
- cleanup some confusion around tpl and views
