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…
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…
298a453e19
Remove stripe session from success page (doesnt somehow work according to their docs hmm)
Yes but having to re-run the same things over and over again, creating huge new cache layers every time would be equally bad?
There will be a new model Product and Order that are relevant for charging services, but we can probably figure out how they are associated with services... I like the idea of matching a service…
Just wanna say that I've seen this WRT the Membership and MembershipType definitions. I think this will work fine in combination. I have some ideas etc.. but fundamentally, this doesn't need to change 👍
An update: I've added a list of tasks in the description. This is getting nearer. If possible, I would consider to deploy some of the changes early so it's possible to add memberships and get…
768ef5a7d2
Add new admins, rework relation between orders and memberships, MembershipType can contain many Products, Memberships can be activated and revoked
This is ready btw... I intend that we just use the Waiting List from the Django admin for now... then we can add a public interface later... BUT:
We have intentions that overlap heavily around…
I think the main priority should be that all our data.coop services are somehow deployed in the same/similar way... but then their development environment can be allowed to drift.
Reasoning…