isaaccheng9 / fairsplit

A web application to split bills and track shared expenses in a group, with a transaction minimisation algorithm. Developed with Node and React.

FairSplit

A bill-splitting application to track shared expenses in a group, developed with Node and React.

Explanation of Transaction Minimisation Algorithm

We implemented a greedy algorithm to minimise the number of transactions required to settle the debts between all members of a group when the user toggles 'Smart Split'. The algorithm runs in O(n log n), where n is the number of users – this means that it scales well with the number of users.

A simple example of this algorithm is shown below. In this example, Alice owes Bob £10 and Bob owes Charlie £10 for a total of two transactions. The algorithm will suggest that Alice pays Charlie £10 directly, meaning only one transaction is required to settle the debts.

This may seem like a trivial problem to solve, but it becomes more complex as the number of users increases. The following diagram shows a more complex example when there are six users with six transactions between them. This is reduced to only four transactions by the algorithm.

Screenshots

Installation and Usage

Setting up the MongoDB Database

1. Create a file in the server directory with the name: .env
2. Open the file in a text editor (such as Notepad or TextEdit).
3. Add the following line to the file, replacing <uri> with the URI of your MongoDB database:

MONGODB_URI="<uri>"

4. Save the file.

Running the Server

1. Open a terminal window.
2. Ensure that you're in the root directory: fairsplit
3. Navigate to the server directory: cd server
4. Install dependencies: npm install
5. Run the server: node app

Running the Client

1. Open a new terminal window (separate to the previous one).
2. Ensure that you're in the root directory: fairsplit
3. Navigate to the server directory: cd client
4. Install dependencies: npm install
5. Run the client: npm start
6. Browse to the URL provided in the terminal window.

Running Tests

Running Tests on the Server

1. Open a terminal window.
2. Ensure that you're in the root directory: fairsplit
3. Navigate to the server directory: cd server
4. Install dependencies: npm install
5. Run the unit tests: npm test

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

For more information, please see the Contributing Guide.

fairsplit's Issues

Implement adding expenses with the user interface

Specification

• We already have the routes set up to create a new expense, but it isn't currently implemented in the UI.
• An idea for implementing this could be to trigger an overlay (similar to YouTube when you click Save on a video) when the 'Add Expense' button is pressed, which would have a form for the user to add the expense with the following fields:
  • title
  • author
  • lender
  • borrowers

Create a transaction whenever a user settles up

Specification

• Currently, there is no transaction displayed when a user settles up.
  • This makes it confusing, as it can seem like the expenses don't add up.
• To fix this, create a transaction alongside the list of expenses in the left panel.
  • For example, in the scenario below, user1 settled up £7.50, so it should have a fourth row on the left panel to reflect this.
    

Change 'Add Expense' dropdown to be more intuitive

Specification

• Currently, adding an expense is a bit confusing for the user.
• We should change the behaviour under the three states:
  • When the page has initially loaded and hasn't started adding an expense
    • Show only one button, 'Add Expense', which opens the panel
  • When the user has started adding an expense
    • Show a button, 'Confirm Expense'
    • Also show a minimal-looking up arrow on the right side to minimise it (see arrow in VS Code terminal panel, shown below)
  • When the user has started adding an expense but minimised the panel
    • Show a disabled button (greyed out), 'Confirm Expense'
    • Also show the same arrow as in the previous scenario, but a down arrow instead of an up arrow

Screenshots

Add a switch to toggle simplify debts

Specification

• The user should be able to optimise transactions using a switch to toggle on/off the algorithm implemented from PR #58.
• Alongside the switch, add a hint that briefly explains what the algorithm does when the user hovers over it/clicks it.

Add view to display all users in a group

Specification

• The user must be able to see all users in a group in a list, with each item displaying the username.
  • Sorting the list alphabetically would be good, but not necessarily required.
  • Displaying their firstName and lastName can be implemented at a later point.
  • We'll assume that only one group can be created at a time for now.

Implement a route to create a user

Specification

• The user must be able to create users so that they can form a group.
  • This only requires basic functionality – no credentials are required, just a username for now that acts as a unique identifier.
    • We can add a display name (firstName and lastName) at a later point.
    • We can also add login functionality for personalised views later.

Create unit tests for endpoints

Specification

• We need to create unit tests to ensure that our commits aren't breaking any features.
  • Look into implementing tests using a framework such as Jest.

Steps

• users.test.js – PR #73
• debts.test.js – PR #74
• expenses.test.js – PR #75

