This split notification settings to separate settings for streams,
PM/mention and other notifications settings.
Previously we have to treat them combined, but with this refactor,
we can treat them separately for future changes.
Fixes#8587.
Until page gets load, table lists are empty. Which results in
showing empty-data-text("No data match to search query") in
setting page parallel to loading spinner.
Hide table-list and show loading spniner until
setting page and table-list gets load.
In org settings, loading spinners are not visible, currently
because their size is very small.
Fix this, by increasing width and height of spinners and
adding spinner text, to make spinners more visible.
Fixes#8502
The summary already has a qualifier that basically says it shouldn't
matter for most people -- making it simultaneously the most
complicated bullet there, and among the least likely to matter.
And in fact, this requirement shouldn't matter for *anyone* when first
experimenting with Zulip. If certbot won't work in a given admin's
environment, and the available ways to get a cert aren't convenient,
they can always let the installer generate a self-signed cert to get
going, and circle back to the issue later.
So, make that option clear in the main requirements text, and then
just cut the whole bullet from the summary.
This further reduces the wall of text on the install instructions.
Simultaneously it lightens up the pressure on this summary to be quite
so terse; expand a couple of items into multiple bullets (yet with
fewer words!) for greater readability.
Now down to just 4 steps!
This version tries to prioritize: just two items that we really want
all admins to look at even if they aren't already mentally committed
to running a big production service and reading all the docs.
Namely, the two required in order to really try out Zulip effectively
with one's colleagues.
The screenshots weren't doing much good without being embedded in the
text... and in fact, looking at them for I think the first time,
they're badly out of date with the app. So cut them.
We might add screenshots later, but on the other hand if we do a good
job with the forms themselves, they should be superfluous.
This further shortens the wall of text inside the instructions.
Note that thanks to embedded reST, we now have the power to provide
custom anchors at section headings! Which in particular means this
link won't break if we later tweak the wording of this heading.
This helps shorten the wall of text between the start of the
instructions and the end. Conversely, now that there are fewer
followup steps, the troubleshooting section at the end isn't so
far away to point.
The installation isn't really complete here, and wasn't even when this
was the only success case; the instructions we're giving are for the
next step in the installation.
These instructions don't say what to do in an actual use case for this
option, but decent instructions there will require having a concrete
use case in front of us and designing the flow for it. At this stage,
just say where we are in the normal flow, and an admin who's chosen to
go off that flow can figure out how they want to vary it from there.
This flips the experimental `--express` option to be the default.
We retain the old behavior, where the script exits before
`initialize-database`, as an option `--no-init-db`; it might be useful
in e.g. a migration scenario (from a Zulip install elsewhere, or
another chat system) where the admin wants to set up the database
separately.
The install instructions are adjusted to match, getting shorter by two
steps and a bunch of words. I think this opens up opportunities to
refactor the text to simplify things further, too, but leaving that
for another commit.
Also tweak the "production" test suite to match.
Kind of unfortunate because the `sudo` interface for running a command
is objectively better -- a list of arguments, rather than a string to
be re-parsed by the shell. But some bare-bones machine images lack
`sudo`, so this makes things a bit more portable.
The messages were first being read and passed to the helper
functions channel wise.
This function makes a list of all the messages in the all the channels
beforehand which would be used to pass in the helper functions.
There's probably follow-up work to do here to eliminate these
completely, but this dramatically shrinks the ~1 minute race window
that was previously present between import and test function being
called.
Running this on additional machines would be redundant; additionally,
the FillState checker cron job runs only on cron systems, so this will
crash on other app frontends.
While this is a different system than I'd written up in #8004, I think
this is a better solution to the general problem of cron jobs to run
on just one server.
Fixes#8004.
The problem that prompted this PR is that I couldn't select the API
key of a bot in chrome to copy it, but I could on Firefox.
Using the `auto` proerty value to override the `user-select`
property of a parent does not seem to be compatible
with all browsers.
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.
Tim Abbott
Shubham Dhama
Akash Nimare
Rhea Parekh
YJDave
Greg Price
Lyla Fischer
Vishnu Ks
Cynthia Lin
Xavier Cooney
Eeshan Garg
Aditya Bansal
Shivam Gera