wouterdeman / timesheet.service Goto Github PK

We only save one token per user but this currently limits the use of multiple chrome accounts which leads to multiple sync storages where tokens could be saved.
Currently a user would log him/herself out every time he/she switches the chrome account.

Solution: The service should be able to store multiple issued tokens per user (max 5?)

We now integrate with the oauth2 services from google so the timesheetmodule can authenticate our company accounts. These security services/features can be different for each use case we will build.

How will we handle more oauth providers, simple api keys, etc...
Is there an external partner/framework that can give us a head start ?

We should investigate and define a first meaning of geofencing for our tracking service. What basic features should be implemented to support the timesheetmodule?

The timetracker groups crumbles per entity and day. We should also add details about the entity. In our timesheet example we can add the email addresses and the first/lastname of a user. This allows easy queries and you should not have to lookup the entity id. This is the mongodb way so we are learning every day ;).

The user is asked of the locations should be saved
-> no -> nothing happens
-> yes -> the user can give the location a name (for example 'home office')

To save time we should have a basic build service that deploys our service to heroku (TravisCI ?)

We should be able to track the devices of an entity in a separate entitytracker. Device id, chrome id, ip address, etc...

This information should also be included every crumble so we can easily query on this data.

Simple solution: Hash in de client steken/hangen...

As seen on google maps, google is able to show poi's. We should investigate if we can retrieve them and use them for suggesting locations when user is at an unknown location.

The service now includes a number of features like entry posting, authentication, dashboard api, etc.. These should be refactored to seperate services and components each with its own unique meaning and responsability.

This is just step 1 in a continuous process.

Example:
Friso's known locations are Corelio and bITe office.
Friso arrives at the SD office. SD is not a known location for Friso but does exist in the locations collections (Wouter and Tim work there). The app promps to store the new location for Friso and informs him that the locations is already known as the SD office.

The service should require clients to authenticate when they send http requests.
A common solution for node seems to be PassportJS.

http://passportjs.org/

Instead of storing one longitude and latitude value for a location we store and array of them. So we can actually create a 'zone' on the map that represents that certain location. This is to prevent that when you go from one place in the building to the other side of the building (think of this as a very big building), both locations and times spent there are saved separately from one another.

Store which locations belong to which user.

Example:
Locations: Corelio, SD, bITe office
Users: Friso, Wouter

Locations for Friso: Corelio, bITe office
Locations for Wouter: SD, Corelio, bITe office

This will enable us start tracking how long (from when until when) a user was at a certain location

The timesheetmodule requires us to have a user concept that we can link to our entries. Our timesheet specific services could provide an api that allows registering users...

Grunt workon allows us to run a local server to develop.
We still need to work out the grunt default task (build) that should create a deployable and optimized build for production.

Enable logon with bite account. This story would enable us to then keep track of locations and time spend there by user

https://github.com/JerrySievert/node-date-utils

Adds a number of methods to the date object for manipulation. Can be used in the browser and inside nodejs

There are two possibilities I'm thinking off.

1. we update the time spent every x seconds/minutes for a certain user.
2. we check every x seconds/minutes if a user is still on the same location. If he is no longer there we update the time spent on location.

Both methods will give a margin of error equal to the time of the interval but I think we can live with that.

Maybe we can POC both solutions to see what are the up and downsides of each one and see which solutions fits best

Almost every device measures a certain accuracy when detecting its location (gps). We should also store this information or use it when handling location detection for example.