Create user interface for adding and viewing users

Specification

• To start with, we'll assume that only one group can exist.
• The user needs to be able to manage all users in the group, including the ability to:
  • Add new users
  • View all users in a group
• We need to create a new user interface to implement this. There are different approaches we could take, but an idea is:
  • Use a button below the list of members, which creates a component where you'll edit the name in-place.

Denormalise net user debts to optimise algorithm to minimise transactions

Specification

• As mentioned in PR #58, the algorithm for minimising transactions is currently O(k * n log n), where k is the number of debts, and n is the number of users.
• We can optimise the algorithm to O(n log n) by denormalising the user debts.
  • The algorithm currently spends O(k) time going through all debts and calculating the net debt for each user.
  • If we store this in a separate collection and update it every time a debt pair is updated, we'll save repeated work.

Create a database for storing records

Specification

• Create a database for storing records for users and transactions.
  • Research into whether SQL or NoSQL would be more suited.

Save current user to avoid having to change it again upon refresh

Specification

• Currently, we have to change the current user on the top right every time we refresh.
  • This detracts from the user experience, so we should look to save this via local storage or an alternative method.

Detect appropriate icon for expenses based on title

Changes

• Use semantic analysis of the title to determine what icon should be used for an expense.
  • Consider implementing this with a dictionary, where the keys are the keywords, and the values are the icon names.
    • This would ensure there are fast look-ups (O(1) time complexity).

Add support for unequal splits of expenses between borrowers

Specification

• We need to change the expense model to include the fraction/percentage of the expense that each borrower owes.
  • The type of the borrowers field could be changed from [String] to [String, Number] to represent the username and how much they owe.

Add summary of total owed by each person

Specification

• Add a summary at the top of the expense list showing how much is owed by each person in GBP.

Prerequisites

• Issue #23

Fix user creation not working in the user interface

Specification

• After entering a username, trying to click on the plus icon to add a user doesn't work (see screenshot).

Screenshots

Update user interface for multiple borrowers

Specification

• Currently, only one borrower can be added to an expense.
  • We need to add support for multiple borrowers through a sub-menu.
  • By default, this should assume an equal split between all borrowers (recalculate splits each time a new borrower is added).
• We'll also allow the user to set the exact amount owed by each person (not percentage).
  • Optionally, we could include a toggle to enable them to set the percentages instead.

Refresh total amount owed after settling

Specification

• After settling up, the total amount should update without the user having to refresh the page.
  

Update the debt for all borrowers when an expense is added

Specification

• At the moment, adding an expense doesn't affect any of the debt relationships between users.
  • Create/update the debt between the lender and each borrower when an expense is added.

Allow the lender to be an option as a borrower in the dropdown menu

Specification

• The user may find it more intuitive to add themselves as a borrower if they want to split an expense evenly (including themselves).
• Currently, the workflow for this is:
  1. The lender subtracts their split from the total amount they paid (which may not be a straightforward calculation).
  2. This amount is the expense that they input into the app.
  3. They add the other people who are part of the split.
• With this change, the workflow would be:
  1. The lender adds the total amount they paid as the expense in the app (no subtraction required).
  2. They add themselves and the other people who are part of the split.

Add user input validation for existing features

Summary

• User input validation is required for things such as creating expenses with unexpected field data types (strings in Amount, entries which are too long, etc.) and null inputs.
• We also need to add text wrapping or ellipsis for long usernames.
• Ensure that feedback is shown to the user for invalid inputs.

Examples of Unwanted Inputs

Improve responsive design for mobile devices

Specification

• The view on mobile devices needs improving, as it currently requires the user to side-scroll which is unintuitive.
• Investigate ways of improving the responsive design.
• A basic improvement would be to centre the FairSplit logo, move the user switcher to the top, and move the group members panel to the bottom of the page.
  • Top to bottom: FairSplit logo -> user switcher -> group expenses -> group members
• If it's feasible, we could look to have smarter switching between the group expenses and group members view.
  • Keep the FairSplit logo and user switcher elements static, and have a slide-deck style switcher between the group expenses and group members.
    • When the user scrolls vertically, it should switch between the two slide decks so that each view is fully displayed.

Screenshots

Fix settling up the full amounts on the front-end

Specification

• On the front-end, settling up the full amounts doesn't work and gets rejected for trying to settle more than the amount of the debt.

Refactor how debt is rendered when switching users

Specification

