philipxjm / steward Goto Github PK

Look okay for 1-day & 5-day but get cutoff for anything longer than that.

When calculating unrealized gains for the first time, I believe we're loading in ALL data for that stock, even if it isn't all going to be used. Might be better to load less allowing for a quicker return? Also, I think this issue may be related with #36

Shorten market cap, put together ask/ask size, etc.

Make a handler that given a portid returns transactions as objects

[{ticker, transaction amount, time}]

Noticed that the 5-day graph only showed 4 days worth of data. Might just be because its a Sunday, earlier days get cutoff? Pretty sure its an API not a graphing issue, but maybe something to look into.

Not sure this would be easy but it'd be cool. Adding as a possible (but unlikely) enhancement

When you nuke quotes.sqlite3 and then generate an unrealized gains graph, it is different then the graph show on future reloads. However the graph doesn't look totally wrong either. Weird bug, I think it has to do with how prices are initially loaded when getting priceData for the range. Adding @mcrob23 to this since he wrote a lot of that backend stuff.

BAC shows null ask and bid

Fewer points should be displayed for these to speed up render/load time.

I have other models built in data/technology but none of those stocks return a prediction, just null.

Given a pool return the leaderboard as
[{Name, Profile Pic, Balance}]

Right now it doesn't seem fully functional, should return 4 digit code but I don't think it does.

This prevents the user from adding a stock to his portfolio from more than ten years ago in a past transaction and also limits us to showing at most ten years worth of data on the stock's graph page.

Full company name, sector, etc. I think all this info is available from the YahooFinance API

When the server is restarted and a user navigates to the home page, GoogleAuth automatically runs the login. Because of the way this causes the home page to flicker and refresh a couple times, I think it'd be better if it just stayed logged out, allowing for a more controlled log in to occur. Assigning @kjin97 since he did a lot of the log in stuff.

Definitely not urgent, but we should probably update API.md (or delete it).