spf-uio / spbm Goto Github PK

The Student Personnel Booking Manager, by and for the Student Cellar Pub Personnel Organsiation at the University of Oslo.

Python 64.62% Shell 5.17% CSS 1.23% JavaScript 0.27% Dockerfile 0.36% Jinja 28.36%

django payroll student-management invoicing booking spbm

spbm's Introduction

SPFs "SPBM"

Her er koden for Studentkjellernes personalforening sitt nåværende nettbaserte system for grovhåndtering av diverse utlån og leier av lokaler, studentansatte, fakturering av medlemsforeninger, samt lønnsrapportering for utbetaling av lønn.
This is the code for the Student basement pubs society current web-based system for roughly managing our various bookings and rentals of our collective premises, student employees, invoicing our member societies, as well as wage reporting to facilitate payroll.

For funksjonalitetsønsker, problemer, og spørsmål kan du opprette et issue her på GitHub.
For feature requests, problems, and questions, please create an issue here on GitHub.

Getting Started

You need Docker and Docker Compose to get started locally. You may use Docker on its own, but it'll require setting the containers up manually.

To get started with a Gunicorn-based development environment with live reloads use docker-compose:

$ docker-compose up

You'll get a local development environment with SPBM, NGINX and PostgreSQL (available at localhost:80).

If you'd rather use the built-in Django development server (at localhost:8000) you may do so.

$ docker-compose run spbm ./manage.py runserver 0.0.0.0:8000

Use docker-compose to perform other typical things while developing, such as migrating or loading.

$ docker-compose run spbm ./manage.py showmigrations --plan
$ docker-compose run spbm ./manage.py migrate
$ docker-compose run spbm ./manage.py loaddata User SpfUser Society Invoice Worker Employment Event NorlonnReport Shift
$ docker-compose run spbm ./manage.py ...

You may also use Poetry and a virtualenv for smoother development, but be careful and test your changes using the Docker container too to ensure that everything works the way it should.

Production

Make sure to override default environment variables for SPBM, and PostgreSQL if you're using Docker Compose.

$ docker-compose -f docker-compose.yml -f docker-compose.prod.yml up

Translations and i18n

Make sure to add strings using ugettext and similarly, such as ugettext_lazy in models. For more information, see Django's own documentation on how to mark strings as localiseable.
Once strings have been added in the code, extract and combine the strings into the locale's PO files:
```
$ ./manage.py extract && ./manage.py merge
```
This will extract all the localizable strings into locale/templates, followed by a merge with locale/xx_XX. Both extract and merge are provided by puente.
Do not use Django's makemessages!
Once you've translated the strings in locale/xx_XX/django.po, you'll want to compile the strings. You'll want to do this every time you're working locally and you want to see the changes.
```
$ ./manage.py compilemessages
```

Contributing

Any help is much appreciated. Take a look at our issues in the issue tracker, and go crazy.

spbm's People

Contributors

Stargazers

Watchers

Forkers

maxiix3 guoyu07 thor hannehugem

spbm's Issues

Creating a PDF invoice fails due to missing get_hours()

See PR #8, which made a warm mess here due to lacking an integration test for the PDF-generation.

Lack of (obvious) dedicated logout button/link

Originally reported by: roht (Bitbucket: roht, GitHub: thor)

Bitbucket: https://bitbucket.org/Aleksi/spf/issue/3

Add information about who the loan was for, including billing information and more.

Originally reported by: roht (Bitbucket: roht, GitHub: thor)

This could etiher be done rather easily by simply adding more fields to our Event model, but I'm not sure if that's the cleanest or most neat way to go about it.

Possibly each Event could have a OneToOne relationship with something such as Booking, but I'm afraid that might dilute the meaning of both.

Fields in consideration

Booker/renter

Who booked the event. Fairly easy, combination of name and contact e-mail could be added as two separate fields.

Start and end-time

These I believe to be essential to allow for some smarter calculations of money.
Each Shift would initialise with the start and end-time specified for the Event, but with the opportunity to add a positive/negative difference to both the start and end-time. If not, it's still something that can be added for the sake of completeness.

Is there possibly a need for breaks to be taken into consideration, @maxiix3?
What would make things easier for you, or do you have an entirely separate tracking system (like CYB, e.g. Jira or similar)?

Description

In the spirit of avoiding too many fields, it might be easier to simply have a description available.
Alternatively it's possible to have a custom-fields sort of setup that allows each society to add details they want, but that's quickly going down a dangerous road.