• With the recent changes to the backend in Issue 42 the client side needs refactoring.
  • At the moment debts are calculated on the assumption that there are two different debts per relationship.
  • Refactor logic to only account for one debt per relationship as per the changes in Issue 42

Create algorithm for minimising number of transactions

Specification

• Whenever there is an update to the debts, run an algorithm to recalculate the transactions required to minimise the number of transactions.
• The algorithm should minimise the number of transactions, not the total amount transacted, as this benefits users more.
• A heuristic may be preferred here, as finding the optimal solution may take too long – O(n!) time complexity to find all subset totals, where n is the number of people in the group.
  • An option would be to check only for exact matches between single amounts owed – O(n^2) time complexity, where n is the number of people in the group.
  • Alternatively, we could avoid doing this, but it's probably better to perform this check because it would cover a lot of common scenarios.
• Either way, we need to sort the balances of people in two lists representing debit and credit – O(n log n) time complexity using a heap.
• This would be useful for minimising the number of transactions which will be displayed under each group member (when expanded).
  • This will be covered in a separate issue.

Prerequisite Issues

• Issue #6

Relevant Research

• Algorithm to simplify a weighted directed graph of debts
• Splitwise is NP-Complete
• Determine minimum number of transactions to get the system to 'zero state'
• Algorithm behind bill splitting app

Add filter to only display transactions involving the user

Summary

• Currently, all transactions are shown, meaning the user must trust that the amount they owe is correct.
• Add a filter to only display transactions involving the user.
  • This means transactions where the user either lent or borrowed money.

Implement a route to create an expense

Specification

• The user should be able to create an expense in a group.
  • An expense consists of a creationDatetime, author, title, amount (GBP), lender and borrowers.
    • For now, all expenses will be split equally between borrowers.
  • We'll assume that only one group can exist at a time for now.

Integrate unit tests with CI/CD pipeline

Specification

• Integrate unit tests with GitHub Actions for automated checks as part of our CI/CD pipeline.
  • This will reduce the chance of user error in future development, as less onus is put on the developer to manually run the test suite.

Prerequisite Issues

• Issue #32

Simplify debts between two users when a new debt is added

Specification

• At the moment, there can be two debt records between a pair of users (X to Y, and Y to X), but this isn't necessary.
• When a user adds a new debt, the records should be simplified so that only one debt exists between the pair of users.
  • X owes Y £5 and Y owes X £50 becomes:
    • Y owes X £45

Add the ability to settle up with another person

Specification

