We believe this to already be obsolete and dead code and is about to be
removed with the migration to the FCM HTTP v1 API, where the concept
doesn't exist anymore.
Create the is:followed search operator.
Fetch all messages that are from followed topics
using exists.
Update API documentation and changelog.
Co-authored-by: Kenneth Rodrigues <kenneth.nrk123@gmail.com>
Fixes#27309.
Previously we generated the search_string and display_html as we
generated suggestions. This commit changes the way Attacher works
to generate these strings once we want the final result. This gives
more flexibility, and will let us replace the last item of `result`,
which will be required for implementing search pills.
This is preparation for search pills.
The X button for user pills will be a click target
that disappears from the DOM. We don't want to
look for the parent of a click element that might
not exist, since that would give us a false positive
and lead us to reset the search bar when removing a
user pill. This commit brings this click handler to
a more stable state.
This commit also adds an extra $elem argument to
`settings_panel_menu.set_key_handlers` which defaults to $mail.elem.
This argument helps us specify a specific element to attach the key handlers
to, instead of the entire settings panel.
We will redraw the list on every deactivation or reactivation.
While that might seem expensive to redraw on each user, the other
option we have is to have some logic run each time the tab is selected
and redraw if the user list has changed.
Since deactivation and reactivation is not something that an admin
would do multiple times a day, redrawing on each user should be fine
for now.
We will continue displaying the reactivated/deactivated users in a
greyed out column after the live-update, since it is weird for a user
to disappear suddenly from the list.
Previously, there were three different sections for managing active
users, deactivated users and invitations.
This commit combines users section has into a single tabbed panel.
Fixes: #26949.
Co-authored-by: shashank-23002 <21bec103@iiitdmj.ac.in>
We've added a new stub function that records the arguments passed
to a function called `stub_with_args`. We're only using this right
now for `admin.launch` since we plan to test that arg in the upcoming
commits for the redirect.
For most of the other functions, the args are empty, so it doesn't make
sense to refactor those tests to use this new stub.
Since we are uniting the user settings into a single panel in the
upcoming commits, we are naming the invites tab as `invitations`.
We also replace `invites` with `invitations` on all user facing
strings on this page.
This commit is a preparatory commit for that.
See https://github.com/zulip/zulip/pull/30268#issuecomment-2155213539
This is a preparatory commit to combine user settings panels into
one. We need to re-register event handlers since they get destroyed
when the settings modal is closed. After re-opening the modal,
clicking the tabs would not do anything unless we re-register our
event handlers.
When the organization settings are launched, there
is a duplicate function call to the 'activate_section_or_default'
function to render the correct section.
This commit adds a field to store the section name,
which is then used to render the correct section.
Co-authored-by: shashank-23002 <21bec103@iiitdmj.ac.in>
Previously, is: searches as a spectator would suggest "Direct messages", even though
DMs aren't accessible for spectators. Fix this by moving the is:dm suggestion
logic to `get_is_filter_suggestions`, which is not used for spectators.
Fixes#30320.
Changed the title of the first panel to
"Create channel: configure settings" and title of second panel to
"Create channel: add subscribers".
Implement logic in stream_create.js to show and hide both the panels.
Add two buttons to facilitate switching between the tabs or panels.
Added new descriptions to 'stream type descriptions'.
Removed the "Stream permissions" heading to simplify the panel.
Moved the "Announce new stream in {stream}" option just above
"Default stream for new users".
Implement a collapsible "Advanced configurations" section,
collapsed by default, to accommodate less commonly changed settings.
This allows for future expansion of stream permission configurations.
Fixes part of #29403.
Fixes#14971
Instead of taking user to top / end of fetched history, we take
user to the first / last message of the narrow.
We simply check our cached history if we have the data for the
jump, if not, we ask server for the data.
Tested by simply pressing `fn + left / right arrow` on mac in
combined feed and topic narrows. Also, reduced message_fetch
constant values to be all single digital to check if the -
data not in cache -> fetch data -> select message logic works well.
When there was a race during bulk insertion of UserTopic
rows, it resulted in Integrity error.
We update the 'last_updated' and 'visibility_policy'
columns for conflicting rows.
We also removed the separate update query to update
visibility_policy because now the new SQL query can
handle the updates too. This leads to have fewer round
trips to the database.
In the 'bulk_set_user_topic_visibility_policy_in_database' function,
the 'duplicate_request' variable wasn't improving any readability.
This commit cleans up that variable.
This commit replaces the local 'is_same_server_message_link'
function used in 'get_mobile_push_content' with the
'is_same_server_message_link' lib function.
The lib function is the same logically but uses urllib instead
of regex for parsing and is backed by tests, hence more robust.
This prep commit adds a lib function 'is_same_server_message_link'.
This will be currently used while compressing quote and reply
in push notifications and later can be used at other places.
This is a prep commit to extract out the test cases
for 'test_is_same_server_message_link' in hash_util.test.js
as a test fixture.
This will help in reusing the same test cases in the node and
backend tests.
Also, it will help in making sure that the logic for
'is_same_server_message_link' is in sync, in both the
web client and server code.
The URL bar in iOS shrinks / expands on scrolling causing change
in height. This triggers our resize handler and forces user to
jump to the selected message. This jump triggers before our
keep pointer in view logic kicks in which means user scrolls back
to the previous selected message instead of scrolling forward.
To fix this, we only do this jump when width changes on mobile
devices.
Note that modern devices support resizeable windows of all forms but
for most use cases where app is full expanded, this seems like the
right fix.
This was discussed in the review of #29999:
https://github.com/zulip/zulip/pull/29999#discussion_r1620818568
The previous way of handling wasn't entirely correct, as unnecessary
events were omitted, with a bad guarantee of even being in the correct
order.
This is an improvement as now the function detects that it ended up
doing nothing and can skip sending an event.
The race condition is hard to make up in an automated test, but we can
hackily simulate it by injecting a side_effect which will create a
conflicting UserPresence row when the function requests a cursor. Aside
of that, the actual race was simulated in manual testing to verify the
expected behavior.
Before this commit, 3 DB queries were actually needed for "realm"
event type but the test mentioned 1 because, the related stream
setting fields were already fetched when testing the case for all
event types above it.
So, when testing the query count for only "realm" event type the
cached realm object was used and no extra queries were made for
the stream settings.
This commit updates the test to refetch the realm before testing
each event type separately, so that we test the actual query count.
This commit updates code to prefetch realm group settings like
"can_create_public_channel_group" only when computing settings
for "/register" response by refetching the realm object with
select_related instead of fetching those settings in UserProfile
query.
This change is done because we do not need to prefetch these
settings for every UserProfile object and for most of the cases
where these settings are actually accessed, we can afford extra
query like when checking permission to create streams. But we
cannot afford one query extra for each setting when computing
these settings for "/register" response, so we re-fetch the
realm object with select_related leading to only one extra
query.
The query count changes in tests are -
- Query count increases by 1 when calling fetch_initial_state_data
for computing can_create_public_streams because Realm object from
UserProfile does not have prefetched setting fields.
- Query count increases by one in test_subs where streams are
created which is as expected due to the setting not being prefetched.
- Query count increases by 2 in tests in test_home.py where one
query is to refetch the realm object and one for computing
can_create_public_streams as mentioned above.
This commit makes passing realm mandatory to fetch_initial_state_data.
This is a prep commit for refetching the realm object with
select_related for group setting fields so that extra queries
can be avoided when computing "/registe" response.
Sayam Samal
Mateusz Mandera
nimish
Kenneth Rodrigues
evykassirer
Shubham Padia
Joy Chen
sujal shah
Aman Agrawal
Lauryn Menard
Prakhar Pratyush
Kislay Verma
Sahil Batra
Alex Vandiver