overview / overview-server Goto Github PK

Is this a dup of #44?

Figure out how to get and deal with Document Cloud credentials.
Return list of user projects
Create new Overview project from Document Cloud project (kicking off worker process)
Associate trees, nodes, documents with document set (project?)
Are there any issues with sending document cloud credentials to worker process (cleartext password in our database)?

1. List of DocumentSets
2. "Import new DocumentSet from DocumentCloud" button

List document sets associated with user
Clicking on document set leads to tree view
Do we list all document sets?
What other operations do we need to support? Delete?
Is "Document Set" the right term for users? "Project" might be an alternative.

So that Adam can code tree

Create Heroku server with worker dyno
Documented process for deployment to staging server
Documented testing process
Can we do clean install (eg. wipe out Database)?

I'm supposed to be able to do this (and the Play framework implies that I can):

<script type="text/javascript" src="javascripts/main.min.js"></script>

However, that doesn't work. Why?

Here's what Play can do:

1. Translate CoffeeScript to JavaScript
2. Concatenate JavaScript files

Here's what it can't do: both.

However, it's in the pipeline for Play 2.1. https://play.lighthouseapp.com/projects/82401/tickets/103-commonjs-should-work-for-coffeescript-files

Here's my plan: I'm going to put all 50 includes straight into the HTML. Later, when Play 2.1 comes out, we'll migrate to it and I'll do things The Play Way.

Upside: I think it'll be straightforward to migrate from Hooper-solution to Play-solution when the time comes

Downside: We depend on Play 2.1 and we're forced to migrate to it (or fork it)

Alternate solution: If need be, I can hack the build system to do something more convoluted.

We'll use one of these values to order /documentsets/index correctly. We should keep the other two just in case.

Client: gather a log of what the user is doing
Server: store it
Server: analyze the log
Client: display the log and/or analysis

Model redesign needed

Somewhere on the wiki

Tests in NodeTest andTreeJsonWrapperSpec had to be commented out because they started to crash once I added a call to "refresh" in Node.java. The cause is probably a bug with Play, triggered by using multiple test starting up an Application (see https://groups.google.com/d/topic/play-framework/fQsGPiC_HAw/discussion)
The issue is supposedly fixed in Play 2.0.2.

Protect all routes with authentication.
Tests for same.

In worker. Probably with Future.select()

was: bug, viewDocumentSet() is no longer async.

commit 1eaf766 made Application.viewDocumentSet() non-async. See comment along with the commit on Github.

For viewing one document, in an iframe

Perhaps VMs, with a setup page

LogEntryControllerSpec uses an Around trait that makes SQL calls to cleanup the database. If all database calls occur in a transaction which gets rolled back at the end of the test, extra cleaning of the database should not be necessary. Removing the SQL calls leads to failed test however.
If possible, fix so it follows the pattern of other tests:

import helpers.DbContext
...
"some test case" in new DbContext {
  ...
}

Model redesign needed for more efficiency

after running play cucumber, the test database is populated with data (see nodes and document tables, for example), breaking the unit tests.

Gives a document list from a selection specification

(for making selections)

We'll have to define use cases and pick our strategy. Will it be a "group" thing with "managers", or a "share my document set with others" strategy (a la Google Drive)?

Client-side: log clicks and periodically send a list to the server
Server-side: store the logs, and retrieve them as HTML or CSV, filtered by DocumentSet and/or User.

We haven't talked about this...

Design user account database
Return error if account exists
Create new account if it doesn't exist
Design and document method for storing passwords and personal info securely
Use email address as account name? What other info do we need?
Do we need verification of account creation?
Do we need password strength checking?
Do we need change password feature?
Do we store document cloud credentials?

...but I don't know where it belongs. @thejonas, I know you're working on this.

From ONA User story:

The help screen gives basic instructions incl a video tutorial and links to further reading, plus contact information and a support request form which sends an email to the team.

Figure out which acceptance test framework to use
Run acceptance tests separately from unit tests

(look into Lucene library code for stemming?, tokenizing?, localization?, etc.)

We need to truncate all tables (or recreate the test database) before running unit tests, since they expect an empty database.

Port code from prototype

done:
Get documents associated with a query/document cloud query
Generate Tree

todo:
spare edge sampling

we're producing the tree in the worker, now write it to the DB

This has to be server-side. Otherwise, the client might tag a selection of documents and then wouldn't be able to un-tag (because un-tagging the newly-tagged documents isn't the same as un-tagging only the ones which were just tagged).

Decide what user actions are undoable
Save actions in Database
Undo last action
How deep is undo command stack and how long does it last? Do we have a session concept?
How do users initiate undo in UI?
Is there client side undo? Node selection and expansion for example.
What does browser back button do?
do we need redo?

Add/rename/delete on a selection of documents

Add a tag to a selection of Documents
Rename a tag in a selection of Documents
Delete a tag from a selection of Documents
Should there be a global tag rename?

under AP account, or new test account?

The errors happen often, and they look like this:

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[NumberFormatException: multiple points]]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:134) [play_2.9.1.jar:2.0.2]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:115) [play_2.9.1.jar:2.0.2]
    at akka.actor.Actor$class.apply(Actor.scala:318) [akka-actor.jar:2.0.2]
    at play.core.ActionInvoker.apply(Invoker.scala:113) [play_2.9.1.jar:2.0.2]
    at akka.actor.ActorCell.invoke(ActorCell.scala:626) [akka-actor.jar:2.0.2]
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:197) [akka-actor.jar:2.0.2]
Caused by: java.lang.NumberFormatException: multiple points
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1102) ~[na:1.6.0_24]
    at java.lang.Double.parseDouble(Double.java:527) ~[na:1.6.0_24]
    at java.text.DigitList.getDouble(DigitList.java:168) ~[na:1.6.0_24]
    at java.text.DecimalFormat.parse(DecimalFormat.java:1320) ~[na:1.6.0_24]
    at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1935) ~[na:1.6.0_24]
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1281) ~[na:1.6.0_24]

It's a bug in Play 2.0.2: https://groups.google.com/forum/?fromgroups#!topic/play-framework/uJXsYw1sOjg

We can fix it by upgrading to the next version of Play, when it's released.

...and document it!

• Run locally with foreman
• deploy to heroku with worker node
• Use play components (ebean, WS)

The SQL query at https://github.com/overview/overview-server/wiki/SQL for getting nodes in a subtree fails in the subtree has a depth < 6. The leaf nodes will not be included in the result, since they are not in the parent.id of any node.