-
Notifications
You must be signed in to change notification settings - Fork 85
Description
Problem
Our MessageController :create endpoint, implemented in #1278 is not enough.
It needs to support creating associated Conversation records alongside the created Message record, for each user specified as the recipient when a project admin is starting the thread.
When a user is starting the thread, a single Conversation record needs to be created for that user.
The question is, which side is the smart one here? Do we specify these associations on the client as directly as possible, the way we do with user skills, for example, or do we specify them dumbly and let the API inferr the correct information?
My vote would go for smarter client, simply because it allows for more flexibility.
When starting a thread as a project
- init new
messagerecord, initiated by admin, authored by current user, belonging to project - for each user (the UI will probably allow for one initially), create new
conversationrecord and put it intomessage.conversations - save the
messagerecord - API casts those asssocations
When starting a thread as a user
- init new
messagerecord, initiated by user, authored by current user, belonging to project - create single new
conversationrecord for current user and put it intomessage.conversations - save the
messagerecord - API casts that one asssocation
The only alternative that I can think of is
When starting thread as project admin
- send virtual attributes indicating a list of users the message targets
- API inferrs users from data in those attributes
When starting thread as user
- API inferss conversation from current user
This alternative makes for a more fragmented codebase and is more difficult to follow, in my opinion, which is why I prefer the first approach.
Subtasks
- Once this discussion is over, close issue and open another one to implement the decided on approach
@joshsmith What do you think?