[API Hangouts] Create Model for Hangouts Endpoint

[BethanyG]

PARENT TRACKING ISSUE: #160

Based on the current proposed hangouts JSON, create a hangout model for the corresponding DB tables to support the hangouts DRF app.

JSON spec under discussion can be found in issue #161, check there for any changes/discussion.

[BethanyG]

Ok. Clearly more work to do, but here is a first shot at a hangouts_hangout table:

class Hangout(models.Model):
    HANGOUT_TYPES = [
        ('WATCH', 'Watch Me Code'),
        ('PRES', 'Presentation'),
        ('COWRK', 'Co-work with Me'),
        ('STUDY', 'Study Group'),
        ('PAIR', 'Pairing'),
        ('ACNT', 'Keep Me Accountable'),
        ('DISC', 'Discussion'),
        ('TEACH', 'I have something to teach'),
    ]

   guid = models.UUIDField(default=uuid.uuid1, editable=False)
   
   #One of scheduled, pending, rescheduled, stale, hold, closed, completed
   status = models.CharField(blank=True, max_length=200)
   hangout_type = models.CharField(max_length=6, choices=HANGOUT_TYPES)
   
   #we are going to require a title
   title = models.CharField(max_length=200, blank=False)
   slug = models.SlugField(verbose_name=_("Slug"),  max_length=100, allow_unicode=True)
   short_description = models.TextField(max_length=300, blank=False, null=False)
   long_description = models.TextField(max_length=600, blank=True, null=True)
    
   # user who "owns" the hangout we'll pull this from their TOKEN
   user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.SET(get_sentinel_user))
   
   #sort of a public/private thing and confirmed/not confirmed thing
   open_to_RSVP = models.BooleanField(blank=False, null=False, default=False)
   #pending_rsvps = models.ManyToMany(settings.AUTH_USER_MODEL, on_delete=models.SET(get_sentinel_user))
   #confirmed_rsvps = models.ManyToMany(settings.AUTH_USER_MODEL, on_delete=models.SET(get_sentinel_user))
   related_responses = models.ForeignKey(HangoutResponses, on_delete=models.CASCADE, blank=True, null=True)
   
   #Calendar date + start time would be derived from the datetime object
   start_time = models.DateTimeField(default=timezone.now)
  
   #Calendar date + end time would be derived from the datetime object
   end_time = models.DateTimeField(blank=False, null=False)

   # creation date of hangout entry
    created = models.DateTimeField(auto_now_add=True)

    # modification date of hangout entry
    modified = models.DateTimeField(default=timezone.now)
  
   recurring = models.BooleanField(null=False, default=False)
   #related_sessions = models.ForeignKey(Sessions, on_delete=models.CASCADE, blank=True, null=True)
    
   internal_platform = models.BooleanField(null=False, default=True)
   external_platform_link = models.URLField(max_length=300, blank-True, null=True)
    
   related_resources = models.ManyToManyField(Resource, blank=True, null=True, related_name='related_hangouts')
   #related_notes = models.ForeignKey(Notes, on_delete=models.CASCADE, blank=True, null=True)

   # Allow tags to be used across entities
   # E.g. so we can create composite views showing all entities sharing a common tag
    tags = TaggableManager(through=TaggedItems, manager=CustomTaggableManager, blank=True)
    ```

[BethanyG]

If this looks "good enough", we can quickly implement this so we can start iterating on other pieces.

[BethanyG]

I will need to add several "intersection" tables for the many-to-many relationships between (Forgot that Django should do these "automagically" if I use a ManyToMany field)
- users_user (connected through a hangouts_hangout_responses table)
- resources_resource (connected through a hangouts_hangout_resourcess table).

Currently, I am thinking we will also need a child table for related sessions, hangouts_HangoutSession.

[BethanyG]

So this is pretty rough, but here is a first pass at a HangoutResponses model. Some of my open questions:

1. Do we want all types of response here? e.g. do we want to store the messages of interest, the requests to join, and the confirmed RSVPs all in one table? What happens when a hangout moves from "proposed" to "confirmed"? DO the statuses get updated?? Do expressions of interest turn into requests to join when the Hangout becomes confirmed??

2. Can a user comment more than once? If so, how do we store their subsequent comments on a pending hangout? Do we care?? Are responses to pending hangouts better pushed to discussion threads/discussions? Do we only want to track expression of interest, request to join, and RSVP here??

3. What does a status of "closed" mean? Does that mean the RSVP/request is "rejected" by the owner?? I am a little muddy here on the particulars.

class HangoutResponses:(models.Model):
    hangout_id = models.ForeignKey(Hangout, on_delete=models.CASCADE, blank=True, 
                                    null=True, related_name='related_responses')
    hangout_session_id = models.ForeignKey(HangoutSessions, on_delete=models.CASCADE, 
                                           blank=True, null=True, related_name='related_session_responses')
    user_id = user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.SET(get_sentinel_user))
    express_interest = models.BooleanField(blank=False, null=False, default=False)
    request_to_join = models.BooleanField(blank=False, null=False, default=False)
    rsvp = models.BooleanField(blank=False, null=False, default=False)
    response_comment = models.TextField(max_length=300, blank=True, null=True)
    status = models.TextField(max_length=10, blank=False, null=False)

[BethanyG]

Related Sessions model:

class HangoutSessions(models.Model):
    hangout_id = models.ForeignKey(Hangout, on_delete=models.CASCADE, blank=True, null=True,
                                    related_name='related_sessions')
    status = models.CharField(blank=True, max_length=200) #scheduled, pending, rescheduled, stale, hold, closed, completed
    start_time = DateTimeField(default=timezone.now)
    end_time = DateTimeField(blank=False, null=False)
    related_resources = models.ManyToManyField(Resource, blank=True, null=True, related_name='related_hangout_sessions')
    created = models.DateTimeField(auto_now_add=True)
    modified = models.DateTimeField(default=timezone.now)

[BethanyG]

Looking at this one last time, I am not sure if we want to track RSVPs in hangouts_hangout proper (as noted in the pending, and rsvp keys to users_user OR if we just one one reference to hangouts_hangout_responses in hangouts_hangoiut.. and then we link to users in the hangouts_hangout_responses table. sigh.

[lpatmo]

Took a look at your draft PR -- first, THANK YOU for leaving really clear inline comments for the fields! Looks great as a first pass!

I'm a little confused about the HangoutSessions model -- from what I understand, it's meant to contain related hangouts of a given hangout. Do we imagine that a user will select related hangouts to a hangout they're responsible, or that this table will be populated automatically somehow?

Not sure if you still are looking for discussion on the questions you posed above, but taking a stab at answering...

Do we want all types of response here? e.g. do we want to store the messages of interest, the requests to join, and the confirmed RSVPs all in one table?

I think your idea to separate out the messages of interest in a separate HangoutResponses table makes sense.

What happens when a hangout moves from "proposed" to "confirmed"? DO the statuses get updated?? Do expressions of interest turn into requests to join when the Hangout becomes confirmed??

Yes, a status should get updated when a hangout moves from "proposed" to "confirmed."

At the moment, I don't think express_interest should automatically turn into a request to join when a hangout gets confirmed, since 10 people could express interest, but the hangout date could only work for let's say 2 people, and only those 2 people should click "request to join." Then, the hangout host will update the rsvp for those two people from "no" to "yes," and all users with a "yes" RSVP will be able to access the hangout link.

Can a user comment more than once? If so, how do we store their subsequent comments on a pending hangout? Do we care?? Are responses to pending hangouts better pushed to discussion threads/discussions? Do we only want to track expression of interest, request to join, and RSVP here??

Ahhh good questions. If we let people comment more than once, we'll have to create a separate table for that, right? 😅 To be simple, let's punt on that feature and leave it so that people can only comment once now. (We can give them the ability to edit their comment)

I think behavior-wise this will also force the hangout proposer-r to be descriptive with their proposal 🤞

What does a status of "closed" mean? Does that mean the RSVP/request is "rejected" by the owner?? I am a little muddy here on the particulars.

#pending - initial status of a hangout
#scheduled - status as soon as the hangout gets a PATCH with a date
#rescheduled - status when a hangout already has a date, but then gets a PATCH with a new date (? Note: imo this can be a later-down-the-line feature implementation)
#stale - no PATCH updates (i.e. status changes) to the hangout for two weeks?
#hold - not sure
#closed - host or admin takes this step to "delete" a hangout, meaning no new updates can be made on the hangout (maybe we want to make visible only to admins and the host)
#completed - date the hangout was scheduled for has passed

[BethanyG]

I'm a little confused about the HangoutSessions model -- from what I understand, it's meant to contain related hangouts of a given hangout. Do we imagine that a user will select related hangouts to a hangout they're responsible, or that this table will be populated automatically somehow?

So my thought with the hangoutsessions table was (and I am probably over-thinking it) the scenario where a study group agrees to meet every week or 5 times over two months, etc. So the scheduler would click "this hangout is recurring" (or some such) in the UI, then pick the dates (and possibly times) for follow-on sessions. The title and topic and maybe even the resources would stay the same, but the dates/times would change. So .. not exactly a different hangout, but different enough to track in its own table. Again - maybe overthinking this. But then the scheduler could add additional resources if needed to a particular session....and of course attendees could choose to go or skip, and also attach notes/tags/etc.

[BethanyG]

#pending - initial status of a hangout
#scheduled - status as soon as the hangout gets a PATCH with a date
#rescheduled - status when a hangout already has a date, but then gets a PATCH with a new date (? Note: imo this can be a later-down-the-line feature implementation)
#stale - no PATCH updates (i.e. status changes) to the hangout for two weeks?
#hold - not sure
#closed - host or admin takes this step to "delete" a hangout, meaning no new updates can be made on the hangout (maybe we want to make visible only to admins and the host)
#completed - date the hangout was scheduled for has passed

I intended hold for the scenario where a user made a hangout, but has not verified their email..so we can't show it in the UI until they do. But hold might be a bad term for it. Maybe unverified?? Dunno.