It only shows them as loading

We'll likely need to create separate repos rather than have the api and frontend in one repo.

I'd probably split them into:

• scoreboard-api
• scoreboard-ui
• scoreboard-deploy

It looks like the sqlite3 package isn't installing. We also are no longer using sqlite3 so this should be an easy fix, but not urgent as we're still targeting node v8.

Error from npm i:

<details>

It leaves an open white space if the edit count spans only a year

Will re-use cards from Campaigns page

Changing your country in edit profile does not work

The search icon in the search box in users page is missing

I get this error on and off:

  Rejected promise returned by test. Reason:

  Error {
    message: 'ECONNRESET: Connection reset by peer',
  }

  Test.assert (node_modules/supertest/lib/test.js:165:15)
  localAssert (node_modules/supertest/lib/test.js:131:12)
  node_modules/supertest/lib/test.js:128:5
  Test.Request.callback (node_modules/superagent/lib/node/index.js:728:3)
  ClientRequest.req.once.err (node_modules/superagent/lib/node/index.js:647:10)

error Command failed with exit code 1.

here's an example: https://circleci.com/gh/developmentseed/scoreboard/259

Tests will run fine locally and it seems like 50% of the time will fail on CI.

There's a delay when clicking on links, I suspect due to server side rendering taking a long time. We should improve the performance by caching SSR'ed pages and measuring performance.

After switching to Lerna heroku deployment of the API only is a bit more tricky. This seems to be a good solution of handling a deployment of an app located in a subdirectory: https://jaketrent.com/post/deploy-lerna-packages-heroku/

This happens for all campaigns

Draft schema:

user ID of assignee
Campaign ID
user ID of assigner

This will have a many:1 relationship with the users table and a many:many relationship with the campaigns table

at appears as blue

See http://localhost:8181/campaigns/#nctx

getLastEdit in

edit_times in the API response (api/users/<id>) only includes dates (no timestamps), so this will be misleading if the last edit is in the window for which distanceInWordsToNow renders dates in granularity smaller than days:

{
  // ...
  "records": {
    edit_times: [
      // ...
      {
        "day": "2018-09-21",
        "count": 2
      }
    ]
    // ...
  }
}

Compare to

Now that we have attainable badges given by the server 12694e9 we can now split badges depending on the person logging in. Now we could build a dashboard with "badges to earn" and move them off of the public profile @sethvincent

I think that tasking manager should not be coupled to scoreboard tightly. We should move towards the concept of "Adding a task" and we could add tasks from multiple sources, such as a TM2 or a TM3 instance. These tasks could then be assigned to teams.

#20 adds docker as a dependency for development. While I understand using docker for less friction in deployment, my opinion is that it should be optional for development work.

Should the documentation contain instructions for setting up a database without docker?

With the following methods available:

1. GET: given user ID, returns all tasks [self-]assigned to a user
2. POST: given user ID and project ID, adds that project to that user's to-do list*
3. DEL: given user ID and project ID, removes that project from that user's to-do list

* Later, this will also take an additional assigning-user ID so that we can allow team admins to assign tasks to team members

NOTE: Tasks here means assigned projects, not individual task squares

The calculation of daysInRow has two parts:

1. sequentializeDates creates an array containing an array for every sequence of consecutive dates
2. findLongestStreak finds the longest array and returns the length

An error is being introduced in step 1, because all days are being put into a single array. Thus the array of arrays passed to findLongestStreak is just an array containing a single array, and the length of that array is the the total number of days mapped.

So that, rather than the highest number of consecutive days mapped, is being returned as daysInRow

I have started a branch which contains most of the code to move tasks out of the database, but it needs some improvements, namely

1. Caching the TM 2 responses since the 100-item page size makes calls to that API slow
2. Pulling all projects from TM 3. This code just pulls 14 or so results at a time -- though this will likely be fixed in another branch before we return to this one

Right now the api and frontend use different eslint rules. I'd like to make them match.

I am able to successfully run tests when I run the database locally. When I run it with docker, I get the following:

