Slack owners and primary owners will be mapped to zulip
realm owners on import.
Previously, we mapped the owner and primary owner roles of slack
to realm admins in zulip. As we have added ROLE_REALM_OWNER in
8bbc074, we now map slack owners and primary owners to owners in
zulip.
Tests are modified for checking all the 3 cases-
- Slack workspace primary owner
- Slack workspace owner
- Slack workspace admin
This commit also has docs changes in 'import-from-slack.md'.
Calling jwt.decode without an algorithms list raises a
DeprecationWarning. This is for protecting against
symmetric/asymmetric key confusion attacks.
This is a backwards-incompatible configuration change.
Fixes#15207.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Generated by pyupgrade --py36-plus --keep-percent-format, but with the
NamedTuple changes reverted (see commit
ba7906a3c6, #15132).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
At the time of creating streams in test_counts.py we earlier did not saved
recipient in the stream object.
stream.recipient is used in many functions so they would throw error.
The right long-term fix here is probably to just use the standard
stream creation functions rather than having a hacky duplicate
here.
Previously, it was unnecessarily difficult to parse the sentence to
determine that "HTTP response" and "internal state of the server
following the request" are the coherent ideas. Even if length wasn't
an issue, e.g. "... and checking both the A and B are correct", the
sentence still feels a bit fragile without a "that".
Since the second phrase is indeed relatively long, and "internal state
of the server" is a reasonable guess for the second coherent idea, the
"the" helps to reset the reader's expectation about where the next
coherent idea starts, and ends.
Lastly, having "both" in front of the two phrases encourages an
assumption that they're shorter (which is especially problematic for
the second phrase), while having it at the end of the sentence helps
to anchor the end of the second phrase; this is especially true since
the absence of "both" before that point encourages an assumption that
you haven't finished reading yet, given that two things have been
mentioned.
This declaration already exists in the default CSS.
This declaration was present when the edit history modal was first
given a night mode (then called "dark mode") style in November 2017 in
4f81bdd0a6. It also existed in the
default CSS at that time.
Previously, topic edit diffs in the edit history modal were not
highlighted in the same way as content diffs because the highlighting
CSS rules were inside a .rendered_markdown block. So they affected the
content diffs, which are classed as such, but not the topic diffs.
This commit moves the highlight rules to a
.message_edit_history_content block inside the already existing
#message-edit-history block. .message_edit_history_content had
already existed in the edit history template message_edit_history.hbs,
and is assigned to both the content and topic diffs.
The ability to see topic edits in the edit history was added in
March 2019 in 38be5ea74394d2fd8586038de6ac447b4bbfbf67; the
highlighting worked at that time. It broke four mounths later in July
2019 in 38ffde37e5 when the highlight
rules were moved into a .rendered_markdown block after having been
global.
(As a further aside, .rendered_markdown was only added to the content
diffs in April 2019 in 5c36918c17.
.message_edit_history_content had been first added, to the content
diffs, in February 2019 in 7d42d7b4dbe6eb144a148135db50ad35efc01295.)
Aside from fixing topic edit diffs, this change is just more correct;
the highlight rules don't belong under .rendered_markdown, and they
don't need to be applied globally.
Previously, the edit history modal did not respect the time format
setting (whether to show times in 12-hour or 24-hour format) when
displaying message edit times (#15171).
This commit fixes that by passing the edit times to
timerender.stringify_time(), which takes that setting into account,
instead of just doing a static string formatting operation.
This bug has existed since February 2017, when the edit history UI
was first added in 1a697b6e02.
Fixes#15171.
Currently, the edit history modal does not respect the time format
setting (whether to show times in 12-hour or 24-hour format) when
displaying message edit times (#15171).
This commit refactors how fetch_and_render_message_history() handles
times in order to make fixing that issue in a reasonable way easier.
It will be fixed in a following commit.
Previously, the show_date_row flag for the first entry in the edit
history modal was directly set to `true`, while in all other entries
it was calculated with identical code. Though show_date_row for the
first entry should indeed always be true, there's no need for it to be
a special case.
In preparation for factoring out the calculation of show_date_row,
this commit nominally calculates the first entry's show_date_row with
the same code that is used to calculate show_date_row for all other
entries. Nominally, because it will still always end up being true.
Previously, the logic for when to add a date row to an edit history
entry was checking against the date of the original message (which is
always the first entry in the message history), not the date of the
previous edit. This caused every edit not made on the date of the
original message to show a date row, even if it wasn't the first edit
on that date.
This commit fixes that bug by updating prev_timestamp after processing
each message history entry, whereas before it was only updated after
processing the first one — the original message.
This bug has existed since June 2017, when
84e5fe733c changed how date rows worked;
from only showing one at the top labeled "Earliest" to each entry
having a possibilty of showing one.
Previously it was impossible for a topic-only edit to show a date row
in any circumstance; the code that handles topic-only edits didn't
even attempt to set show_date_row, the flag that determines whether a
date row should be rendered. Now a topic-only edit will show a date row
in the same circumstances as any other edit[1].
This bug has existed since March 2019, when rendering of topic-only
edits was first added in 38be5ea743.
[1] Currently, "the same circumstances as any other edit" means
there'll be a date row on the original message, and then on every edit
not made on the same date as the original message, even if it was't
the first edit on the date it was made. This is a bug that will be
fixed in a following commit. This commit is being made first since
it's fixing a lack-of-information bug, whereas the other bug is a
somewhat less important repeating-information bug.
The activity.process_loaded_messages code path was called when these
tests were originally written in f8e0137. We stopped calling that
code path in 43e5b2d (#15118). This assert test code is no longer
relevant; tested by adding console.log in the function. I came
across this when working on removing activity from the window.
Waiting till DOMContentLoaded event is triggered helps avoid flakes since
puppeteer is very fast and starts doing another task before
everything on the page is loaded. Adding this to log_in function
as almost all tests depend on this which leads to flaky tests if
the other parts of tests just start without even the page being
loaded.
One example this commit helps is for the test `02-site.js`
which is dependent on a function that runs some jquery on the site.
But because of the page not being loaded, we miss jquery and thus
the test fails. `02-site.js` and related code is added in the next
commit.
Co-authored-by: Priyank Patel <priyankp390@gmail.com>
When no credentials are sent to `log_in` function we want to
use the default generated test credentials. This saves us the
work of importing test_credentials everytime we run this function
in a different test which doesn't focus on what credentials are sent
to login.
The `wildcard_mentions_notify` key was missing from the initial
sub data when a new stream was created. Thus `wildcard_mentions_notify`
was undefined and `wildcard_mentions_notify_display` was false.
(This key is used to render the data in the templates)
This caused a bug where the wildcard notifications was unchecked
in the stream personal settings and the newly created stream was
displayed in the stream specific notifications table.
Old topic of the msg edit event can be used to help the client
calculate useful information such as if a change
in current narrow is required.
This fixes our re narrow logic after a stream edit of a topic, with
no change in topic name itself, since the original topic was not
present in the event received and hence the `orig_topic` was
undefined in this case.
This adds 'target_users' parameter to 'attempt_unsubscribe_of_principal`
function in test_subs.py, which accepts list of UserProfile objects to be
unsubscribed, instead of defining users in the function itself.
This change makes the code cleaner and more readable.
Also, 'other_user_subbed' parameter is changed to 'target_users_subbed'
to clearly depict the use of this parameter.
majordwarf
sahil839
Anders Kaseorg
arpit551
rht
Sharif Naas
Johannes Hochreiter
SiddharthVarshney
Priyank Patel
Dinesh
Ryan Rehman
Aman Agrawal