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

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)

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 ?

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 ?

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.

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

 In this case resize and reorder 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 ?

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 ?

13. A system integrated for requesting new terms

 A link to email the .obo maintainers ?

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

 I think this is just from the postgres tables, but if there's something else through exporting text files or something, let me know.

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

 I don't understand what this is.

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.

 This is the ``reset and query vs ``append query results different buttons ?  I've forgotten the issues involved in this, maybe something about reordering things and losing track of where characters came from.

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)

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.

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) ?