Add conversation part for open/closed status changed

Problem

We need to add a conversation part that includes a simple border and some small text saying either:

• {{You | username}} closed this conversation {{time-ago}}
• {{You | username}} reopened this conversation {{time-ago}}

These parts should not be shown in the user’s view of a conversation. Only the comment part_type should be shown. We’ll have to add a check for whether the user has admin privileges to see that information.

This is blocked by the API adding a part_type for us to determine the type of conversation part to display.

Also needs https://github.com/code-corps/code-corps-api/issues/1322 to be done to be mergeable.

[begedin]

Proposed solution

rename conversations/conversation-part to conversations/conversation-part-comment

All related files

app/components/conversations/conversation-part.js
app/templates/components/conversations/conversation-part.hbs
tests/pages/components/conversations/conversation-part.js
tests/integration/components/conversations/conversation-part-test.js

All references to those files

• page object import in -test.js
• renderPage in tests
• conversation-thread.hbs

add a conversations/conversation-part-closed.hbs

The component needs to inject the currentUser service, to compare the part.author.id with currentUser.user.id and decide if it should render You closed this at... or username closed this at....

add tests for this new component

• Renders “You closed this at…” if current user equals part author
• Renders “username closed this at…” if current user is different from part author

add a conversations/conversation-part-reopened.hbs

The component needs to inject the currentUser service, to compare the part.author.id with currentUser.user.id and decide if it should render You reopened this at... or username reopened this at....

add tests for this new component

• Renders “You reopened this at…” if current user equals part author
• Renders “username reopened this at…” if current user is different from part author

modify conversation thread

• We assume the API will return only those conversation parts we are allowed to see.
• We modify components/conversations/conversation-thread.hbs so that, for each conversation part, it renders a different component
  • if part_type is comment, render the usual conversations/conversation-part.hbs. Might want to rename it to conversation-part-comment
  • if part_type is closed, render conversation-part-closed
  • if part_type is reopened, render conversation-part-reopened, etc.

add tests to support this change

• renders proper component type for comment part type
• renders proper component type for closed part type
• renders proper component type for reopened part type

Add client-filtering of parts based on authorizaton

Wrap non-comment parts in the conversation thread under a {{#if canAdminister project}} helper, to hide non-comment parts from users who aren’t admins on project.

Add integration tests to support this change

• Render a thread with one of each supported part type, register a fake project ability with canAdminister: true
• Render a thread with one of each supported part type ,register a fake project ability with canAdminister: false, see if just the comment part is rendered

See tests/integration/components/task-assignment-test.js on how to register a fake ability

[begedin]

As I said in chat, I like the idea of specifying thread type. It could even be used for other potential features.

There is an argument to be made, however, that if we’re rendering a conversation thread of type “project” and another one of type “user”, why not just call them project-conversation-thread and user-conversation-thread respectively and be done with it?

No {{#if}} switching within the template, no component logic to test. We just test that the project conv page renders a proper thread of x parts and that the user conv page randers a user thread of x parts.

If you think there’s no risk of the user seeing a part that’s not intended for them, then fine.

In my view, If a user is able to, in any way, ever, receive data from the API which they should not be able to see, then our API is unsafe and we need to deal with it immediately.

The ember app rendering or not rendering that data, while adding a minor failsafe, is in no way a fix.

So what I’m saying is, if there is a risk, that means we have an API problem.