When staff view list of accounts, they see the most recent day that the customer worked and the most recent day that the customer had a meal.

• link to join pythonforgood Slack team
• link to pythonforgood Code of Conduct
• reach out via Github or Slack before contributing

I would like to propose switching our styling over to http://tachyons.io/
I have been using Tachyons for some personal stuff, and as someone who hates writing CSS, it has been a lifesaver. I believe that switching will allow us to keep our styling simple, easy to update, and help us remain consistent with multiple contributors.

To complete this, you will need to:

• Include tachyons.css in our index.html
• Remove the existing CSS (bartercheckout.css)
• Replace all class names in the React component render() functions with tachyons class names

Sisters has a policy that barter accounts can't exceed $50. If someone tries to add a credit that would make the account exceed $50, prevent that action from taking place and present a message to the user about the limit.

It would also be good to prevent accounts from going under 0.00.

Suggested approach...

In the add and subtract methods of the BarterAccount model...

• add a check (i.e. if statement) to see of the operation would exceed the limit.
• if the operation doesn't exceed the limits go ahead and perform it
• if the operation would exceed the limit, throw an error

In the views that use the add and subtract methods...

• handle the limit exceeded error
• send an error message to the front-end if BarterAccount.add() or BarterAccount.subtract() fail

In the React pages...

• if an error message is returned from the buy/add endpoints, display the error message to the user

Barter accounts have at least the following fields

• name
• balance

Events have at least the following fields

• reference to a barter account
• type (credit, debit, note)
• datetime of events
• staff_id (who was logged in when the event is recorded)

• Get it working
• Write deploy instructions

I suggest adding the ability to view the barter event history for an account on the account page so the user can research account balance issues, answer customer questions about the account balance, correct any errors that were made on the account. Currently, the user can only see the date of the most recent transaction.

Sisters of the Road Outbook

Description

Sisters is a safe space and is dedicated to maintaning a violence-free, respectful, and dignified environment in the cafe. If a customer violates the house rules, they can be put on an "out", meaning they are not invited to the cafe for some period of time. This duration is determined through a conversation with the customer and sisters staff.

We'd eventually like to be able to support the outbook for Sisters of the Road. We'd like to be able to allow the POS app to know if a client is currently out and we'd like to make it easy for SotR to generate the various reports that they are required to make.

Requirements

Outbook Events

• New django model with a name OutbookEvents
• barter account: A required Foreign key field to a barter account (establishing the many-to-one relation).
• out start date: A required date field
• out end date: A required date field
• reason: An optional text field
• Set the default ordering of the model to be by the out end date in descending order
• Custom manager method is_barter_account_out that takes a BarterAccount object and returns a bool makes it easy to determine if a given barter account is currently out
• Custom manager method get_barter_account_out_reason that takes a BarterAccount object and returns a str that makes it easy to see why a given barter account is currently out

BarterAccount Model changes

• add BarterAccount method add_out_event that adds an event to the outbook for this barter account
• add @property named is_out to BarterAccount that takes no parameters and returns a bool that uses self in the is_barter_account_out custom manager method
• add @property named out_reason to BarterAccount that takes no parameters and returns an optional str that uses self to call the get_barter_account_out_reason method.

Tests

