Users can no longer opt-in for "public" edit history
if site owner disables it.
This feature adds cost and complexity to post rendering since
user options need to be premeptively loaded for every user in the
stream. It is also confusing to explain to communities with private edit
history.
As it stands we load up user records quite frequently on the topic pages,
this in turn pulls all the columns for the users being selected, just to
discard them after they are loaded
New structure keeps all options in a discrete table, this is better organised
and allows us to easily add more column without worrying about bloating the
user table
- add User.staff scope
- inject MessageBus into Ember views (so it can be used by the poll plugin)
- REFACTOR: use more accurate is_first_post? method instead of post_number == 1
- FEATURE: add support for JSON-typed custom fields
- FEATURE: allow plugins to add validation
- FEATURE: add post_custom_fields to PostSerializer
- FEATURE: allow plugins to whitelist post_custom_fields
- FIX: don't bump when post did not save successfully
- FEATURE: polls are supported in any post
- FEATURE: allow for multiple polls in the same post
- FEATURE: multiple choice polls
- FEATURE: rating polls
- FEATURE: new dialect allowing users to preview polls in the composer
FIX: history revision can now properly be hidden
FIX: PostRevision serializer is now entirely dynamic to properly handle
hidden revisions
FIX: default history modal to "side by side" view on mobile
FIX: properly hiden which revision has been hidden
UX: inline category/user/wiki/post_type changes with the revision
details
FEATURE: new '/posts/:post_id/revisions/latest' endpoint to retrieve
latest revision
UX: do not show the hide/show revision button on mobile (no room for
them)
UX: remove CSS transitions on the buttons in the history modal
FIX: PostRevisor now handles all the changes that might create new
revisions
FIX: PostRevision.ensure_consistency! was wrong due to off by 1
mistake...
refactored topic's callbacks for better readability
extracted 'PostRevisionGuardian'
Changed internals so trust levels are referred to with
TrustLevel[1], TrustLevel[2] etc.
This gives us much better flexibility naming trust levels, these names
are meant to be controlled by various communities.
All flags should end up in one of the three dispositions
- Agree
- Disagree
- Defer
In the administration area, the *active* flags section displays 4 buttons
- Agree (hide post + send PM)
- Disagree
- Defer
- Delete
Clicking "Delete" will open a modal that offer to
- Delete Post & Defer Flags
- Delete Post & Agree with Flags
- Delete Spammer (if available)
When the flag has a list associated, the list will now display 1
response and 1 reply and a "show more..." link if there are more in the
conversation. Replying to the conversation will NOT give a disposition.
Moderators must click the buttons that does that.
If someone clicks one buttons, this will add a default moderator message
from that moderator saying what happened.
The *old* flags section now displays the proper dispositions and is
super duper fast (no more N+9999 queries).
FIX: the old list includes deleted topics
FIX: the lists now properly display the topic states (deleted, closed,
archived, hidden, PM)
FIX: flagging a topic that you've already flagged the first post