Booking information

Trickier. Should it only be an e-mail address? Any reference field? What for, if so? We're not invoicing the rentees, just the cellars, which have to do that.

Bitbucket: https://bitbucket.org/Aleksi/spf/issue/2

Linting and consistent formatting

There's a lot of room for code improvement, even with the high amounts of things that have been fixed.

Thus, we should look at things like:

pylint
mypy

Or maybe packages of them, like:

pylama

Code analysis and formatters too:

Tool	Category	Description
Mccabe	Analytical	Checks McCabe complexity
Radon	Analytical	Analyzes code for various metrics (lines of code, complexity, and so on)
Black	Formatter	Formats Python code without compromise
Isort	Formatter	Formats imports by sorting alphabetically and separating into sections

Correct number of decimal places for postgresql annotation of invoices

This involves either rounding the invoices data when it multiplied with each other, or using the Python format tools to correct it.

Initially I used

models.DecimalField(decimal_places=2)

which didn't help, oddly enough on postgres, which has been changed to

models.DecimalField()

in 2e17503 for the meanwhile. These details can be seen in spbm/apps/society/models.py.

Improved overview of wage reports for verifying sums and wage recipients

Current wage reports are too simplistic, not very useful, and even more importantly almost entirely useless for verifying the correctness of an externally executed payroll.

A new view should:

Show a total overview of the sum to be added before taxes
A sorted list (over external wage IDs) of the personnel on the payroll
How much each gets before taxes
Listing each invoice it belongs to

Furthermore, that's just for the singular view, but the main overview should show a more complete overview of issues preventing a wage report from being created, and even more so there needs to be a mechanism for editing in some way. This is however not important to begin with.

Yrkeskode is now mandatory when paying out sallary

We should take a look in to if there is possible to add this to the output file SPBM gives us after closing a period. And if norlønn can read somewhere yrkeskode from the file. I think the easiest way is to add a section on every worker that works at a event. To make it easier we should have a drop down so you could select if the person was "barmedarbeider", "barsjef" or "lydtekniker" or similar names.
Any thoughts, @thor ?

The new rules can be found her:
To download the list of type look here:

Inconsistent language and typos

The language need to be more consistent, both in regards to mixing English/Norwegian, abbreviations and language typos.

Example of undesired behaviour:

Workers have to be duplicated for each society

Unfortunately our OneToOneField usage limits each worker to one society, which means these workers that are active in more than one society have to be duplicated. This kills the normalisation.

Change to ManyToManyField.
Create a manual migration to migrate back to them.

Events can be created without shifts, or empty shifts spanning no time

This can lead to the invoice page failing to generate the required information, as there's suddenly an unexpected division by zero.

Amend the invoicing view for better safety, but unless a second booking type of free is introduced, no booking should be able to have a zero-cost sum.

Payroll executor doesn't know if statuses are up to date

For the payroll to be executed correctly, whoever executing it must be able to know whether statuses are recent enough to execute payroll.

Alternatively, they simply need to be stopped in the event they aren't.

Crash when adding the same person multiple times in the same event

Added by @thor.

IntegrityError occurs due to an attempt at violating the unique constraint for an event's shift and its worker.
Should be amended to provide a better error message, as the IntegrityError certainly shouldn't go away in itself.

Norwegian bank account numbers are not verified

The fields are not verified, and are used solely as a form of help to keep data in one location, even though it has to go into the wage system as well.

This field should verify that it is a valid bank account number, so that it can be trusted.

Integration with eAccounting API

This is a bigger one.

For invoicing, we want to integrate with the eAccounting API for us to achieve two things, for the most part:

Ensure correct creation and detailed itinerary of invoices sent to participating personnel organisations
Ensure correct payment and subsequent data basis for payroll executions

The latter is particularly useful, as we want to reduce the dependency of organisation representatives on the financial administrator.

The documentation is fairly easily available on Visma's site, and despite how hard it has to get anything done on this, it is more for a lack of prioritisation than any technical hurdles.

Enable per-worker start and end times in addition to pure hours

Includes the work that goes along with improving the interface for actually entering this information in a useful manner.

Any instance of a start and end time overwrites hours.
If hours are entered, and then a start time, then the end time will be set automatically.
Hours entered that do not match with start and end time will be changed in accordance with the actual duration.

Bitbucket: https://bitbucket.org/Aleksi/spf/issue/1