Open BethanyG opened 4 years ago
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)
If this looks "good enough", we can quickly implement this so we can start iterating on other pieces.
I will need to add several "intersection" tables for the (Forgot that Django should do these "automagically" if I use a ManyToMany field)
many-to-many
relationships between-
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
.
So this is pretty rough, but here is a first pass at a HangoutResponses
model. Some of my open questions:
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??
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??
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)
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)
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.
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.
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.
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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
still open.
PARENT TRACKING ISSUE
: #160Based 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.