| Age | Commit message (Collapse) | Author |
|---|
|
Authentication should be handled by the auth server (gn-auth) and thus, this
commit removes code handling user authentication from the GN3 system.
|
|
Temporary traits are not saved to the database, and have no attached
resource (at this time). As such, make them all simply public-read to enable
access for users.
This might change after more information on usage of temporary traits is
collected and considered.
|
|
|
|
Provide the user and resource_id information in each trait's authorisation
details to help with linking on the UI end.
|
|
Ensure the authorisation endpoint expects only JSON.
Add the user data to the response from the endpoint.
|
|
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.
|
|
|
|
|
|
Fix bugs with setting up of the selected traits for use while filtering the
search results.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
Rework the migration trigger endpoint such that it does a bulk import of all
the resources in the redis store.
It also expects that the user that triggers the migration have the appropriate
privileges.
|
|
|
|
The functions that fetch the unlinked data have checks to ensure they are
called by users with the appropriate privileges. This commit enables a
temporary escalation of privileges to enable fetching the data, so as to allow
successful data migration.
|
|
Due to the fact that the data migration requires higher privileges than the
user details, separate the user details migration endpoint from the data
migrations endpoint.
|
|
|
|
Implement the code to migrate the data from redis to SQLite.
|
|
Provide an outline of the data migration steps to be taken from some results
of the experiments with the data in redis.
|
|
Enable the data editor to unlink data from a particular resource.
|
|
When the endpoint is accessed with a list of traits, it should/will respond
with the access privileges for each of the traits attached for the active
user.
|
