lehack / trattentracker Goto Github PK

If a student moves between groups with different fees, the system should still be able to calculate his balance correctly for months before and after the change.
Same should be true for students who switch to/from sport cards.

Prepare DB and Model layout.

This view will be similar to the #12 but after clicking we will get details on the current attendee balance and last 5 payments made (similar like in #8 ).
Note that according to the project vision (2.2.5) the summary view should never display any balance info. This should be hidden until a particular attendee is selected.
It would however be nice to have some highlight of attendees with pending payments.

Currently the monthly balance is updated manually and the code calculating amount due has to crunch through all data since the last balance update. The balance should be automatically recalculated every month.
Note also a dependency on issue#20

We need to filter out inactive users.

Add some membership/passes notifications to allow for easy spotting of users whose membership or 5 training pass is running out soon.

In order to allow sharing trainings docs and exam info.

The idea is to store, manage and display upcoming events like training camps/seminars, one-time additional trainings etc.
This should also include a way to assign users to such events to eventually include such attendance in the frequency calculations.

In the event a training is cancelled within the next 2-3 weeks, a notification should be present on the users page.

Currently most view reloads require fetching group/attendees info. This (and other) data could be stored in the browser and reused. This could also be a good solution to handling issue #16
A good candidate to do the job is: https://github.com/reactjs/redux

Allow the users to see their current fee status with a highlight when one is close to becoming invalid.

Show the user his training frequency for the last 3 months.
Currently there is info regarding last 6 months, but this is very basic (also the idea of "extra attendance" is not really implemented correctly).
We should extend the view to show per month frequency (in the month attendance detail view) and an overall sum with the last 3 months side by side.

Add support for membership fees and training passes to the model. Update dues calculations.

When a payment is not added to the cash register, it should be visible on a list of such pending payments.
There should also be a button to mark each/all payments as cash-registered (currently this process has to be done via the Durango asmin page).

