Commit Graph

57 Commits

Author SHA1 Message Date
Durga Akhil Mundroy 146dfa6f0b org-permissions: Add allow_edit_history organiztion setting.
This new setting controls whether or not users are allowed to see the
edit history in a Zulip organization.  It controls access through 2
key mechanisms:

* For long-ago edited messages, get_messages removes the edit history
  content from messages it sends to clients.

* For newly edited messages, clients are responsible for checking the
  setting and not saving the edit history data.  Since the webapp was
  the only client displaying it before this change, this just required
  some changes in message_events.js.

Significantly modified by tabbott to fix some logic bugs and add a
test.
2017-07-16 10:10:06 -07:00
Akhil 6adf241d7e message_edit: Avoid always fetching raw content.
Altered message_edit.start to check for message.raw_content before
retrieving the same from the backend.

With tweaks by tabbott to update, rather than delete, on repeated
edits.

Fixes: #4404.
2017-06-06 22:41:27 -07:00
Steve Howell 8eb86335b9 Extract narrow_state.js.
Despite the length of this commit, it is a very straightforward
moving of code from narrow.js -> narrow_state.js, and then
everything else is just s/narrow.foo()/narrow_state.foo()/
(with a few tiny cleanups to remove some code duplication
in certain callers).

The only new functions are simple setter/getters that
encapsulate the current_filter variable:

    narrow_state.reset_current_filter()
    narrow_state.set_current_filter()
    narrow_state.get_current_filter()

We removed narrow.predicate() as part of this, since it was dead
code.

Also, we removed the shim for narrow_state.set_compose_defaults(),
and since that was the last shim, we removed shim.js from the app.
2017-04-25 09:57:32 -07:00
Tim Abbott 7d8d9c1bf9 Fix message-edit animations being displayed after sending.
This fixes a regression in 3041480600
that would cause anything rendered on the backend differently than on
the frontend to experience this animation.

We actually only want to do the animation when the message content was
changed in a way that generates an edit history event, i.e. a
user-facing edit, not in cases where we're either transparently
swapping in post-backend-rendering content (e.g. with link previews)
or cases where there's a discrepancy between the exact HTML from the
frontend and backend markdown processes (e.g. mentions).
2017-04-21 11:46:35 -07:00
Steve Howell 70b7d4c00b Extract compose_state.js.
This is mostly just moving methods out of compose.js.

The variable `is_composing_message`, which isn't a boolean, has
been renamed to `message_type`, and there are new functions
set_message_type() and get_message_type() that wrap it.

This commit removes some shims related to the global variable
`compose_state`; now, `compose_state` is a typical global
variable with a 1:1 relationship with the module by the same
name.

The new module has 100% line coverage, most of it coming
via the tests on compose_actions.js.  (The methods here are
super simple, so it's a good thing that the tests are somewhat
integrated with a higher layer.)
2017-04-18 12:26:58 -07:00
Steve Howell fd856d728c Extract message_util.js 2017-03-19 21:03:45 -07:00
Steve Howell 8d3d70984d Extract message_events.js. 2017-03-19 21:03:45 -07:00