New WaitingListEntry #33
4
.gitignore
vendored
4
.gitignore
vendored
|
@ -8,3 +8,7 @@ db.sqlite3
|
||||||
.env
|
.env
|
||||||
venv/
|
venv/
|
||||||
.venv/
|
.venv/
|
||||||
|
|
||||||
|
|
||||||
|
# collectstatic
|
||||||
|
src/static/
|
||||||
|
|
4
Makefile
4
Makefile
|
@ -1,6 +1,5 @@
|
||||||
DOCKER_COMPOSE = COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose
|
DOCKER_COMPOSE = COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose
|
||||||
DOCKER_RUN = ${DOCKER_COMPOSE} run -u `id -u`
|
DOCKER_RUN = ${DOCKER_COMPOSE} run -u `id -u`
|
||||||
DOCKER_BUILD = DOCKER_BUILDKIT=1 docker build
|
|
||||||
MANAGE_EXEC = python /app/src/manage.py
|
MANAGE_EXEC = python /app/src/manage.py
|
||||||
MANAGE_COMMAND = ${DOCKER_RUN} app ${MANAGE_EXEC}
|
MANAGE_COMMAND = ${DOCKER_RUN} app ${MANAGE_EXEC}
|
||||||
|
|
||||||
|
@ -21,3 +20,6 @@ shell:
|
||||||
|
|
||||||
manage_command:
|
manage_command:
|
||||||
${MANAGE_COMMAND} ${ARGS}
|
${MANAGE_COMMAND} ${ARGS}
|
||||||
|
|
||||||
|
build:
|
||||||
|
${DOCKER_COMPOSE} build
|
||||||
|
|
54
README.md
54
README.md
|
@ -7,7 +7,6 @@ There are two ways to setup the development environment.
|
||||||
- Using the Docker Compose setup provided in this repository.
|
- Using the Docker Compose setup provided in this repository.
|
||||||
- Using [hatch](https://hatch.pypa.io/) in your host OS.
|
- Using [hatch](https://hatch.pypa.io/) in your host OS.
|
||||||
|
|
||||||
|
|
||||||
### Using Docker Compose
|
### Using Docker Compose
|
||||||
|
|
||||||
Working with the Docker Compose setup is made easy with the `Makefile` provided in the repository.
|
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
|
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
|
```bash
|
||||||
cp .env.example .env
|
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
|
2. Migrate
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
make migrate
|
make migrate
|
||||||
```
|
```
|
||||||
|
|
||||||
3. Run the development server
|
3. Run the development server
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make run
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Building and running other things
|
||||||
|
|
||||||
```bash
|
```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
|
### Using hatch
|
||||||
|
@ -53,25 +65,25 @@ make run
|
||||||
|
|
||||||
1. Setup .env file
|
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
|
```bash
|
||||||
cp .env.example .env
|
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
|
2. Run migrate
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
hatch run dev:migrate
|
hatch run dev:migrate
|
||||||
```
|
```
|
||||||
|
|
||||||
3. Run the development server
|
3. Run the development server
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
hatch run dev:server
|
hatch run dev:server
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Updating requirements
|
#### Updating requirements
|
||||||
|
|
||||||
|
|
|
@ -5,6 +5,7 @@ from django.contrib import admin
|
||||||
from .models import Membership
|
from .models import Membership
|
||||||
benjaoming marked this conversation as resolved
Outdated
|
|||||||
from .models import MembershipType
|
from .models import MembershipType
|
||||||
from .models import SubscriptionPeriod
|
from .models import SubscriptionPeriod
|
||||||
|
from .models import WaitingListEntry
|
||||||
|
|
||||||
|
|
||||||
@admin.register(Membership)
|
@admin.register(Membership)
|
||||||
|
@ -20,3 +21,8 @@ class MembershipTypeAdmin(admin.ModelAdmin):
|
||||||
@admin.register(SubscriptionPeriod)
|
@admin.register(SubscriptionPeriod)
|
||||||
class SubscriptionPeriodAdmin(admin.ModelAdmin):
|
class SubscriptionPeriodAdmin(admin.ModelAdmin):
|
||||||
"""Admin for SubscriptionPeriod model."""
|
"""Admin for SubscriptionPeriod model."""
|
||||||
|
|
||||||
|
|
||||||
|
@admin.register(WaitingListEntry)
|
||||||
|
class WaitingListEntryAdmin(admin.ModelAdmin):
|
||||||
|
"""Admin for WaitingList model."""
|
||||||
|
|
|
@ -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'},
|
||||||
|
),
|
||||||
|
]
|
|
@ -139,3 +139,18 @@ class MembershipType(CreatedModifiedAbstract):
|
||||||
|
|
||||||
def __str__(self) -> str:
|
def __str__(self) -> str:
|
||||||
return self.name
|
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")
|
||||||
|
|
|
@ -1,5 +0,0 @@
|
||||||
[pytest]
|
|
||||||
testpaths = .
|
|
||||||
python_files = tests.py test_*.py *_tests.py
|
|
||||||
DJANGO_SETTINGS_MODULE = project.settings
|
|
||||||
#norecursedirs = dist tmp* .svn .*
|
|
Loading…
Reference in a new issue
I'm against importing whole modules.
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 ownmodels
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
inapp.models
but inapp.*
I usefrom 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 othermodels
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)
Alright you stubborn one ❤️