-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move back to message created_at ordering
When a message is approved later about where it should appear in the thread isn't clear but given it was using created at we should just stick with it for now This also adds some message loading via AJAX specs
- Loading branch information
Showing
5 changed files
with
41 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7ed6ca4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the initial created time is the right one to use, not the approval time, as otherwise the logical order of the arguments presented by users in the discussion gets disrupted. E.g. this would be wrong
User 1: Do you agree?
User 1: Glad you agree.
User 2: Yes I do.
where the User 2 message got delayed. Clearly this would be wrong. So created time is best.
7ed6ca4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But User 1 would only see "Yes I do" after it was approved so they couldn't be glad. The argument for approved time is that now new messages can appear anywhere in the message thread so:
Making the newly approved message hard to spot.
7ed6ca4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do agree that created at is a good order as the thread might have moved on by the time the message gets approved. Here threaded email handles it well listing the messages, probably in created at order, but the message where approval was delayed is marked as unread.
7ed6ca4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good point...
My general point is that the created date does reflect properly the views of the user at the time they posted. I think it could end up quite misleading if, for instance, someone replies (but it is delayed), the conversion moves on, that user has changed their mind, and then their previous view then appears just because it got stuck in moderation for whatever reason.
I think the moderation system is akin to a delivery delay, as if an e-mail had got temporarily delayed. In that scenario, the e-mail still shows its original sending time.
7ed6ca4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this is really a problem of messages that are unseen, in web context only, due to a later one having been seen, perhaps the correct solution is ultimately:
I think that solves the problem, but I don't think it's a priority to implement. Sure, they'll re-read the non-delayed 'subsequent' messages, but that's not a huge issue.
If you agree this is the correct solution, could you create this as a new ticket and we can have it sitting there till later. Unless it's quick to implement.