This commit:
* Restructures the doc to use a numbered-step format.
Note that there are no screenshots. I signed up for a
Fabric/Crashlyics account but you have to link an Android/iOS app
to even get to the settings panel, which seemed like too much work
just to get a screenshot.
However, the way we can verify (somewhat) the correctness of the
last step is that it is a paraphrase of the first paragraph of
Fabric's Webhook docs, which can be found here:
https://docs.fabric.io/apple/crashlytics/custom-web-hooks.html
This commit modifies the text to:
1. Removes unnecessary screenshots.
2. Use the numbered-style format.
3. I also removed the instructions for generating an access token.
I took a look at Dropbox's docs and you shouldn't need that
for a webhook setup. The whole point behind a webhook is that
one can get by without using OAuth.
4. Rearranges the instructions to only contain 4 steps. For
uncomplicated instructions, that seems to be the ideal number.
In `recipient-row` template, if conditions to add/hide/show edit
icon for message topic is incorrect.
In some cases, we only want to just hide the edit icon, but icon
should be in DOM, cause in future if organization settings are
changed we want to show edit icon in message row.
If user can edit topic of message, surely add edit icon element to
DOM regardless of user is allowed to edit or not. If user is
allowed to edit then show edit icon otherwise hide edit icon element.
`update_message_topic_editing_pencil` function update edit
icon for message topic in message row header.
- Remove erroneous `meta.loaded` check.
- Add proper check of message editing permission in realm
before updating message-topic-edit-icon in function.
- Update `always-visible-topic-edit` element in function
simultaneously.
Rename `toggle_allow_message_editing_pencil` to
`update_message_topic_editing_pencil` in `settings_org.js`.
As this function update the pencil icon for updating message
topic in message row header.
We fallback to using data-user-email attrib for mention messages
from the times when we use to expose user emails to frontend.
This is only required for cases where we are dealing with anything
that isn't rendered dynamically (like the messages that were already
sent and stored long time ago). Hopefully we won't be needing this
kind of fallback logic in more places so I am putting off efforts
to try to extract fallback logic for common use. Also this is like
this because it will probably be tricky to extract out a common
fallback logic in this case because of different situations involved.
Fixes: #8588.
This provides a slightly clearer interface, allowing us to remove the
unnecessary split of the code for the clone_file_input concept across
multiple modules (we now just clone it on-demand).
This makes it easier for users to tell how Zulip ended up with an
avatar for them without them uploading one: through the Gravatar
service used across many Wordpress blogs.
Fixes#8225.
This field has been unused by clients for some time, and isn't great
for our public archive feature plans (where we'll not want to be
including email addresses in messages).
In stream deactivation modal, make "stream_name" a template variable,
rather than patching stream name to modal header in javascript.
Add tests for deactivation stream modal.
This replaces the cumbersome system we had for giving users feedback
on settings state changes in the display settings UI.
We expect this new system to be what we will attempt to migrate other
settings widgets to match over the coming weeks and months. It also
provides the opportunity to significant refactor away a lot of the
code duplication in settings_display.js.
Thanks to Brock Whittaker for redoing the styling and improving the
code simplicity.
Fixes#7622.
Add `translate_emoticons` to `prop_types` and `expected_keys`.
Furthermore, create a emoji-translating Markdown inline pattern.
Also use a JavaScript version of `translate_emoticons` and then use
this function during Markdown previews and as a preprocessor. This
is only needed for previews, because usually emoticon translation
happens on the backend after sending.
Add tests for emoticon translation, a settings UI, and a /help/ page
as well.
Tweaked by tabbott to fix various test failurse as well as how this
handles whitespace, requiring emoticons to not have adjacent
characters.
Fixes#1768.
Private streams were not included in stream suggestions for default streams
in org settings.
Remove function, which exclude private streams from stream suggestions
for default streams.
These two classes are tricky to test, and nocoverage-ing them
allows us to mark queue_processors.py as fully covered. We
still want to cover these two workers at some point, but for
now, it's nice to enforce full coverage for any future changes
to queue_processors.py.
Fixes (sort of) #6542.
This sets up a new test class with a simple
test, mostly for increasing coverage. The class
should in the future be extended to properly
verify the handle_feedback() logic.
We already check in get_service_bot_events() if a bot is mentioned,
and then only pass on the call to the bot handler if it is. The
commit removes the additional check in the embedded bot queue
processor simply because it is impossible to obtain test coverage
for it (there is no meaningful way to trigger the content of the
if-clause, because there will never be a message reaching the bot
without @-mentioning it.
To alleviate the danger of a potential regression, the check is not
removed completely, but rather replaced by an assert statement.
This appends a space when text is inserted at the end of a message
using `compose_ui.insert_syntax_and_focus`. This is definitely what
users expect when using this feature.
Fixes: #8569.
Previously, when a user updated the config data of an
embedded bot, only the updated fields were dispatched
back to the client. Dispatching all config data fields
makes the client updating code less brittle.