Phenote cgi wish list

The following functionalities should be integrated into the new phenote cgi:

1. Term info panel (which displays info on the paper object, allele, ontology term etc.)

2. Annotation editor (with multiple tabs)

3. Annotation table

4. Retrieve function

 no OR
 use filter for AND
 all retrieves are append retrieves.
 new annotations always blue.
 each retrieve a different color (alternate with 2 colors like green and yellow) with a retrieve number
 if a retrieve would get something that is already there, don't get it, but append a retrieve number and change the color to a 4th color (purple)
 don't need colors or counts with edits always update postgres on the fly and the table display always matching the database.  use filtering or column sorting.
 sorting of retrieves in filtering.
 no read-only annotations, can always open another browser.
 

4.1. Clear function to start over with a clean slate. (file new)

5. List fields with the option to delete invidual terms with a 'del' radio button

 If the sample I sent out is not this, let me know, otherwise it'll be just that (see below about obsolete fields issue)
   JF: Let's stick to one you used for the online allele submission form.  Input box with auto suggest, forced values only, no toggle, del button, no add button.

  RK: talks to Sanger - try to get a weekly dump of wbgenes with obsoletes. 

6. Edit radio button feature that provides you w/ a pop-box to insert or edit large amounts of text

 Why a radio button instead of a normal button (or link).  We can do a popup window like phenote does, but would an input field (line) that on focus (when it gets clicked or tabbed into) switches to a large expandable textarea (like the curator_first_pass fields) work just as well ?
  For allele phenotype only have some fields that toggle between input fields and textareas on focus.  (no buttons)

7. Spell checker (Google has come out with a fancy spell check code that checks for both spelling error and context)

8. Autopopulating a field based on the contents of the another field. (eg: autopopulate gene name field based on allele object field).

 How would you want this to work ?  Switching one field toggles another field that is read-only, or can you edit the second field, but if you switch the first field it re-switches what you manually changed in the second field ?
 read-only, maybe some fields have a "fix wrong autopopulate" field that overrides the read-only.

9. Ability to configure/customize the panels according to preference

 Yes, but it'd help if we were clear on what panels, and how you'd like them to be customizable.
 Default config, 3 frames in single window, always have only one window.
 possibly also have 3 frames in a row config.

10. Ability to customize the column arrangement in the annotation table

 In this case resize, reorder, and sort by columns.

11. Incorporate Simple Filter and filter based on the individual field

 I've forgotten what we decided on how filtering would work, I remember talking about a lot of different methods.  Simple filter works on all fields, not just current field ?  Individual field filtering just displays characters with literal matches on that field ?
 Simple filter -> text match on any field
 Field filter -> text match on specific field (includes query filter)
 or filtering by | e.g. dpy|egl
 2 sets of filters, each with field drop-down, text, autofilter onKeyUp
 

12. After hitting commit, it gives you a summary of the following counts: Total number of alleles/rearrangements/transgenes per paper. Total # of phenotypes/ paper. Total number of object-phenotype connections

 Is this for allele-phenotype phenote only ?  Yes.
 pop-up results.
 characters can only have one paper.  phenotypes can only have one value (not list)
 foreach paper :
    count of unique alleles, count of unique rearrangements, count of unique transgenes.
    count of unique object name-phenotype connections, meaning characters (rows) because all characters must have object name and phenotype.
 total count of unique object name-phenotype connections, meaning characters (rows)
 total count of unique object names that have NBP (even if there's an append retrieve, everything from annotation table)

13. A system integrated for requesting new terms

 A link to email the .obo maintainers ?
 No.  Stuff goes into postgres.  Other CGIs from other curators can see that, and do stuff, that also affects phenote postgres tables.  (allele-phenotype)

14. Retain existing pipelines to Mary Ann's, Wen Chen's and Gary's cgi

 This is just from the postgres tables like 13
 

15. Auto update date for GO form (must be editable esp. if it's a minor edit)

 Date and Curator from login are auto assigned to new characters or duplicate characters.
 Queried stuff keeps DB curator and date.

16. When actively curating two or more genes it would be nice if a retrieve query did not erase the previous annotations from the annotation table. Maybe the results of the new query could be displayed in a separate window? if there is a fear of deleting or changing something by mistake.

 See 4. (retrieve)

17. Curator login

 How would this work ?  Fill in the curator-drop with that curator by default, but when querying values use the postgres curator for that character and still allow that character's curator to be replaced (but not doing that automatically)
 on query use DB curator.  on duplicate use login curator.  on new character assign login curator.  if querying characters without curators, leave them blank.  allow field to be editable.

18. Mandatory Constraints on certain fields... dependent on the configuration

19. Incorporating results of Textpresso searches into cgi form.

 To unify the GO curation process, would it be possible to have a module or panel where the weekly Textpresso search results are deposited and could be curated just as they are now from the ccc_curation cgi?
 Perhaps also include an option to see the sentences in a PDF.

20. tab files.

  Save tab file with headers, import from headers ;  if names of headers have changed, then this breaks. no tab files, datatable always reflects postgres.

Questions : 1. Obsolete .obo terms / .obo fields should be forced to be in the .obo. Currently .obo fields's values have to be in the .obo, which is good because you can't enter invalid values, but it's bad when obsolete terms are not tracked because invalid values can't be queried. Do we want to properly track obsolete values and have restricted ontology, or do we want a free field with autocomplete that stills allow non-.obo terms in there (and potentially lets wrong data in the database) ? see #5 above