This view should allow to add information of a received payment from a particular group member.
Possibly we could have a clickable list (with group selection above) of group members (those who have pending payments highlighted somehow or moved higher up the list). Upon clicking a set of controls would emerge allowing to specify the payment (type and amount, defaulting to the current setting for payment type, see #11 ). After saving the indications should refresh.

ℹ️ Note: The model will be prepared as part of #1 so this information will be available regardless whether #11 is done.
ℹ️ Note 2: This was finally omitted in the current model implementation. Due to time restrictions, it will be part of a future update.

Currently any attempt to search returns an internal server error (500)

When a student owes more than his monthly fee, he should get a monthly e-mail reminder (with an option to opt-out of them) and at the same time a summary of such should be sent to the teacher.

Every remote view should be also able to handle communication errors with the backend.
If the backend does not respond during initial load, there should just be a big error message shown.
If the backend stops responding during operation (e.g. when updating the attendance list), the UI should handle it gracefully by enabling a "Save" button which will allow to update the backend at a later time (the app may stay loaded in the phone memory for a long time).

Handy for newcomers.

This will be the most frequently used view in the app (maybe except for #4 ).
It should show a list of group members and allow to quickly enter which members are present on a training. Here's a mockup of what I'm thinking about:

So clicking on an attendee should toggle his current status (and immediately send the information to backend).
Possibly the label above should be expandable to allow for changing the currently selected group.
The default group should be selected using the current date and time and the Group model information (days and hours of trainings), e.g.

• say we have two groups: Beginners (at 7 PM) and Advanced (at 8 PM), so the Beginner group should be selected as the default one until 7:45 PM, after that the Advanced group should be selected by default
• if we'd have three groups: 5 PM, 6 PM and 7 PM, the 5 PM group should be selected until 5.45PM, the 6 PM group until 6.45PM and later the 7 PM group

Furthermore, the system should be able to distinguish two types of attendance:

• basic - meaning that the attendee attends his group training (the frequency on these trainings is the basis for next exam eligibility)
• extra - meaning that the attendee attends an additional training (e.g. beyond group schedule or a younger group training)

Finally if the user has a sports card enabled, we should be able to mark his attendance and by default also mark that he scanned the card, but there must also be a possibility to mark the attendance with missing sports card (in case the user is present, but e.g. forgets his card that day).

As for payment, in the formula described in #2 an attendance is only counted once per day, regardless of the above. So if somebody attends two hours on Monday, one hour on Tuesday and two hours on Thursday, only 3 attendances can be used in payment calculation for that week.

With a docker config it would be faster and simpler to setup a running instance for development purposes. This should be run using the django server and react-scripts in debug mode (inside) and linked directly with the code itself (via a volume) to enable robust reloads on code changes.
Keep in mind that at least for now this will not be used with deployments (not enough hardware to run docker reliably in production).

Since sometimes a training has to be cancelled (due to holidays or some other Armageddon event), we need to support marking such days for the attendance frequency algorithm to provide correct outcomes.
So basically what we need here is a Year filtered view of dates (due to various holidays, there is usually around 10-15 cancelled trainings each year) and a simple form for entering them.

The first view to prepare is the mode selection view.
It should be very simple and contain 4 options (admin view):

• attendance
• payment
• attendance summary
• payment summary

It should also contain some indication that we're logged in, a logout link and link to the system configuration view.

I'm not exactly sure what look'n'feel this should have. I'll try and prepare a mockup but I'm also open for any suggestions.

Every single income has to be reported using the cash register. Usually when something is paid in cash, the cash register is used at the spot to generate a receipt. At the same time when a bank transfer comes in often I don't have the register on me, so I update it later.
To make sure I have everything reported correctly it would be good to have an additional attribute by each entered payment which would state whether this payment was tax_reported or not. If it wasn't some reminder should be set to enter it by the end of the day (if possible). This could be done via the Android App, which could automatically generate a calendar reminder set for say 10 PM the same day a payment was added without "tax_reported" attribute set.

We need a module that will be able to handle the monthly fee calculations for a attendee using the following rules:

• to calculate the monthly fee, first check what type of payment the attendee has, if it's monthly then it's a fixed fee and nothing else needs to be calculated for the given month
• if it's attendance-based, then we need to know how many times the attendee was present during that particular month and then we take the group monthly fee subtract the attendance count x10zł, note that this number may come out negative and that's valid (then we get a surplus which advances for the next month)

Finally the module should be able to give us two numbers:

• the fee for any selected month (using the above rules)
• the total current balance - to calculate this we take every month for which there is any attendance info available for that particular attendee, multiply the month count by the group fee and subtract the attendance count x10zł (this should be always calculated live, not stored anywhere)

This view should allow for managing (CRUD) attendees including.
The list should contain the name, rank and assigned group.

We could possibly easily plug in an online payments handler making it faster and simpler to make all necessary payments.

This view would show a list of attendees with their current attendance (last 12 months) stats which are: total number of trainings attended and a percentage (separately for "basic" and "extra" trainings).
After clicking on an attendee, the system could display the same stats but spread out for the last 12 months for that particular attendee.

For certain membership fee level users should gain access to 3 most recent trainings in electronic form.

It would be helpful to see the last time a given person logged into the system to track basic usage.

This view should be accessible via a separate address (using the admin module of django, hence by default it will be http://trattentracker.pl:8000/admin)
It should contain links (tabs?) with the system configuration including:

• #5
• #6

This includes both membership fee and training pass. Include option to set training pass as partially used up.

It is unfortunately obsolete right now, thus it could be hidden (possibly by adding some view config).

This view would allow the admin to CRUD all handled types of payments and their default values (the group payment fee would point to this setting).
Possible options could be:

• Monthly fee Group 1
• Monthly fee Group 2
• Monthly fee Group 3
• Seminar contribution
• Kyu exam fee
• Dan exam fee
• etc.

For the time of using both the old and the new DB format, we need some simple solution that will allow us to make use of the data stored in the old DB (including further changes like trainee adding/activation/deactivation).

There should be a view allowing to CRUD the groups. Group attributes are:

• group name
• training weekdays
• monthly payment

This view should be accessible from the system configuration view.

The app should allow for storing the login/password to the system in some internal preferences (e.g. as some salted sha1sum, not in clear text!). Once set, opening the app should communicate with the REST backend, handle authentication (by calling a specified REST endpoint which will accept the hashed login/pass) and then open the index page of the web view (with operation mode selection).

If the phone system allows it, the app should go to background whenever other operations are performed on the phone (e.g. a call is made or received) and allow to be restored with everything intact.
A REST ping should be performed on every restore, to ensure having a session ready. If REST denies us access, a new session should be established (by logging in again) and replace the current one without reloading the app (and potentially loosing data).

This view is the only one the training attendees should see after logging in (all other views should be admin-only).
It should contain:

• the current balance
• last 5 payments made (with "Show more" button)
• current month attendance stats (training count and a percentage) separated into basic and extra (attendance to the assigned group, attendance to other groups) - sort of a "Progress status"
• attendance stats for the last 5 months (similar to the above, but below and in a smaller font)

ℹ️ Note: in order to count the percentages we need to know how many trainings there are to be in a month, so this will require #9 to be completed, thus this part is a "Could have" not "Must have"