New WaitingListEntry #33

Merged
valberg merged 10 commits from benjaoming/membersystem:waiting-list into main 2024-07-31 22:49:48 +00:00
7 changed files with 93 additions and 27 deletions

4
.gitignore vendored
View file

@ -8,3 +8,7 @@ db.sqlite3
.env
venv/
.venv/
# collectstatic
src/static/

View file

@ -1,6 +1,5 @@
DOCKER_COMPOSE = COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose
DOCKER_RUN = ${DOCKER_COMPOSE} run -u `id -u`
DOCKER_BUILD = DOCKER_BUILDKIT=1 docker build
MANAGE_EXEC = python /app/src/manage.py
MANAGE_COMMAND = ${DOCKER_RUN} app ${MANAGE_EXEC}
@ -21,3 +20,6 @@ shell:
manage_command:
${MANAGE_COMMAND} ${ARGS}
build:
${DOCKER_COMPOSE} build

View file

@ -7,7 +7,6 @@ There are two ways to setup the development environment.
- Using the Docker Compose setup provided in this repository.
- Using [hatch](https://hatch.pypa.io/) in your host OS.
### Using Docker Compose
Working with the Docker Compose setup is made easy with the `Makefile` provided in the repository.
@ -21,24 +20,37 @@ Working with the Docker Compose setup is made easy with the `Makefile` provided
1. Setup .env file
An example .env file is provided in the repository. You can copy it to .env file using the following command:
An example .env file is provided in the repository. You can copy it to .env file using the following command:
```bash
cp .env.example .env
```
```bash
cp .env.example .env
```
The default values in the .env file are suitable for the docker-compose setup.
The default values in the .env file are suitable for the docker-compose setup.
2. Migrate
```bash
make migrate
```
```bash
make migrate
```
3. Run the development server
```bash
make run
```
#### Building and running other things
```bash
make run
# Build the containers
make build
# Create a superuser
make createsuperuser
# Create Django migrations (after this, maybe you need to change file permissions in volume)
make makemigrations
```
### Using hatch
@ -53,25 +65,25 @@ make run
1. Setup .env file
An example .env file is provided in the repository. You can copy it to .env file using the following command:
An example .env file is provided in the repository. You can copy it to .env file using the following command:
```bash
cp .env.example .env
```
```bash
cp .env.example .env
```
Edit the .env file and set the values for the environment variables, especially the database variables.
Edit the .env file and set the values for the environment variables, especially the database variables.
2. Run migrate
```bash
hatch run dev:migrate
```
```bash
hatch run dev:migrate
```
3. Run the development server
```bash
hatch run dev:server
```
```bash
hatch run dev:server
```
#### Updating requirements

View file

@ -5,6 +5,7 @@ from django.contrib import admin
from .models import Membership
benjaoming marked this conversation as resolved Outdated

I'm against importing whole modules.

Explicit is better than implicit.

I'm against importing whole modules. > Explicit is better than implicit.

Don't we import whole modules everywhere all the time?

The idea is that the Django app is a domain-specific app so importing the models into the admin makes sense because almost all Models from that models module will have an admin. To me, this makes the code more readable than having lots of import statements.

Don't we import whole modules everywhere all the time? The idea is that the Django app is a domain-specific app so importing the models into the admin makes sense because almost all Models from that models module will have an admin. To me, this makes the code more readable than having lots of import statements.

Well, yes. I mostly use for instance from django.db import models in my own models modules, because it is a standard - but I actually would love to be more explicit everywhere.

When push comes to shove it is all about preference. My preference is to explicitly import what is being used, to have a clear "in this module we are using these external things".

Well, yes. I mostly use for instance `from django.db import models` in my own `models` modules, because it is a standard - but I actually would love to be more explicit everywhere. When push comes to shove it is all about preference. My preference is to explicitly import what is being used, to have a clear "in this module we are using these external things".

I also use from django.db import models in app.models but in app.* I use from app import models because it's so convenient and it targets the domain-specific ideal of the app. As in, if you are import some other models module, then something is wrong.

I also use `from django.db import models` in `app.models` but in `app.*` I use `from app import models` because it's so convenient and it targets the domain-specific ideal of the app. As in, if you are import some other `models` module, then something is wrong.

I think having explicit imports is more readable and gives me an overview of what the module is interfacing with.

I think we can debate this forever :P

I would say that we should go with "do not change it just for the sake of changing it" and keep it as it was (but that is also in favorable for me ATM)

I think having explicit imports is more readable and gives me an overview of what the module is interfacing with. I think we can debate this forever :P I would say that we should go with "do not change it just for the sake of changing it" and keep it as it was (but that is also in favorable for me ATM)

Alright you stubborn one ❤️

Alright you stubborn one ❤️
from .models import MembershipType
from .models import SubscriptionPeriod
from .models import WaitingListEntry
@admin.register(Membership)
@ -20,3 +21,8 @@ class MembershipTypeAdmin(admin.ModelAdmin):
@admin.register(SubscriptionPeriod)
class SubscriptionPeriodAdmin(admin.ModelAdmin):
"""Admin for SubscriptionPeriod model."""
@admin.register(WaitingListEntry)
class WaitingListEntryAdmin(admin.ModelAdmin):
"""Admin for WaitingList model."""

View file

@ -0,0 +1,32 @@
# Generated by Django 5.0.7 on 2024-07-20 20:45
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('membership', '0005_member'),
]
operations = [
migrations.CreateModel(
name='WaitingListEntry',
fields=[
('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
('modified', models.DateTimeField(auto_now=True, verbose_name='modified')),
('created', models.DateTimeField(auto_now_add=True, verbose_name='created')),
('email', models.EmailField(max_length=254)),
('geography', models.CharField(blank=True, default='', verbose_name='geography')),
('comment', models.TextField(blank=True)),
],
options={
'verbose_name': 'waiting list entry',
'verbose_name_plural': 'waiting list entries',
},
),
migrations.AlterModelOptions(
name='membership',
options={'verbose_name': 'medlemskab', 'verbose_name_plural': 'medlemskaber'},
),
]

View file

@ -139,3 +139,18 @@ class MembershipType(CreatedModifiedAbstract):
def __str__(self) -> str:
return self.name
class WaitingListEntry(CreatedModifiedAbstract):
"""People who for some reason could want to be added to a waiting list and invited to join later."""
email = models.EmailField()
geography = models.CharField(verbose_name=_("geography"), blank=True, default="")
comment = models.TextField(blank=True)
def __str__(self) -> str:
return self.email
class Meta:
verbose_name = _("waiting list entry")
verbose_name_plural = _("waiting list entries")

View file

@ -1,5 +0,0 @@
[pytest]
testpaths = .
python_files = tests.py test_*.py *_tests.py
DJANGO_SETTINGS_MODULE = project.settings
#norecursedirs = dist tmp* .svn .*