User:Rando/Donate v2: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
No edit summary
Line 38: Line 38:


=== Implementation Steps ===
=== Implementation Steps ===
<pre style="background: green;color: white"># Create new financial Model (done) </pre>
# <pre style="background: green;color: white">Create new financial Model</pre>
#
# <pre style="background: green;color: white">Migrate existing donate models</pre>

Revision as of 05:47, 18 December 2018

donate.noisebridge.net v2

donate.noisebridge.net (donate) is currently written in Ruby on Rails using rspec for testing.

Issues

  1. Very little of Noisebridge's other architecture is ruby.
    1. this creates a maintenance issue
    2. rails doesn't have the greatest reputation
  2. certain functionality is not available or exposed
    1. some critical-ish functionality like subscription cancellations is mention in the code but there is no way for the user to execute or know how to do it
    2. important financial reporting functionality is not available
    3. some nice to have functionality is available but not exposed
    4. the financial models are not aligned with good accounting practices

Implementation Plan

  1. Backend Implementation in Python
    1. Python is the best known and maintainable language currently
    2. using Flask
      1. Django was discussed and had some support, however, Flask is used in house
      2. Flask is growing faster the Django, though Django is still growing
      3. Flask is has more configuration options (can be negative)
      4. To increase support, a Flask class can/should be added to the current Python class schedule to recruit people to maintain architecture.
    3. APIs
      1. Stripe integrates with Python just fine.
      2. Paypal is just contructed links
  2. Front end uses unchanged/minimally changed migrated assets
    1. Donate does not require significant user interaction or front-end behavior implementation.
    2. Re-use of js/css/images/fonts from old doante site will used where-ever possible

The first goal is to get the existing functionality up and running with the same ui / look and feel. Once Complete, items from the road map will be added. However, the main difference is that the backend will use a contemporary model for financial data, which is based on transactions and accounts. This will support, among other things, double accounting and can be reconciled to other platforms and be a repository for all financial inflows and outflows.

Currently everything is a project and spending from the project is tracked elsewhere. this is because the account model is missing. An account is something like the Laser. Money is donated to it, and money is spent on upkeep. The balance in the account goes up and down. right no project balances are just the inflows, e.g. the donations. The amount never goes down.

Projects are implemented with accounts and they now have a goal. E.g. a project will have an amount to reach. Accounts are flexible and can represent any aggregated financial data.

The other difference is transactions. Any time money is moved into NB, in between accounts, or out of NB, a transaction is created. The sum of the transactions creates the entries for double accounting, and should alway sum to zero globally. This allows us to reconcile accounts / spending etc easily.


Implementation Steps

  1. Create new financial Model
  2. Migrate existing donate models