• To settle up, there will be a dropdown menu of all users they owe and the amount, an input field with the amount they want to settle up (limited to how much they owe) and a 'Confirm' button to finalise it.
• There are two ways we could display the dropdown menu:
  • Display an overlay when the 'Settle Up' button is clicked
  • Display a sidebar (which doesn't blur the rest of the UI) when the 'Settle Up' button is clicked
• This will update the debt in the database by subtracting the amount the user settles up.

Improve user-friendliness of the interface

Specification

• The user interface has a few areas where it would be more user-friendly:
  • Lenders and borrowers should be selectable from a dropdown menu rather than using text input.
    • This prevents users from selecting users who don't exist.
  • Indicators for the lender and borrower are often truncated.
    • We should increase the size of the panel by using more of the empty space between the transaction list and the group members list, which would make this less likely to occur.
    • The indicators should display the full contents when hovered over.
  • Indicators for expenses with multiple borrowers are misleading.
    • While expanding the expenses provides clarity, it isn't obvious at a glance when an expense involves multiple borrowers, as it is displayed as if only the first borrower was involved (see top expense in screenshot below).
    • There should be a separate type of indicator for these expenses – perhaps it should say something like:
      • jack3 -> 3 Users
      • This would prompt the user to expand the transaction for further details.

Screenshots

Investigate into adding additional GitHub Actions for code analysis

Specification

• Additional GitHub Actions can be added for more thorough code analysis, such as performance analysis for size and runtime.

Switch amount measurement from floating point to integers

Summary

• The unit test for settling debt is currently non-deterministic, likely due to floating point arithmetic issues
  • Avoid floating point arithmetic by measuring currency amounts in integers instead of floating points
  • Switch the unit from pounds (GBP) to pence (GBX)
• See example of non-deterministic test runs here (screenshot below):

Test Code

  // Check whether we can settle a debt between two users.
  test("POST /debts/settle", async () => {
    const server = supertest(app);
    await server
      .post("/debts/settle")
      .send({
        from: "testuser456",
        to: "testuser123",
        amount: 50,
      })
      .expect(200);

    // Check whether the debt was successfully reduced by 50.
    await debtModel
      .findOne({
        from: "testuser123",
        to: "testuser456",
      })
      .then((debt) => {
        expect(debt.amount).toBe(50);
      });
  });

Update debts when a new expense is added with smart split enabled

Specification

• Currently, the debts are only updated when a new expense is added and smart split is disabled.
  • When smart split is enabled, the optimised debts aren't updated in the user interface, even if they have been calculated in the back-end and updated in the database.

Fix lender and borrower fields incorrectly being flipped when sending API calls

Specification

• The lender and borrower fields are incorrectly flipped.
• For example, in the following scenario, the expense created is a debt from user2 to user1, when it should be from user1 to user2.

Add view for group expenses

Specification

• The user should be able to view a list of all expenses in the group.
  • Each item should consist of the datetime, title, payee, and amount.

Add ability to expand a transaction to view the full details

Specification

• Currently, transactions display in a way that assumes an equal split.
  • However, this may not be the case, which results in misleading transaction listings (see below).

Track balances between users based on expenses

Specification

• We must track the amount of money owed from one user to every other user.
• To start with, we'll track this in a one-to-one relationship, with each document having the format:
  • from: user1
  • to: user2
  • amount: xyz (£)
• When adding an expense, the API will update an existing document if it already exists. Otherwise, it will create a new document as necessary (see below).
• This will be used for the list of group members, as it enables calculations for how much each member owes to one another.
  • For now, adding an expense will only ever increase a debt.
  • Debts will only be subtracted when a user pays off what they owe.

Deploy app to a hosting solution

Specification

• Deploy the app using Digital Ocean, Heroku, or other free alternatives.
• Provide the URL in the README for ease of access.

Update README to be more comprehensive

Specification

• The README is very basic at the moment. We should update it to be more comprehensive, including details such as:
  • Description
  • Deployment link
  • Screenshots
  • Prerequisites
  • Installation instructions

Refactor routes to use controllers

Specification

• To prevent the routes files from becoming cluttered and difficult to manage, we should handle the actions in each route with controllers.
• For example:
  • server/controllers/userController.js
  • server/controllers/expenseController.js

Fix the total amount the user owes/is owed for optimised debts

Bug Report

• When turning on 'Smart Split', the total amount the user owes/is owed isn't always updated correctly.
• This is likely caused by a missing await on when clearing the optimised debt model collection here.
• However, adding an await statement causes test failures:

isaac@MBP16 server % npm test

> [email protected] test
> jest --verbose --coverage

 PASS  routes/users.test.js
  Test for user routes
    ✓ GET /users (24 ms)
    ✓ POST /users (18 ms)
    ✓ GET /users/:username (6 ms)
    ✓ DELETE /users/:username (4 ms)

 PASS  routes/expenses.test.js
  Test for expense routes
    ✓ GET /expenses (20 ms)
    ✓ POST /expenses (24 ms)
    ✓ POST /expenses/settlement (6 ms)

/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/lib/operations/execute_operation.js:20
                return callback(new error_1.MongoNotConnectedError('Client must be connected before running operations'));
                                ^

MongoNotConnectedError: Client must be connected before running operations
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:89:11
    at maybePromise (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/utils.ts:518:3)
    at executeOperation (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:83:22)
    at Collection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/collection.ts:624:28)
    at NativeCollection.<computed> [as deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:202:33)
    at NodeCollection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/collection/node.js:90:21)
    at model.Query.Object.<anonymous>.Query.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/mquery.js:2661:20)
    at model.Query.<anonymous> (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/query.js:3211:32)
    at model.Query._wrappedThunk [as _deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/helpers/query/wrapThunk.js:27:8)
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/kareem/index.js:426:25 {
  [Symbol(errorLabels)]: Set(0) {}
}

Node.js v18.2.0
/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/lib/operations/execute_operation.js:20
                return callback(new error_1.MongoNotConnectedError('Client must be connected before running operations'));
                                ^

MongoNotConnectedError: Client must be connected before running operations
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:89:11
    at maybePromise (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/utils.ts:518:3)
    at executeOperation (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:83:22)
    at Collection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/collection.ts:624:28)
    at NativeCollection.<computed> [as deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:202:33)
    at NodeCollection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/collection/node.js:90:21)
    at model.Query.Object.<anonymous>.Query.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/mquery.js:2661:20)
    at model.Query.<anonymous> (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/query.js:3211:32)
    at model.Query._wrappedThunk [as _deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/helpers/query/wrapThunk.js:27:8)
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/kareem/index.js:426:25 {
  [Symbol(errorLabels)]: Set(0) {}
}