lerna ERR! yarn run test stderr:
createdb: could not connect to database template1: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
dropdb: could not connect to database template1: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
error Command failed with exit code 1.

lerna ERR! yarn run test exited 1 in 'scoreboard-api'
error Command failed with exit code 1.

the docs were used to be accessible at /docs. I think we should make it accessible at /api and /api/docs

After changing

Proposed change:

diff --git i/api/package.json w/api/package.json
index b503fb1..f92bc3e 100644
--- i/api/package.json
+++ w/api/package.json
@@ -25,6 +25,7 @@
     "@heroku/foreman": "git+https://github.com/heroku/node-foreman.git",
     "body-parser": "^1.18.3",
     "compression": "^1.7.1",
+    "cors": "^2.8.4",
     "express": "^4.16.3",
     "express-boom": "^2.0.0",
     "express-promise-router": "^2.0.0",
diff --git i/api/src/index.js w/api/src/index.js
index d8b9cdf..7dad586 100644
--- i/api/src/index.js
+++ w/api/src/index.js
@@ -4,6 +4,7 @@
 const express = require('express')
 const bodyParser = require('body-parser')
 const boom = require('express-boom')
+const cors = require('cors')
 const session = require('express-session')
 const compression = require('compression')
 const YAML = require('yamljs')
@@ -24,6 +25,7 @@ const { passport, authRouter } = require('./passport')
 const swaggerDocument = YAML.load('./docs/api.yml')
 swaggerDocument.info.version = pckg.version
 
+app.use(cors())
 app.use(bodyParser.json())
 app.use(compression())
 app.use(boom())

I am reposting from #38

This line in https://github.com/developmentseed/scoreboard/blob/master/frontend/src/containers/Dashboard.js#L141 (and others around the app) does not make sense when hosting a public version of scoreboard. We should rewrite localhost:5000 either:

• Rewrite APP_URL on the server and render the page on the server (this is the simplest logic)
• Create a frontend REACT_APP_URL that replaces this at build time (this is the simplest fix, but requires two environment variables, APP_URL on the server and REACT_APP_URL on the frontend) cc @sethvincent

The following error results from trying to run yarn build, however yarn dev runs fine

SyntaxError: /scoreboard/pages/_app.js: Unexpected token (65:6)

return (
    <div className='App'>
    ^

I think there's a missing yarn migrate (from api/) step in the README...

When running lerna at the top level, if there is an error in the API and it crashes, lerna does not report any errors or exit.

I started using unistore for async actions in the dashbaord.

Let's start using it in other components/containers as well.

Sidenote: unistore is almost exactly the same as redux, but requires less boilerplate code and is a smaller file size. It's pretty cool.

Usage is the same, except actions and reducers are simplified down to just actions, and there's no need to use middleware to do async actions. Moving to redux would be easy, but probably not necessary.

This error appears on all pages:

We have a number of places in the UI where we need to provide better errors based on responses from APIs.

Tasks in Scoreboard

Task Attributes

For each page of tasks pulled from the API, the following will be displayed:

• Name of task
• Percent completed
• Percent validated
• Priority

The following will also be used and/or provided:

• GeoJSON
• Link to task

Note that for each of the first four attributes, we will need to make a separate API call since the only attributes provided in the basic search is the Project ID and priority.

For now, we will follow the task manager's example of:

• Showing the most urgent projects by default
• Displaying 14 results per page
• Allowing users to search projects by name, priority, mapper level

Open Questions

• What other data do we need to pull for the project page (as opposed to the card)?

Right now scoreboard has a list of users with metadata and renders read-only users. We will be moving scoreboard to a login system. This has a few implications:

• Can stats be viewed by non logged in users?
• Are there different user permissions?
• Do we need to calculate stats for users that have never logged in?
• Do we have a public vs private profile where certain stats are only available to the logged in user?

It would be good to talk through these issues @ricardomestre @geohacker @scisco @alyssadelaine

Right now there's just a 404 error