So on the typeahead results, I'd like to show the matching text in the dropdown but it looks like some of the fields searched are not returned in the results. For example if I search for 'nib':

http://localhost:3001/api/variants/typeahead_results?query=nib

I get a bunch of hits but the drug field, which I assume which has all the hits on 'nib', isn't returned in the results.

Also if it's not too difficult or computationally expensive, it would be cool to have would be a list of field(s) that contain the searched string. So if I type in 'BRAF' then I get all the BRAF variants and a 'hits' field that might be ['entrez_name']. If I search for 'nib', the 'hits' field would be ['drug']. Then I can include that info in the dropdown.

Currently if an admin applies an edit, it appears to update the entity's record w/o generating a revision event that would show in logs, or revision diffs that would show up in the revisions grid. Generating revision evens and diffs would probably make the apply process much clearer (it's already proved a bit confusing - see griffithlab/civic-client#86).

Could/should we include admin apply actions in the revision workflow so that it generates update events and diffs?

The rake civic:dump task needs to start respecting foreign key ordering on table copy statements.

Right now that field is blank but it would be cool to have the time added and something like 'CIViC importer' as the user. Mainly so something shows up in the 'last modified by/on' displays for those records.

And by HGVS I mean use chr:start-stop (ref -> var)

Here are some values and other changes that I found myself wanting in the admin interface:

• In the Comments view show: Commentable and Commentable Type values
• In the Evidence Items view set default sort to be reverse chronological on the Updated At field.
• In the Evidence Items view add the Evidence Level field
• In the Evidence Items view in the Filters section, the Variant drop down menu should be sorted by variant name. The remaining values that you can filter on could all also be drop down menus as well.
• In the Variants view it would be good to have the 'Updated At' field so that one can quickly find the latest variants that were added.
• In the Variants view in the Filters section the drop down menu for Gene should be sorted by Gene name. I would also make this the first filter listed instead of the last one.
• In the Variants view, when you edit a variant ideally you should be able to edit coordinate information perhaps.
• In the Genes view, perhaps the default sort should be by Updated At. Same thing for the Suggested Changes view.
• It was not immediately clear how one would create a Subscription. Maybe we should have some examples in here or further guidance on how to create these?

Germline vs somatic status exists in spreadsheet but is not currently being imported into database.

@acoffman raised this important point. We should do this before we completely abandon the CIViC spreadsheet.

Select one user record that "wins", merge activity, roles and authorizations under that user record.

Plz #----2

I'm thinking that having an 'Applied by' column in the entity revisions lists would be good to have, and I bet we get asked for it eventually. Could we add an 'applied_by' attribute to objects returned from the various entities' suggested_changes endpoints? It might then make sense to change name of the 'user' attribute to 'created_by'. I don't consider this to be a high priority request, just thought it would be a good enhancement and didn't want to forget it.

Not sure if this is done yet, but it would be great to have use tracking in place prior to the soft launch so that we can get a sense of how many people we are able to reach.

On-site notifications of changes to entities a user is watching.

Create a background task that produces downloadable TSV files of the latest data.

The background task choked and had to be manually corrected when giving a doid in the form "DOID:XXXXX" rather than just "XXXX" we should be able to handle both.

Currently we return a 509 if a user submits an entity revision that doesn't contain any edits. In griffithlab/civic-client#88, Obi noted that he was able to submit several identical gene suggested revisions. I had expected that these would genreate 509s as well, but thinking back I don't recall if we discussed/implemented this or not.

As the revisions system is currently implemented, should these identical revisions be generating 509s and did Obi find a bug? Or is returning 509s from identical suggested something we need to discuss and add as an enhancement? (personally I think identical revisions should return a 509 or some other error).

After initial sign up, direct user to a page to supply any additional required details.

Allow for supplying links, institution names, etc.

In addition to the "last modified" information, we should include "created by" information in both the admin pages and the api responses.

The new browse-by-gene mode can have an 'aliases' column for each gene, but the server doesn't return these from the /variants endpoint, can we get aliases for each gene as well?

Issue #35 over in civic-client

This potentially involves the creation of new Genes and Variants. We will also need to verify (likely in background tasks) that the provided DOID, PubMed ID, and PubChem IDs are valid.

In the "browse" endpoint, the disease names should be returned sorted in descending order of evidence quantity.

I think I can fix this.

Load in a YAML glossary of definitions and provide an endpoint for accessing them.

One of the downsides of single page applications (SPAs) is that in order to be viewed they must be generated by javascript, and most search engine crawlers cannot do this. The workaround is for the server to return the SPA for users and static rendered pages for web crawlers. Google has created a set of standards for doing this, and it's also baked into AngularJS as well. More details at Google's Making AJAX Applications Crawlable page.

Given that one of the goals of CIViC is to be a useful online reference for cancer variant information, we should make it easily available to search engines, etc.

A company, prerender.io, provides software for doing the redirection and page generation logic. They've open sourced their software so it's possible to install and set up your own prerender server. Then you use their Rails libraries to plug it into your app.

I found this after digging around for a little bit, and it looks like the easiest solution. Here's Prerender.io:

https://prerender.io/

Their node-based page rendering server:

https://github.com/prerender/prerender