Node.js v18.2.0
/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/lib/operations/execute_operation.js:20
                return callback(new error_1.MongoNotConnectedError('Client must be connected before running operations'));
                                ^

MongoNotConnectedError: Client must be connected before running operations
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:89:11
    at maybePromise (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/utils.ts:518:3)
    at executeOperation (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:83:22)
    at Collection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/collection.ts:624:28)
    at NativeCollection.<computed> [as deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:202:33)
    at NodeCollection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/collection/node.js:90:21)
    at model.Query.Object.<anonymous>.Query.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/mquery.js:2661:20)
    at model.Query.<anonymous> (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/query.js:3211:32)
    at model.Query._wrappedThunk [as _deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/helpers/query/wrapThunk.js:27:8)
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/kareem/index.js:426:25 {
  [Symbol(errorLabels)]: Set(0) {}
}

Node.js v18.2.0
/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/lib/operations/execute_operation.js:20
                return callback(new error_1.MongoNotConnectedError('Client must be connected before running operations'));
                                ^

MongoNotConnectedError: Client must be connected before running operations
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:89:11
    at maybePromise (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/utils.ts:518:3)
    at executeOperation (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/operations/execute_operation.ts:83:22)
    at Collection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongodb/src/collection.ts:624:28)
    at NativeCollection.<computed> [as deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/drivers/node-mongodb-native/collection.js:202:33)
    at NodeCollection.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/collection/node.js:90:21)
    at model.Query.Object.<anonymous>.Query.deleteMany (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mquery/lib/mquery.js:2661:20)
    at model.Query.<anonymous> (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/query.js:3211:32)
    at model.Query._wrappedThunk [as _deleteMany] (/Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/mongoose/lib/helpers/query/wrapThunk.js:27:8)
    at /Users/isaac/Library/CloudStorage/OneDrive-Personal/Documents/Programming/Projects/fairsplit/server/node_modules/kareem/index.js:426:25 {
  [Symbol(errorLabels)]: Set(0) {}
}

Node.js v18.2.0
 FAIL  routes/debts.test.js
  ● Test suite failed to run

    Jest worker encountered 4 child process exceptions, exceeding retry limit

      at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js:211:21)

------------------------|---------|----------|---------|---------|-------------------------------------------
File                    | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s                         
------------------------|---------|----------|---------|---------|-------------------------------------------
All files               |   79.27 |    34.61 |   81.81 |   79.27 |                                           
 controllers            |   94.73 |       50 |     100 |   94.73 |                                           
  expense_controller.js |    91.3 |       50 |     100 |    91.3 | 10,18                                     
  user_controller.js    |     100 |      100 |     100 |     100 |                                           
 controllers/helpers    |   51.16 |    31.81 |      50 |   51.16 |                                           
  index.js              |   51.16 |    31.81 |      50 |   51.16 | ...9,43-44,53,65-74,93,96,101-107,119-138 
 models                 |     100 |      100 |     100 |     100 |                                           
  debt.js               |     100 |      100 |     100 |     100 |                                           
  expense.js            |     100 |      100 |     100 |     100 |                                           
  optimised_debt.js     |     100 |      100 |     100 |     100 |                                           
  user.js               |     100 |      100 |     100 |     100 |                                           
  user_debt.js          |     100 |      100 |     100 |     100 |                                           
 routes                 |     100 |      100 |     100 |     100 |                                           
  expenses.js           |     100 |      100 |     100 |     100 |                                           
  users.js              |     100 |      100 |     100 |     100 |                                           
------------------------|---------|----------|---------|---------|-------------------------------------------
Test Suites: 1 failed, 2 passed, 3 total
Tests:       7 passed, 7 total
Snapshots:   0 total
Time:        3.664 s
Ran all test suites.

Implement user switching in a group

Specification

• At the moment, the website just displays all expenses from a generic POV (not specific to any user).
• Account switching would enable things to be displayed specific to the user, so that the most important details are highlighted.
  • For example, we could show 'Outstanding balance' above the list of expenses to show how much the user owes in total.
  • We could also display some text below each member of the group stating how much they owe money to or are owed by that person.