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

Project messaging #1234

Closed
begedin opened this issue Nov 22, 2017 — with Code Corps · 7 comments
Closed

Project messaging #1234

begedin opened this issue Nov 22, 2017 — with Code Corps · 7 comments

Comments

Copy link
Contributor

begedin commented Nov 22, 2017

This task should be considered the start off point for specs and discussion about the project messaging feature.

Our aim here is to have a basic system to allow users to message projects.

From the UI point of view, something like this could do the trick:

Model

  • Initially, it can be as simple as user-to-user, where posting a message to a project simply posts to organization owner
    • we need a sender, a recipient and a body field

Reaching the UI

  • We can add a link to the user dropdown, to reach the message inbox
  • We can add a button to the project page to message a project - this opens the message thread UI and allows the current user to send a message to the project owner

Message inbox

  • we get a list of users we had contact with in the sidebar, ordered by most recent on top. clicking any opens the message thread for that user, on the same page, in the main area next to the sidebar

Message thread

This is where we get to when starting a new message, or clicking an item in the message inbox.

This is basically a route which fetches all messages either sent by the recipient to the current user, or sent to the recipient by the current user, from oldest to newest. Potentially, we can list only the last X messages, and fetch more as we try to scroll up.

There's a new message form at the bottom, which can be as simple as a text area. It does not need to support markdown, or anything like that.

At this point, we have something shippable, and also implementable in a couple of days.

Past this point we can

Enhancements

  • support rendering of links in the message thread
  • add buttons to the project membership page next to each member, to allow project owner and potentially admins/collaborators message each other
  • add a similar button to each user's profile page
  • extend the message model to allow for project-to-user, user-to-project. Since ecto prefers flattened relationships instead of polymorphism, this can be easily built upon in iterations like this. That would mean the project message button now targets project
  • give each message a "read" status. Sounds simple, but with user-to-project, we need to decide how to handle "reading" messages targeted at projects. Might want to merge it with notifications, once we have them, since they'll likely end up serving the same purpose in this context.
  • privacy/do-not-disturb settings
  • add organization as a third recipient/sender option, if there's a need for it
  • plug notifications into it, once we have them
@begedin begedin added this to the Messaging milestone Nov 22, 2017
@joshsmith
Copy link
Contributor

joshsmith commented Dec 4, 2017

We just discussed the model here and came up with a simplified version:

Message

  • subject (required if sent by project)
  • body (HTML or text)
  • initiated_by ("admin" or "user")
  • belongs_to author
  • belongs_to project
  • has_many conversations

Conversation

  • open
  • read_at (last read time by admin in project)
  • belongs_to message
  • belongs_to user (target of conversation)
  • has_many conversation_parts

Conversation Part

  • body
  • read_at (by admin in project if author is user, otherwise by user)
  • belongs_to author
  • belongs_to conversation

@joshsmith
Copy link
Contributor

Message Policy

CREATE

  • if initiated_by "admin"
    • at least project admin
  • if initiated_by "user"
    • author == user

Conversation Policy

CREATE

  • same as message policy

UPDATE

  • if read_at/open set
    • at least project admin

Conversation Part Policy

CREATE

  • if author == user

UPDATE

  • if read_at set
    • if author != user
      • at least project admin
    • OR if author == user

@joshsmith
Copy link
Contributor

joshsmith commented Dec 5, 2017

The things I think we'll need to add UI-wise. You'll notice the user/projects messaging UI is largely the same right now, though over time these will increasingly diverge.

Project contributors list

  • Photo, name, conversation button
  • Remove skills from current UI

Messages for projects

  • Left sidebar list of messages
    • photo
    • name
    • last message time
  • Center main area individual message
    • show conversation parts
      • photo
      • body
      • sent at
      • read at / not seen yet
  • Right sidebar user info
    • photo
    • name
    • skills

Messages for users

  • Left sidebar list of messages
    • photo
    • name
    • last message time
    • project icon + title
  • Center main area individual message
    • show conversation parts
      • photo
      • body
      • sent at
      • read at / not seen yet
  • Right sidebar project info
    • icon
    • title
    • skills

Miscellaneous

  • Message icon in top nav bar that updates when you have a new personal message
  • Update message conversation parts in realtime (channels)
  • Send email if not seen by user after 3 mins

@joshsmith
Copy link
Contributor

I think we're actually going to need to require project_id or user_id when rendering messages from the index. The same is going to be true on Conversation and ConversationPart, including for the show actions.

@joshsmith joshsmith mentioned this issue Dec 5, 2017
@joshsmith
Copy link
Contributor

When a Message is created, we're going to likely want to create the Conversation alongside it.

For the purposes of the MVP, the way we display messages for users/projects is to actually hit the /conversations endpoint.

@begedin
Copy link
Contributor Author

begedin commented Dec 11, 2017

From our meeting today

  • the messages/conversations index page should, by default query conversations initiated by users with any amount of parts, as well as convs. initiated by projects with at least one part (so we don't render unreplied to messages sent out to multiple users)

@joshsmith
Copy link
Contributor

Closing in favor of other issues.

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

No branches or pull requests

2 participants