Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Best way to create Conversations when creating Message #1293

Closed
1 task
begedin opened this issue Dec 12, 2017 · 1 comment · Fixed by #1301
Closed
1 task

Discussion: Best way to create Conversations when creating Message #1293

begedin opened this issue Dec 12, 2017 · 1 comment · Fixed by #1301

Comments

@begedin
Copy link
Contributor

begedin commented Dec 12, 2017

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 message record, initiated by admin, authored by current user, belonging to project
  • for each user (the UI will probably allow for one initially), create new conversation record and put it into message.conversations
  • save the message record
  • API casts those asssocations

When starting a thread as a user

  • init new message record, initiated by user, authored by current user, belonging to project
  • create single new conversation record for current user and put it into message.conversations
  • save the message record
  • 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?

@begedin begedin added this to the Messaging milestone Dec 12, 2017
@begedin begedin mentioned this issue Dec 12, 2017
@joshsmith
Copy link
Contributor

I don't think we even need to support targeting multiple users at first with the messages. Simplest is 1:1 on both sides and expand it later to support more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants