CD-CODE Docs issueshttps://git.mpi-cbg.de/dd-code-team/dd-code-docs/-/issues2024-02-29T19:56:56Zhttps://git.mpi-cbg.de/dd-code-team/dd-code-docs/-/issues/11Document post-processing tasks from "Sync"2024-02-29T19:56:56ZSoumyadeep GhoshDocument post-processing tasks from "Sync"Soumyadeep GhoshSoumyadeep Ghoshhttps://git.mpi-cbg.de/dd-code-team/dd-code-docs/-/issues/10Specs for storing Pubmed ID with protein with specific tags2023-11-01T18:15:35ZSoumyadeep GhoshSpecs for storing Pubmed ID with protein with specific tagsIn this documentation, I am trying to outline the specification of feature additions and modifications needed for storing PubMed IDs and strong evidence for all protein-specific annotations in condensates. As of now, we only store common...In this documentation, I am trying to outline the specification of feature additions and modifications needed for storing PubMed IDs and strong evidence for all protein-specific annotations in condensates. As of now, we only store common set of PubMed IDs for general protein-membership in a condensate.
# Database Schema Change
_Referring to [current](https://git.mpi-cbg.de/dd-code-team/dd-code-docs/-/blob/master/schema.md) version of schema_
**Condensate Attributes concerned**
1. `protein_functional_type`
2. `protein_exp_evidence`
3. `protein_driver_criterion`
Currently, these attributes are of data type `dict` where the key part is the UniProt ID of the member protein, and the value part is the respective annotation(s). For example, for `protein_exp_evidence`, it is currently a `list of str`, where each member is an experimental evidence (e.g. `in_vivo`, `in_vitro` etc.)
The value part in the `dict` needs to have its value modified to store a `dict` where it was just an `str`, and `list of dict` where it was a `list of str`. This will allow us to store more contextual details along with the annotation. To handle the situation at hand, the `dict` should have two mandatory keys - `'annotation'` and `'pubmed_ids'`. A sample annotation of funtional_type of a protein in a condensate could change from simply `"driver"` to `{'annotation': "driver", 'pubmed_ids': ['31366629', '31366121']}`
For now, we will not have any value for the `pubmed_ids` in the `dict`, however, hopefully, this will be curated over time using the values from the `protein_pubmed_ids` (these are list of all pubmed_ids supporting the membership of this protein in this condensate, but doesn't say yet anything about any specific annotaions).
# API Change
The same data structure change flows through the database. The visual changes will be done by the frontend. I realize that this is a breaking change and calls for a new version. But are we supporting API versions yet? I don't think we need that unless it is powering another web-app or long-running service.
# Frontend
**Component concerned**
Proteins table in condensate detail page.
Columns:
1. Role in Condensate (rendering `protein_functional_type`)
2. Driver Criterion (rendering `protein_driver_criterion`)
3. Experimental Evidence (rendering `protein_exp_evidence`)
Now we would be able to show PubMed IDs in the brackets beside each annotation. This is how most other databases have been displaying PubMed IDs till now.
**Example**
Now we parse the `protein_functional_type` field and search for the UniProt ID of the current protein row in this dict's key. If found, we show the value of this key. Since. now the value is `dict`, we have to display the `'annotation'` of this inner-dict and if there is `pubmed_ids`, we join the list of `pubmed_ids` with a suitable separator and show in the brackets, or else no brackets if no `pubmed_ids`
# Database Update (Sync)
While receiving `update_items` from contributors from "Role in Condensates" (functional_type), "Driver Criterion" (driver_criterion) and "Experimental Evidence" (exp_evidence), we must also accept `pubmed_ids` in another text input box along with annotation drop-down selection. This would ask for changes in the frontend input boxes. The rest of the part for the CMS frontend is described here https://git.mpi-cbg.de/dd-code-team/dd-code-web/-/issues/149Soumyadeep GhoshSoumyadeep Ghoshhttps://git.mpi-cbg.de/dd-code-team/dd-code-docs/-/issues/9Specs for user auth token generation from Admin portal2023-11-12T20:52:28ZSoumyadeep GhoshSpecs for user auth token generation from Admin portalThis issue documents the feature needed on the CMS frontend to allow (authenticated) users to generate an API Key from their own CMS User profile page.
# Existing CLI utility
Currently, an API Key can only be generated from the CLI of ...This issue documents the feature needed on the CMS frontend to allow (authenticated) users to generate an API Key from their own CMS User profile page.
# Existing CLI utility
Currently, an API Key can only be generated from the CLI of the API (Flask) repository by running this Python program - [auth.py](https://git.mpi-cbg.de/dd-code-team/dd-code-api/-/blob/develop/src/auth.py)
The command takes a mandatory argument `email` (of the user). If an API Key has already been generated for this user, then it throws a `duplicate` error.
# API
We need to expose the above CLI functionality over an endpoint.
## Routes
### Get the user's existing API Key by email
`[GET] /auth?email=<user_email>`
#### Response
- 200: When an API Key was successfully found against a user's email address
- 400: When query param `email` is not provided
- 404: When no user's auth entry is found with the given email address
### Generate an API Key for the user
`[POST] /auth`
Body: `{'email': <user_email>, 'name': <user_name>}`
- 200: Generated new API Key successfully
- 400: If the request payload doesn't have the required key - 'email'
# Frontend
- Show an additional field on the user's [profile](https://cd-code.org/profile) page labeled `API Key`
- This field shows a hidden password initially [`******`] with an eye button beside it
- On click event of the eye button, the API Key is fetched using the `[GET] auth` API
- If there exists no auth entry for this user (404 response), then show an error message and provide a button to `Generate API Key`
- On click of the `Generate API Key`, an API Key for this user is generated and displayed; use route `[POST] /auth`