| Age | Commit message (Collapse) | Author |
|---|
|
The code, as written previously had a subtle bug - if the user created a new
collection before they had tried accessing their list of collections, the
older code would not have migrated the older collections.
This commit fixes that by enabling the migration of older collections, whether
or not the user has created a collection with their new accounts.
|
|
Add an endpoint to list a user's collections. This only works for logged in
users.
|
|
Check only that the email format is correct, but don't bother with the
deliverability check during authentication. The deliverability check is done
at registration.
|
|
Implement the "Authorization Code Flow" for the authentication of users.
* gn3/auth/authentication/oauth2/grants/authorisation_code_grant.py: query and
save the authorisation code.
* gn3/auth/authentication/oauth2/models/authorization_code.py: Implement the
`AuthorisationCode` model
* gn3/auth/authentication/oauth2/models/oauth2client.py: Fix typo
* gn3/auth/authentication/oauth2/server.py: Register the
`AuthorisationCodeGrant` grant with the server.
* gn3/auth/authentication/oauth2/views.py: Implement `/authorise` endpoint
* gn3/templates/base.html: New HTML Templates of authorisation UI
* gn3/templates/common-macros.html: New HTML Templates of authorisation UI
* gn3/templates/oauth2/authorise-user.html: New HTML Templates of
authorisation UI
* main.py: Allow both "code" and "token" response types.
|
|
With the assignment of `system:*` privileges to roles, we need to check for
their existence when doing authorisation.
This commit provides a hack for that, seeing as user groups (and the system
itself) are not treated as resources, and therefore the way to fetch the
privileges is not entirely consistent.
|
|
While creating new group roles, enable the listing of non-resource privileges,
e.g. `system:group:*` and `system:user:*` that the user has to allow for them
to be used in role creation.
|
|
|
|
|
|
|
|
|
|
Some roles should not be user-editable, and as such, we need to check before
allowing any edits on such roles. This commit makes that possible.
|
|
Previously, the `oauth2/data/authorisation` endpoint was returning hard-coded
values for the privileges assigned to the user for each resource. In this
change, we rework to return the actual privileges for the user.
|
|
|
|
|
|
During development, we need logging sometimes to help with troubleshooting
problems. This commit provides a module to help set up the logging in a
separate module from the app module.
|
|
|
|
|
|
|
|
Fix bugs with setting up of the selected traits for use while filtering the
search results.
|
|
|
|
|
|
Consistently encode all values for the top-level keys stored in redis to avoid
issues with json encode/decode
|
|
Signed-off-by: Munyoki Kilyungi <me@bonfacemunyoki.com>
|
|
Signed-off-by: Munyoki Kilyungi <me@bonfacemunyoki.com>
|
|
* gn3/api/metadata.py: Import Template, sparql_query and RDF_PREFIXES.
(get_genewiki_entries): New endpoint.
* gn3/db/rdf.py: Add new constant for storing rdf prefixes.
Signed-off-by: Munyoki Kilyungi <me@bonfacemunyoki.com>
|
|
|
|
|
|
Decouple the `gn3.db_utils` module from the global `flask.current_app` object,
ensuring that the database uri value is passed in as a required argument to
the `gn3.db_utils.database_connection` function.
|
|
We need a search through the available phenotype traits in the database when
linking the traits to user groups. Unfortunately, the Xapian Search indexes do
not (and should not) include the internal identifiers we use to disambiguate
the traits.
On the other hand, we do not want to present the user with traits that have
already been linked to any user group within the search results.
The script in this commit, together with the modified queries for fetching the
phenotype data form a "hack" of sorts to wrap around the way the search works
while ensuring we do not present the user with "non-actionable" (linked)
traits in the search results.
|
|
To avoid application context errors in external scripts, disconnect the
`gn3.auth.db` module from the `flask.current_app` dependency.
|
|
|
|
|
|
|
|
|
|
When a user selects some datasets and does a new search, we filter out the
selected datasets too, even though they are yet to be linked.
|
|
|
|
|
|
Remove the deprecated function and fix a myriad of bugs that arise from
removing the function.
Issue: https://issues.genenetwork.org/issues/bugfix_coupling_current_app_and_db_utils
|
|
There is need to run external scripts using the same configurations as the
application but without the need to couple the script to the application.
In this case, we provide the needed configuration directly in the CLI, and
modify the existing `gn3.db_utils.database_connection` function to allow it to
work coupled to the app or otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
Fix the bug where the system was trying to load a user from a non-existing
OAuth2 client, leading to an exception.
|
|
The configuration in gn3.settings can (and does) get overwritten by values in
the environment variable `GN3_CONF` and any configurations passed in the call
to the `gn3.app.create_app` function; as such, this commit changes the
configuration used in the code to user the final configuration values that are
in the running application's `flask.current_app.config` object.
|
|
This is an initial attempt: it does not allow a search to be carried out
across the data available in the database.
I will need to rework this, probably start from the UI and work backward.
|
|
|
|
|
|
The way data is linked to the resources needs to be reworked. This commit
removes all the existing migration scripts that created the tables formerly
used for linking data in preparation for reworking the system.
|
