I added these hooks in Zulip Desktop 5.5.0; handling these events in
the frontend will let us remove the janky desktop-side fallback code
that uses fake click events on menu items with specific indexes.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 13c11ec5f3 (#16699) already fixed
the generated curl examples, but missed this, which is the only
hard-coded one.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This handles the conditions when anchor values are larger than
LARGER_THAN_MAX_MESSAGE_ID by clamping them down to it. Also added
tests for the function parse_anchor_value.
Fixes#16768.
This simplifies the code, as it allows using the mechanism of converting
JsonableErrors into a response instead of having separate, but
ultimately similar, logic in RateLimitMiddleware.
We don't touch tests here because "rate limited" error responses are
already verified in test_external.py.
In 1bcb8d8ee8 I made
it so the webapp doesn't include "streams" in its
state from `fetch_initial_state_data`, but I didn't
address all the places in apply_event.
By default all Stripe API amounts are in the currency's smallest unit.
It's upto us to convert it to a bigger unit and show it to the end user.
And refund event used to show the currency in the smallest unit which makes
the output wrong when it comes to most currencies like USD, Europ, INR etc
which uses a bigger unit(eg Dollar instead of Cents) as the standard.
rustc's default edition is 2015 to preserve backwards compatibility, and
the playground appears to follow this scheme. However, 2018 edition Rust
is the current standard and is the default that Cargo uses when
initializing new projects. It adds support for various features,
including async/await and a new module system. As a result, I think
Zulip should default to 2018 edition when linking to the playground.
Users can always select a different edition once in the playground if
they would like.
There are actually two dropdowns for wildcard mention setting,
which would have been added mistakenly while changing the label
and position during merging the original commit for adding this
setting.
This commit removes the extra dropdown dropdown in Other
Permissions subsection and retains the one in Stream
Permissions subsection.
This refactoring should have no functional effect for any call points,
but makes the function behave more naturally. The comments explain
the situation, but specifically:
* There's the page_params.narrow hack that affects both narrows and
home_msg_list.
* There's the shared data for home_msg_list and all_msg_list that
requires we modify the query from home_msg_list.data.public_operators().
And otherwise the logic should just use the operators associated with
the message_list.data object (allowing us to remove the force_fetch
hack added in the last commit).
Hopefully in some future refactoring, we'll be able to migrate those
hacks to live in the Filter object construction and eliminate this
block of conditionals entirely.
In commit ebea17b9a6,
we added an extra fetch to get accurate data for the top
items in recent topics table.
But the `narrow` parameter wasn't passed to the endpoint,
this resulted in fetching the user's overall message
history including the muted streams/topics which aren't
required by the recent topics table.
`operators` can be replaced as we set the same value for
the `narrow_state` module and the narrowed message list's
filter, when activating the narrow.
`wal-g wal-push` has a known bug with occasionally hanging after file
upload to S3[1]; set a rather long timeout on the upload process, so
that we don't simply stall forever when archiving WAL segments.
[1] https://github.com/wal-g/wal-g/issues/656
Update the New Relic webhook and tests to match the format specified
in the New Relic documentation. The new format sends a json body
instead of using url parameters. The old format is no longer supported
by New Relic according to their support staff; as a result, the fixtures for
the old test cases were removed. Added fixtures for new test cases.
Fixes: #16393.
We seem to periodically get contributors who rebase upstream commits
onto their pull request rather than the other way around, resulting in
a lot of GitHub noise. The PRs where this happens were made from
branches named master. We have always documented that you should work
on a feature branch, but not from this page; maybe this will help
reduce that kind of confusion.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The changes made in this commit are as follows:
* The `remove_messages` is moved to the `message_events.js`
file from `ui.js`.
* We refactor `MessageListData.change_message_id` to no
longer require an `opts` parameter as this function
just returns whether we need to rerender or not.
The blueslip error block can be removed since we made
the change to no long defer the data updates in
commit 3b5ba6b2c1,
this case can no longer occur.
The changes made in this commit are as follows:
* We remove the now unused `ui.find_message` which was added
in commit 1666403850.
* We change the function paramter to now accept message ids
instead of messages to eliminate redundant message ids to
message convertion as only the id is required.
* The remove method in MessageListData did not remove the
messages from the hash, it removed only from the items,
this fixes it.
* This commit also fixes a bug where messages are not added
to the current message list if an event is recieved where
messages are moved to this current narrow.
Only the message removal logic was present, which has been
refactored in this commit.
For 3000 messages and 400 users, this saved
about 30 seconds.
We only do two queries per batch of messages
now, and the algorithm is easier to analyze,
as it's just three nested loops.
Anders Kaseorg
Siddharth Asthana
Isaac Evans
Puneeth Chaganti
Ben Steinberg
Sundar Guntnur
rht
Mateusz Mandera
Steve Howell
Vishnu KS
Camelid
Dinesh
ryanreh99
sahil839
Tim Abbott
nikhilmaske-2001
Alex Vandiver
Sourabh Rana
Max Zawisa
Abhishek Yadav