

--> when adding a test, values should be no-values, not default values


--> make sure when we create new scores we also update parent-child
    relationships, etc.  and remap them when we submit.

--> first cut at permissions.  on login, are we an admin?  on loading
    a patient, do we have write permission?
--> dbview cleanup
--> add test
--> implement forms flag and other flags
--> how would I create a field (e.g. in a form) that references a
    patient or session?
--> interface for editing a patient -- maybe dbview can shift a view
    into edit mode by calling client->requestEdit(patientid)
--> interface to edit a patient list -- change its name, add/remove
    patients, edit notes
--> interface to view/add contact notes, including a quick contact
    that should be indexable with an arbitrary field (when it turns
    out to be unique).  need client->addcontact(), getcontacts(), etc.
--> forms -- open up special views of tests in user's dbpatient record

use the "userdata" tag to indicate tests that are for user data, not
  patient tests.  then treat forms:*, message, and contact specially.
  note that we have to have some concept of recency -- we can't load
  all of a user's contact history on every login, because it will be a
  lot of data for some users.  same with forms probably.  maybe just
  send pending forms and the 50 most recent contacts.

server info to send over when we log on: total number of patients, new
  patients since your last logon, db name (editable by su), db motd
  (editable by su), list of fields sent with search results, including
  search result string template (editable by su), current id (for
  debugging only)

user info to send over when we log on: highest patientid on last
  logon, all forms (i.e., all user test data)

user info to keep client-side: window positions, server name/port

main menu options: create list from new patients; add new patient

DONGBO:
--> need a special function to get a patient's brief info, for
    displaying search results, adding contacts, etc.
--> additional info to come over when connecting to server
--> need to figure out a way to know how many *new* patients, probably
    by using highest patientid
MORE DONGBO:
--> contacts are stored in USER data
--> need user id and other DBuser info on logon
--> make sure when we request information from the server, it only gives it to us if we're
    entitled.  e.g., users can request their own user records, but only the admin can request
    arbitrary user records

when we close a database, we need to know if it's the last window (in
  which case it should stay open but empty) or not (in which case it
  should just close).
get qt3 compatibility stuff out of the qtwidgets directory
my code assumes that when we create a new test, its root scorevalue is
  given 0 as a parent.  make sure this is always true.
we should also make sure we have a sessionlist entry for all sessions
  repreented in sessiontests
we also need to know that all root level tests are children of "" in scorenamechildren

when we submit new scores, we need to first grab the changes from the
  interface and copy them to the dbscorevalues, using a getValue()
  method that passes the scorevalue by reference.

when we submit, we also need to submit new session info as well as
  newly deleted records




implement the scorename arguments min,max,places,default plus the old
  ones as appropriate.  dbview has the scorename record when it
  creates the widget.  it can choose to honor them or not, as
  appropriate, when it creates the widget.

--> get test instance links working by added item data to test table
--> do we need to worry about limits on map sizes?  how large are the
    structures we're putting in maps?
--> make sure fields with unset values are not shown in default view
    unless neverhide is set
--> need to be able to click on a session and get a test list, then
    click on that test list and get the scores
-> make sure when we submit we also submit f_deleted flagged records
    for deleted fields, and make sure we also submit all of the fields
    marked f_dirty.

need to come up with a coherent policy on how to handle values in the
  database for which there is no scorename record

brain image auto-sizing
selective showing/hiding fixes
dbview forms mode
new patient display
special dbview widget for adding a new score (special tab) either to a
  session or generally

add text to dbschema on how/when to lock patient access