• Tests for the outbook events custom model manager methods and the sorting (depends on #113)

Notes:

• Feel free to pair with @mikelane on any of this.
• The barter account field must have an on_delete parameter set since we are using django 2.
• It makes it easy to do reverse relations if you provide a related_name parameter to the foreign key field, too
• Django Many-to-one relationships
• Django adding extra manager methods
• Django default ordering

Testing

Implement the following if the new testing system gets released before this work is done. Please feel free to pair with @mikelane for help on this.

• It'd be nice to use the upcoming testing system for the tests, if possible. Mike is happy to pair with you on this.
• It'd also be nice to create a model factory to facilitate the creation of outbook events
• It'd also be nice to create functionality to optionally add outbook events in the barter account factory

pip install -r requirements.txt
npm install
./node_modules/.bin/webpack --config webpack.config.js

In bartercheckout.test.py, create a TestCase class for the credit view, eg:

from django.test import TestCase

class CreditTest(TestCase):
...

You'll need to set up an account that you can use for the test. One way to do this is to write a setUp method that adds an account to the test database. Another approach would be to mock the model object.

Write test method in side this class that test the following scenarios:

• If the account doesn't exist, you get the correct error
• If the account exists, add method is called
• If the account exists and the credit amount is valid, no errors are raised and a credit event is created
• If the account exists and the credit amount is not valid, json is returned that describes the error

This is just a suggestion, but should this project be using Preact instead of React?

React has a restrictive license and is also a larger payload than Preact. Many of the features still exist in Preact, but there are differences which you might need to be aware of.

The way we are doing testing now for the backend is nice, but it's got a bit of a learning curve. Let's write some beginner-friendly documentation about how to test our code.

When I fill out a form to spend money or add credit, and then hit return, the page is refreshed with no backend action.

For example,
If I click into a barter account,
then click on buy card,
then enter an 5 in the form input field,
then hit the return key on my keyboard,

Then
The account balance is not decreased by $5
The browser is refreshed and I returned to the search screen

Hi team,

I found it a little difficult to get a local environment set up for this without digging through the code for database configuration. I think a docker container would make it easier to set up a local development service as well as the eventual deployment to production.

Here's some files which might help get this started:

rundocker.sh (the script to start the local service from)

#!/bin/bash

echo "Stopping any existing containers"
sudo docker rm -f $(sudo docker ps -aq --filter "name=sisters-of-the-road") 2>/dev/null

echo "Building image"
sudo docker build -t sisters-of-the-road/barter:latest .
if [ $? -ne 0 ]; then
  echo "Could not build image"
  exit 1
fi

echo "Starting container"
sudo docker run -it --name sisters-of-the-road-barter -p 8000:8000 sisters-of-the-road/barter /rundockerserver.sh

Dockerfile

FROM ubuntu:latest

# Prepare all deps
RUN apt-get update
RUN apt-get install -y git-core
RUN apt-get install -y python-setuptools python3-dev build-essential
RUN apt-get install -y python3-pip python3-venv
RUN apt-get install -y npm
RUN apt-get install -y postgresql-9.5
RUN apt-get install -y sudo

### Database set up
USER postgres

RUN ls /etc/postgresql/
RUN    /etc/init.d/postgresql start &&\
    psql --command "CREATE USER sisters WITH SUPERUSER PASSWORD 'sisters';" &&\
    createdb -O sisters barter

RUN echo "host all  all    0.0.0.0/0  md5" >> /etc/postgresql/9.5/main/pg_hba.conf
CMD ["/usr/lib/postgresql/9.5/bin/postgres", "-D", "/var/lib/postgresql/9.5/main", "-c", "config_file=/etc/postgresql/9.5/main/postgresql.conf"]

### Application set up
USER root
RUN service postgresql start

RUN pip3 install --upgrade pip
RUN python3 -m venv venv
RUN npm install npm@latest -g
RUN ln -s /usr/bin/nodejs /usr/bin/node

RUN git clone https://github.com/codeforgoodconf/sisters-of-the-road-admin.git
RUN (cd sisters-of-the-road-admin/; npm install; ./node_modules/.bin/webpack --config webpack.config.js)
RUN (. venv/bin/activate; cd sisters-of-the-road-admin/; pip install --upgrade pip; pip install -r requirements.txt)

COPY rundockerserver.sh /
RUN chmod +x /rundockerserver.sh

EXPOSE 8000

rundockerserver.sh

#!/bin/bash

sudo service postgresql start

python3 -m venv /venv
source /venv/bin/activate

cd sisters-of-the-road-admin/
pip install -r requirements.txt
python manage.py migrate

echo "from django.contrib.auth.models import User; User.objects.filter(email='[email protected]').delete(); User.objects.create_superuser('admin', '[email protected]', 'password')" | python manage.py shell
python manage.py runserver 0.0.0.0:8000

By running the rundocker.sh, it should start a local service up which you can immediately test against and use the default admin account: admin / password.

Let me know what your thoughts are. I'd be willing to help extend this concept if your team find it useful.

Cheers,
Steven

django 2.1 offers some useful features, plus it's difficult to upgrade over time if you aren't keeping up to date.

Sisters of the Road Outbook

Depends on #113, #117

Description

Sisters is a safe space and is dedicated to maintaning a violence-free, respectful, and dignified environment in the cafe. If a customer violates the house rules, they can be put on an "out", meaning they are not invited to the cafe for some period of time. This duration is determined through a conversation with the customer and sisters staff.

We'd eventually like to be able to support the outbook for Sisters of the Road. We'd like to be able to allow the POS app to know if a client is currently out and we'd like to make it easy for SotR to generate the various reports that they are required to make.

Requirements

BarterAccount API changes

• add field is_out to the serializer
• add field out_reason to the serializer
• add nested field for outbook events

Tests

• add outbook events factory if not accomplished in #117
• modify BarterAccountFactory to add optional outbook events
• test api returns outbook events
• test api returns correct out status with no outbook events
• test api returns correct out status with outbook events that have expired in the past
• test api returns correct out status with outbook events that have not yet started
• test api returns correct out status when today falls within the outbook start and outbook end dates (test that today is the start date, today is between the start and end, and today is the end date).

The input fields on the AddCredit and BuyMeal pages currently do not have any validation. It would be nice to display a helpful message if the user tries to submit something invalid.

Also, Eileen suggested adding a "mask" to the input so that e.g. if the user types "125" the field automatically formats that as "$1.25". This is a non-trivial problem though, and might be better suited to its own issue.

Right now the search results are about the same width as the search bar, but their offset quite a bit. (See the screenshot below)
I don't have a strong opinions about exactly how this should look, but it should:

• look like the alignment was designed intentionally
• looks good on an iPad with a landscape orientation

Currently the only way to look up an account is by searching for it. Since the Cafe staff is used to looking up accounts in books by first letter of an account name, we would like to give them a similar option in the UI.

• As an alternative to using the search field, there should be a way to browse accounts in alphabetical order.
• Currently, if you click search without entering a search string, all accounts will be displayed. If would be preferable to be explicit about this and to have a way to skip to accounts starting with a certain letter

Stretch Goal: Note: the app is deployed on Azure
Implement autocomplete using ElasticSearch

• Dockerize the entire project (using Docker Compose)
• ES search returns a barter account ID?
• Front end needs to populate and re-populate the accounts list as letters are typed (perhaps with some kind of sane timeout so it does not attempt to keep up with fast typing)

• Add icons to buy card, buy meal, and add credit buttons to make them easier to distinguish
• Make them more rectangular
• Stack them in a column rather than next to each other

The idea is to give the user an extra opportunity to verify they want to ADD credit.
It would be nice also to give them a slot to leave their initials, which could help with auditing changes later.

Right now these pages do not show the current balance, so you have to remember what it was when you're adding/subtracting from it.

Style the results differently to make it clear that you tap on the results to get to the desired barter account.

Currently, we load all accounts on the index page when it is loaded. Instead we'd like to only show account that match a search term after it has been submitted.

To implement this, you will will most likely need to:

• create a form/button with react
• when the button is clicked, a GET request is made to account/search?q= where is the text from the input field
• build the list of accounts using the data returned from the search request

When a customer has a medical condition that prevents them from volunteering at the Cafe, they can spend $1.50 per day to at the cafe for free. Sometimes this lasts for a short amount of time and sometimes this is indefinite.

• An admin user should be able to enter a medical allowance for an account. A customer could have medical indefinitely or with an expiration date. Medical can only be used once a day, so the application needs to track if a customer has used medical that day.

• Counter staff should be able to mark whether a customer has used their medical allowance that day. One possibility could be to add a medical button to the account page if that account has medical enabled. A customer should still be able to spend any barter balance that they have if they have a medical allowance.

Notes:

• Medical balance should be used before barter_account balance. Should this be optional or should it be automatic?
• Keep an accounting of when medical has been used.
• Medical does not roll over.
• Front end should have some kind of display for those who are on medical. Should this display only in case there is medical balance available?

After adding a transaction to a barter account, if you want to do anything else with that account, you must search for the user again. Make it so that is not required.

When in a barter account, when you click "Back to Search" there is a name populated in the search bar. However, if you click search without changing the name, you get search results that are equivalent to searching for no name (i.e. you get all names returned). If you change even one letter in the name and then click search, you will then get search results with that name.

Working with cents on the back end is error-prone. We should make the model work with dollars and cents and prevent rounding errors while doing so.

Eileen suggested adding a "mask" to the input so that e.g. if the user types "125" the field automatically formats that as "$1.25". (See issue #39)

Django Rest Framework makes REST a lot easier and more secure. So let's update our backend to use DRF instead of pure Django.

The setup instructions are out of date. Need to update to help new contributors install and set up environment.

In the admin interface, the current page heading is "Django administration".

It would be better to change this to something more specific, something like "Sisters of the Road Cafe Admin".

Since this is in the django admin, you won't find this heading in our existing code, but it should be relatively straight forward to find out how to do this using Django's documentation.

Currently this page uses BarterEvent's __str__() to display barter events. It will be better to edit admin.py instead.

This would make it easier for new contributors and also make pull requests more uniform and informative.

When searching for a barter account, sort by name.