The comment logic doesn’t make sense. Every build gets to write to
the caches; some builds do in fact add new items, and without
clean_unused_caches.py there’s no way for them to remove items.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Fixes#11767.
Previously multi-character emoji sequences weren't matched in the
emoji regex, so we'd convert the characters to separate images,
breaking the intended display.
This change allows us to match the full emoji sequence, and
therefore show the correct image.
This saves the blue box position as state on the location
in brower history, with `history.replaceState`.
The position is restored when a narrow is activated.
Fixes#20066.
We have modified the code to directly fetch realm from Message
object instead of "sender" field and thus we no longer need to
fetch "sender__realm" using select_related.
There is no need to get realm for sender as ScheduledMessage
object also has realm field.
There is no direct benefit of this change but it is nice to
maintain the pattern which we want to follow in the code
in tests as well.
We do not want to access realm from "sender" field so that
we do not need to pass "sender__realm" argument to
select_related call when querying messages. We can instead
pass realm as argument to wildcard_mention_allowed.
We can directly get the realm object from Message object now
and there is no need to get the realm object from "sender"
field of Message object.
After this change, we would not need to fetch "sender__realm"
field using "select_related" and instead only passing "realm"
to select_related when querying Message objects would be enough.
This commit also updates a couple of cases to directly access
realm ID from message object and not message.sender. Although
we have fetched sender object already, so accessing realm_id
from message directly or from message.sender should not matter,
but we can be consistent to directly get realm from Message
object whenever possible.
We do not set realm to Message objects defined for markdown tests
and this works because we currently access realm from sender object.
This commit changes the code to set realm in Message objects as
we would be accessing realm from Message object directly in further
commits.
Previously, if a user tried to create a webhook using the Webhooks
plugin in Sentry and used the "Test plugin" to test the webhook,
the server would send a 500 error, even though the integration
worked perfectly. This led users to believe that the integration
was not working.
Fixes#26173.
Previously, there was no mechanism in place to replace the data.
Therefore, we had to manually delete the stream row when
unsubscribing. However, with the introduction of this new function,
there is no need for manual deletion. The server events code path
already handles the case when any stream is unsubscribed, so we
can simply remove this code.
This commit introduces a new function named
'update_user_profile_streams_list_for_users'. it will be used
to update the stream_list in the unsubscribed streams section.
Since the list_widget offers a function to replace the data, we
can invoke this function whenever there is a subscription change
in the server_events file or stream_events file.
This commit refactors the 'get_subscribed_streams_for_user' function
to return an object with two keys: one for the subscribed streams
and another for the streams the user can subscribe to. The node
tests have been updated accordingly.
Renamed 'get_subscribed_streams_for_user' to 'get_streams_for_user'.
This commit is a prep commit for implementing the live update of
user profile streams list. Since the code for both adding and
removing peers is the same after adding or removing the peer data,
it is better to extract that code to reduce duplication in a new
function called 'process_subscriber_update'.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
In commit 846b470b99, `narrow.by_topic` was missed for getting
the stream name via the stream ID in the message data. Updates
function to get the stream name to pass in the filter terms
to `narrow.activate`.
In that same commit, `narrow.by_recipient` was updated to not
pass the message ID to `then_select_id`. Updates call to
`narrow.activate` to include that opts parameter so that the
selected message doesn't change.
Tweaked provision script to run successfully in Fedora 38 and
included a script to build the groonga libs from source because
the packages in Fedora repos are outdated.
There is a major version jump from the last supported version (F34)
which is EOL so references and support for older versions were
removed.
Fixes: #20635
There was no particular reason for this to be the single page that
documented multiple API endpoints, and splitting it fixes a duplicate
ID parameter-stream_id.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This not only introduces a new gold color that works across light
and dark modes, but it also separates out the hover and focus-
visible styles for stars--regardless of whether a star has been
filled or not.
The :focus-visible selector is more appropriate here, as that
enables browsers to determine whether focus should be displayed
or not. That's generally the case with keyboard-achieved focus,
but pointers and fingers generally do not need focus to be
displayed.
By not displaying a different icon color on simple :focus, this
will also ensure that star icons behave predictably when hovered
or focused via keyboard in both starred and unstarred states.
This corrects for an issue where hover controls would remain
visible after multiple clicks on one of the hover control icons,
despite the mouse pointer leaving the area.
This does not really create a regression for keyboard focus, as
there is currently no reasonable way to get a Tab key into the
hover controls area.
However, if one clicks multiple times on the vdots icon, and uses
Tab to move back and forth, the icons still remain visible--thanks
to the mouse pointer still being in the hover area.
This introduces a new breakpoint. In the future, this kind of
round-about sizing will be made unncessary by container queries,
but while those ship in all modern browsers, their availability
is quite recent:
https://developer.mozilla.org/en-US/docs/Web/CSS/@container
Anders Kaseorg
evykassirer
Sahil Batra
Alex Vandiver
Karl Stolley
David Rosa
Satyam Bansal
palashb01
Greg Price
Lauryn Menard
shu.chen
Junyao Chen