App mindmap

[bbelderbos]

Pybites Mindmapping (App Design) Training https://www.youtube.com/watch?v=ZEOJ7GZyg0k

[theonlysam]

@bbelderbos Mindmap V1

[bbelderbos]

@theonlysam cool thanks, looks good. Which component shall we start with, the core of adding the booking system? Maybe you can define the models for this first? For user registration I suggest using allauth - I logged an issue as well as some others. Feel free to add additional ones ...

[theonlysam]

[theonlysam]

• I'm thinking Booking and recurring/special booking can be one table
• For Messages the recipients would be fellow members. How to define/store that information?
• Should member inherit from abstract user or one of those classes?
• If the member's subscription is not valid for the current year, they are assumed to be inactive. Does the active field in member make sense here?

[bbelderbos]

Great work @theonlysam

• Yes I don't think recurring booking has to be a separate table, let's go with one Booking table. Should Court be it's own table though? There is a 1-to-many relation between Court and Booking.
• Message: is this for members to message each other? You could have two foreign keys to the Member table for to / from
• Yes Member is a subclass from Django's User which you should leverage to get common attributes like first_name, last_name, email, etc. Check out https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html - I usually pick option 2 to have profile stuff in it's own (1-to-1) table, but happy to go with option 4 as well, read up on it and let me know what you prefer ...
• Yes active would be a boolean flag on the Member, that's good
• What is the use of the Players table?

Maybe you can also list the "business rules" (3-5) here to make sure this matches, e.g.

• User makes a booking for a particular time which can be one time or recurring
• User1 can message user2 and vice versa
• A user can be on a subscription, which gives them access to make bookings (or other ...)
• If a subscription expires, user gets deactivated with consequence ...
• Etc.

[bbelderbos]

As per meeting today:

1. Drop Players table, this wil be m2m (many to many) on booking table
2. Add owner fk to member on booking table
3. Add guests m2m to booking table
4. Member will be abstracted user (see Vitor extend user article option 4)
5. Messages - recipients will also be m2m to member table (existing fk (foreign key) = sender)
6. Drop the recurring booking table, this will be “recurring” boolean flag on booking table (TODO: figure out how to make recurring entries: https://stackoverflow.com/questions/60279898/how-does-calendar-provider-store-instances-of-infinitely-repeating-events)
   7. Drop the court column from Booking table, because it’s fixed, there is only one (so no extra related table needed)

[bbelderbos]

django-admin startproject mysite .
django-admin startapp court
# add court app to INSTALLED_APPS
# create models.py in court app and use makemigrations + migrate
# then code a make booking view