And the Rails gem that generates the rendering requests and serves up the prerendered pages:

https://github.com/prerender/prerender_rails

Can we get DOID, Pubchem ID, and pubmed ID to the output from an API call like:
https://civic.genome.wustl.edu/api/genes/238/variants/8/evidence_items/15/

It would be great to a have a view in the interface that showed the current 'bibliography' of CIViC. This would be the list of sources we have obtained 1 to n evidence statements from.

Use cases:

• We give credit to the authors of papers, while also giving a sense of the number and diversity of papers CIViC leans on.
• User can see if their favorite paper is already in CIViC
• User can add a paper to the queue that they believe has value but hasn't been curated yet.

View could show:

• Compact citation pulled from PubMed as we display elsewhere
• Number of evidence statements pulled from the paper so far
• Status (Curated, pending, etc.)

This view could be a third view:
'Browse by Variant', 'Browse by Gene', and now 'Browse by Source'.

On the admin backend, batch applying suggested changes results in an error page though the changes seem to apply.

civic-client issue griffithlab/civic-client#67 requires some kind of field that it can use to sort by amino acid or germline coordinate when displaying lists of variants.

To reproduce, query this URL:

http://127.0.0.1:3000/api/genes/38/variant_groups

and look for the four identical instances of D842V. The genes/:geneId route returns a gene record w/ a variant_groups array that looks correct.

In the client, this results in multiple identical entries in the Variant menu:

http://127.0.0.1:3001/#/events/genes/38/summary/variants/97/summary

(This issue is linked from griffithlab/civic-client#77)

Problem with data or import? Looks like there is an empty disease term causing a leading comma on the browse page for ALK F1174L

In admin interface, the View and Edit Evidence views only show (and allow editing) of a subset of evidence item fields. They should all appear and be editable.

We're planning on making some breaking changes to the API, and I was thinking about the best way to handle this so that we don't have to worry too much about pushing our changes on the client and server at the same time for this and future versions. Working on different branches helps, but implementing an API versioning feature would pretty much eliminate the problem.

I was thinking from the API side the easiest way to do it would be to place a version slug in the URL like:

http://127.0.0.1:3001/api/v1/[...]

Looks like there's at least one gem that provides this feature:

https://github.com/bploetz/versionist

and a few articles that show how to roll your own:

http://www.bignerdranch.com/blog/adding-versions-rails-api/

We'd like a dashboard of sorts for displaying information general site information, activity, and stats. We'll need endpoints to power them. Some ideas:

• Total database size (number of evidence items, variants, users, etc)
• Recent activity
• New users

I followed the install instructions but did both the rake civic:load and then the rake civic:import. The import failed on the error below. Is this because that import method is currently broken? Or can you not import directly from the files after you have already loaded from the existing database dump?

Obis-MacBook-Air:civic-server ogriffit$ rake civic:import['import/GeneSummaries.txt','import/VariantSummaries.txt','import/ClinActionEvidence.txt', 'import/VariantGroupSummaries.txt']
rake aborted!
Don't know how to build task 'civic:import[import/GeneSummaries.txt,import/VariantSummaries.txt,import/ClinActionEvidence.txt,'

We've been punting on this for quite a while. ICGC,COSMIC etc. could be a good source for displaying information.

Looking at views in the CIVIC interface, the few spots where casing is not consistent are a bit jarring to the eye. In particular, on import, or when we query and display options from an external API, can we convert disease names to Title Case? Also can we similarly convert drug names to Title Case.

Note that in both of these cases there may be diseases that are like 'AML' or drug names that are like 'PLX4720'. We don't want to lower case any of these letters.

So what I really mean, is to make the first letter of each word upper case, and leave the rest of the word alone.

Google, ORCid?

Search API endpoint should support diseases and drugs in addition to genes and variants.

When I merged in the coordinate information, I made a mistake and we lost the leading zeros on a handful of DOIDs again. This resulted in evidence items without an associated disease (18 to be exact).

If I add an evidence item following the example documented in the interface (latest pull of everything). I am able to approve this new entry in the admin interface. Then I get an evidence item that appears in the UI and for the most looks correct. But the drug value remains blank (even though I added one).

Related to #59, since the admin interface only shows a subset of values for an evidence item, I can't tell if the drug was actually entered in the database successfully and just isn't display or whether it was not captured at all at the time of entry.

If I try to edit the evidence item and add a drug, that also doesn't seem to work.

Add MIT license.

Maybe this should be an admin only privilege, maybe not. But even for our quick corrections, it'd be nice to be able to edit each attribute. Maybe this is a client side issue.

Include coordinate support in the importer, endpoints, and admin panels at the variant level.

Took a stab at this. Sent you an email outlining my steps so far.

Plz

Recent comments are fine, but we definitely will also want things like:

• Recent evidence item submissions
• Evidence items waiting on admin acceptance
• Evidence items that have failed and require manual intervention
• Daily stats (total new users, evidence items, variants etc)

Anything else that would be useful?

API responses should include "last edited by" metadata.

Is it true that all you have to do is run rake spec to run the test suite? Currently when I do that I get 4 failures, but I may be doing it wrong...

Come up with basic API documentation for the read-only portions of the API.