when we click the add new XXX button, we add the relevant field (even
  if it's a stub) to the enclosing layout.  so we need the enclosing
  layout, parentid, and nameid.  in all views, we can look for the
  add_buttons that have the same scorename and parent, and add it
  there.  this doesn't solve the problem with "mostrecent" fields.

NEW DBVIEW BUTTONS TO ADD:
  add new test (opens up a box to select test, then creates a tab)
  add new session
  add new contact
FRONT PAGE STUFF:
  pending forms
  unread messages
  add new contact


+----SCORENAME FLAGS---------+-------------------+-------------------+
  min,max
  places (decimal places or lines)
  default
  static (takes default value at creation)
  leaf,defer,searchable,repeating,dropdown,editable,neverhide,customizable
  form (this test is a form (user score), not a patient score)
+----------------------------+-------------------+-------------------+



+----MESSAGES----------------+-------------------+-------------------+
message stub userdata repeating
message:date datetime
message:from userid
message:to userid
message:message text
+----------------------------+-------------------+-------------------+

+----CONTACTS----------------+-------------------+-------------------+
contact stub userdata repeating
contact:date datetime
contact:patient patientid
contact:notes text
+----------------------------+-------------------+-------------------+

+----FORMS-------------------+-------------------+-------------------+
A form type, like a post-test summary, is a special kind of test that
has a userid instead of a patientid.  When the administrator creates
one, it's added to the scorevalues table.  A form view is just a view.

When a user logs on, we get all that user's "patient" data.  We find
  the ones that are children of the special stub forms.  check their
  dates.  We make a list, put it in a widget, and if the user clicks
  on the right thing, we open up a dbview with appropriate
  permissions.

A form is implemented as a test with an extra flag or two set.  To
give someone a form, the administrator creates a form with permission
for the user.  The form may have a deadline, which is just another
field in the test, albeit one we may treat specially.  Users can't
delete fields from the form.  When a user logs on, all of their
unfilled forms should be displayed, with a warning for late ones.

Example: post-test summary

forms stub forms
forms:posttest repeating
forms:posttest:notes_from_coordinator text default "please fill this out"
forms:posttest:deadline date
forms:posttest:experimenter string default "your name here"
forms:posttest:date date
forms:posttest:payment stub repeating
forms:posttest:payment:for string
forms:posttest:payment:amount string default "enter amount paid here"
forms:posttest:tests test_type customizable repeating
forms:posttest:payment_for_that string default "enter amount paid here"


+----------------------------+-------------------+-------------------+




+----------------------------+-------------------+-------------------+
--> to detect neuronames, we can pre-identify them before laying out
    the text.  apply some special style.  then when we get a
    double-click event or something, we can reconvert the position
    into the right name.  convert names by finding bracketed text, and
    searching for the best match in db.
--> need a brainregion type that allows us to select a brain region
    from one or all namespaces in our NN database (how big is it?)
--> missing views: neuronames view?
+----------------------------+-------------------+-------------------+

--> when we lay out a stub with no filled-in children values, or we
    click new, we need IDs for the new values.  we also need to know
    that the stub itself should be submitted as a new value.

--> when adding a test to a vboxlayout, if we have an existing and
    immediately preceding gridlayout, we should use it


--> should a boolean stub take a boolean value?



--> play with some test data that has multiple instances of certain
    fields (i.e., multiple index).  also various kinds of illegal
    data, like repeating data for non-repeating nodes, fields that are
    long since gone, etc.


view test/score flags:
  mostrecent (show only the most recent)
  sessioninfo (show session info before ata)


--> when a patient is opened with write access, the server should
    maintain a set<int32> that contains just the patientids of those
    patients who are currently opened with write access.  check this
    list when a request for write access comes in.  make sure we clear
    any held locks when a session disconnects.  if the server quits
    for any reason, all sessions are terminated, so we don't need to
    keep track in persistent storage.

when a stub has no instances and is repeating, we don't put anything
  in its frame.  if it's not repeating, we add its (possibly blank)
  children.  if it is repeating, then we defer adding the children
  until the user clicks "new."

--> do we want "mostrecent" or "mostrecentsession?"  the latter would
    find the most recent session in which the score appears and
    present all values (repeating or whatever) for that score.  the
    former...  it's not clear, but conceivably it might just find the
    most recent value set?  that would be silly, because it would give
    us a corrected value for an older score.





RANDOM IMPLEMENTATION NOTES
--> to find all of a patient's static tests, retrieve the list of
    scores with session 0 and parent 0
--> to find all of a patient's non-static scores, find all of a
    patient's sessions, then tests, then scores.  or just tests with
    parent 0 and session nonzero.

NICE FEATURES NOT ESSENTIAL FOR INITIAL RELEASE

--> PROJECT NAME: the database needs a name that won't conflict with
    other brain/neuro databases that have nothing to do with human
    subjects recruiting and testing.
--> need a way to have a "do not contact until..." field that does not
    get displayed unless the date is in the future.  easiest way would
    just be to let admin unset the date when it's not in use.  also
    nice if we can format the field splay in some kind of emphasized
    color.  perhaps we could allow a format string for a given field.
--> tree view of all static and session-based scores
--> privatize dbtype::values, use accessors in case we want to change
    the structure later
--> need policy-based way of deciding if screens are printable for a user
--> can we accomodate special tables for user-specific notes on a
    patient?  can this be created automatically?
--> non-editable combo box items probably still need a way to see the
    list of static choices
--> maybe need a new layout option for "subtest" so that we can lay out
    (e.g.) demographics without actually laying out the "demographics"
    label and indenting
--> if the same scorevalueid appears twice in our view, when one is
    changed the other needs to change too.  just traverse the list and
    call setvalue, then copy the flags, then updatestatus.  or maybe
    copyvalue().
--> replace DBView::layout_banner with a layout_label method that
    calls boost::format, providing automatic arguments for printable
    date, M/D/Y H:M:S, username, etc.  plus the user can add
    additional string entries for db field values.  needs to call it
    multiple times so that we can include spacers probably.
--> htmlviews: a view can also be a chunk of html, with the
    understanding that certain preprocessing macros will be expanded
    to provide things like the username, time of day, fields from the
    database, iteration over repeating fields, etc.


