| Age | Commit message (Collapse) | Author |
|---|
|
BCrypt has been superceded by argon, and this commit removes it and
all code depending on it from the repository.
|
|
The schema changed a while back, and the script that is used to make
all existing data public needs to be updated for the new schema. This
commit does exactly that.
|
|
Use the core system functions to both fetch the user and make them
into a system admin, rather than fetching with raw queries. This way,
if the way the users are fetched, or made into an admin, changes, we
do not need to update the scripts for most part.
|
|
Make the system admin creation code part of the core system, and
simply call it from the script(s). This will help with maintenance,
since the changes are done in a single place only.
|
|
Only commit changes if the queries are successful.
|
|
Update query in script to provide resource_id for the user_roles tabel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds clarification that the `OAUTH2_SCOPE` setting is provided by
default, and so the final settings are only necessary to override
that.
|
|
|
|
|
|
|
|
Add an endpoint to help users get the resources authorisation by the
resource ids.
|
|
|
|
Get the resource used to control access to the InbredSet group by that
group's SpeciesId and InbredSetId.
|
|
|
|
Provide a new migration to create tables to handle the InbredSet
resources. The migration also sets up the resource category and the
related privileges.
|
|
|
|
|
|
|
|
- Update the name and version
- Include the whole of gn-auth in the `packages` list
- Include any non-python files in the install
|
|
|
|
|
|
|
|
|
|
|
|
Replace `group_user_roles_on_resources` table with `user_roles` for
the query that checks whether the user has appropriate permissions to
act on a specific resource.
|
|
Add an error handler to gracefully handle the custom
AuthorisationError at the application's top-level to avoid having to
manually handle it everywhere that the error (and its sub-classes)
might be raised.
|
|
Fetching resource data: system and group categories of resources do
not have associated genetic data.
This commit adds some code to temporarily handle that case as an edge
case before I can devote more time to fixing the issue in a much
better way.
|
|
Add a new `public-view` role to be assigned to all users on all
resources that are defined as publicly viewable.
Update code to make assign `public-view` role to a newly registered
user for all publicly viewable roles.
Update the code to assign/revoke the `public-view` role to/from users
whenever the resource is toggled to and from being publicly viewable.
Ensure that `public-view` is not revoked from system-administrators.
Ensure that `public-view` is not revoked from the group administrators
of the group that owns the resource.
|
|
|
|
|
|
The way the `gn_auth.auth.authorisation.roles.models.user_roles`
function works has changed: this commit updates the code to take that
into consideration and fix any errors.
|
|
|
|
* The system resource is public, and should be present for all users.
* Each user that is a member of a group, should have their group show
up in their list of resources.
* Fix the SQL join: add an `ON ...` clause.
|
|
|
|
With user groups being resources that users can act on (with the
recent changes), this commit moves the `groups` module to under the
`resources` module.
It also renames the `*_resources.py` modules by dropping the
`_resources` part since the code is under the `resources` module
anyway.
|
|
|
|
With the new schema, not all Resource objects are "owned" by a
group. Those that are, are linked together through a different db
table (`resource_ownership`).
This commit removes the `Group` object from `Resource` objects and
updates the `resource_ownership` where relevant.
|
|
Rather than using pymonad's Maybe monad and dealing with the
complexity it introduces, raise an exception if there is no group
found for the given resource.
|
|
Some resources are "owned" by specific user groups. This commit adds a
way to retrieve those "owners" where relevant.
|
|
For easier maintenance, extract the code that relates to specific
resource types/categories into separate modules, each dealing with a
single resource type/category.
|
|
|
|
* Link the `role_id` field to the `roles` table rather than the
`group_roles` table.
* Merge the data in the `group_user_roles_on_resources` table in the
`user_roles` table to have a single point-of-truth for all user
roles on resources.
|
