What I did this week (April 1)

This week I worked in the flow logic for cash payments, a user can only pay a pool if it has a debt, but he or she can overpay and then the pool owner has a debt with him. Pool owners can edit the debts and amounts of the users but only if the debt is high enough to surpass the pool’s total. I was working implementing stripe, in fact, we were able to receibe payments from users that registered in stripe (we were missing the frontend that would comunicate with stripe for the registration). Anyway we decided that we don’t have the time to finish this, there are other, more urgent things to do before the final delivery, so we will drop the credit card functionality from the app and focus in making better what we already have.

Advertisements

What I’ll do this week (April 1)

This week I’ll be working on the payment flow.

When a pool is marked as cash, users should say how much they paid and then the administrator should confirm the amount.

When a pool is marked as credit we will have to request the payment from the users and then send the same amount to the admin (we need to check if this is possible with stripe).

If the admin wants to update the amounts that the users have debt, we need to make sure that everything is kept within the limits of the initial costs (right now you can update a user’s dept to whatever amount). And maybe we should not be able to update the already paid amount (at least for credit), what’s already paid should not change.

Another nice to have would be to find friends on Facebook, instead of searching them by name or email.

That’s it.

What I did this week (May 25)

Even though we were on vacations I made a lot of progress. From the Cooper API now we can:

  • Use another invitation flow: there is an endpoint where we can find the pools that we are invited to, an endpoint to accept invitations, and another one to decline invitations, this way we can make sure that only those who are invited join and that you can also decline invitations.
  • Disabled sendgrid, we will delete the code that send emails, everything will be done in the app.
  • Friend requests, now we can have friends, send, accept and decline friend requests.
  • Login with facebook.
  • I put a server on Digital Ocean, started using travis for continous integration, everytime we push to the server repository, the app is built and the tests are run, if they pass we can merge, when we create a pull request to master and merge it, the code is deployed automatically to the Digital Ocean Server and restarted.
  • Now there is an https version of the server on port 3443, altough the http server is still running on 3000, this was because facebook only allows login from an https server. We may need to get a real certificate (I created and signed one by myself and the browser shows a warning).

What I’ll do this week (March 12)

The most important thing to do right now (in the api) is to be able to split the bill of a pool. I think the best way to handle this is, when the pool owner says that the bill should be splitted evenly, take all current users and divide the bill evenly, the problem is that not all users have joined by this time, all I can do is that when a new user confirms the invitation the API will update all the relations to users in the pool to fit the new bill split. When the ower sets the bill split to custom it I think it should be able to set the amount that invited users should pay, that will require me to add a new relation from the pool to users where invited users have a special relation with the label `:invited`, just so it can tell the user how much is he spected to pay and then he can accept or reject this invitation.

The TODO list is as follows:

  • Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
  • Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
  • The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
  • Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
  • We need a Facebook and Google login (I think this will be done by someone else).
  • User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

What I’ll do this week (March 5)

This week I’m not sure if we will be able to work in the project because it’s the Tarver Vertical (buuuh), but if we do, the most important thing to do right now (in the api) is to be able to split the bill of a pool. I think the best way to handle this is, when the pool owner says that the bill should be splitted evenly, take all current users and divide the bill evenly, the problem is that not all users have joined by this time, all I can do is that when a new user confirms the invitation the API will update all the relations to users in the pool to fit the new bill split. When the ower sets the bill split to custom it I think it should be able to set the amount that invited users should pay, that will require me to add a new relation from the pool to users where invited users have a special relation with the label `:invited`, just so it can tell the user how much is he spected to pay and then he can accept or reject this invitation.

The TODO list is as follows:

  • Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
  • Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
  • The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
  • Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
  • We need a Facebook and Google login (I think this will be done by someone else).
  • User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

 

What I did this week (February 26)

Last week I was able to finish with the first bullet point from the list I wrote in the previous premortem.

  • Search pools and users, that implies that I need to create a way to query a regular expresion or at least the begining of one of their string properties. I also need to filter the pools by its `public` property.

This is an important functionality because now we as users are able to search for pools to participate in and search users to invite them to the pool. Right now you can query for pools by name and users by name and email, but only in the web API.

I also corrected a lot of bugs that I found, when I’m testing new functionality I find bugs in old functionality that should have been noticed before, but just because there are no tests it all depends on us to find these bugs, Marco has also found a couple of bugs when testing with android. It seems like unit tests are more and more necessary as time passes by, as it is hard to keep track of everything that I’ve written and not tested.

Estefy created the landing page. And marco is working in the mobile application.