This commit changes stream_data.create_sub_from_server_data to use
stream id, instead of stream name, for checking whether subscription
already exists or not. We are using stream ids so that we can avoid
bugs related to live update after stream rename.
This commit changes would_receive_message and want_normal_display
functions in compose_fade.js to use stream id, instead of stream
name, to get sub object. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit changes populate_group_for_message_container function to
use stream id to get sub object, instead of stream name.
We already have stream id from message object, so we can easily
use it to fetch sub. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit changes stream_data.remove_subscriber to use stream id
instead of stream name. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
Thsi commit changes stream_data.add_subscriber to use stream_id
instead of stream name. We are using stream ids so that we can
avoid bugs related to live update after stream rename.
This commit removes stream_edit.rerender function. We directly
call subs.rerender_subscriptions_settings directly from
server_events_dispatch.js, which was the only caller of rerender
function, as we already have sub object.
We are using stream ids so that we can avoid bugs related to live
update after stream rename.
We can use get_sub_by_id instead of get_sub to get the stream info,
as we already have stream id from the message object. We are using
stream ids so that we can avoid bugs related to live update after
stream rename.
This commit changes receives_notifications function to use
stream_ids instead of stream names. We are using stream ids so
that we can avoid bugs related to live update after stream rename.
Prior to this commit has:link, has:attachment, has:image
filter couldn't be applied locally and deferred filtering to
web server. This commits make sure client filters all messages
it can instead of completely deferring to the server and hence
improve speed.
A tradeoff is also made to turn off local echo for has: narrows
as messages with link sent to has:link narrow were locally echoing
to another narrow and not appearing in the active has:link narrow.
Fixes: #6186.
With this implementation of the feature of the automatic theme
detection, we make the following changes in the backend, frontend and
documentation.
This replaces the previous night_mode boolean with an enum, with the
default value being to use the prefers-color-scheme feature of the
operating system to determine which theme to use.
Fixes: #14451.
Co-authored-by: @kPerikou <44238834+kPerikou@users.noreply.github.com>
We can now invite new users as realm owners. We restrict only
owners to invite new users as owners both for single invite
and multiuse invite link. Also, only owners can revoke or resend
owner invitations.
Add arrow key navigation support for recent topics.
Simple jquery is used to allow navigation for filter buttons,
a grid system is used for navigation inside table.
This commit corrects the message shown when we click the add button
for subscribing users to stream with empty input.
We show 'No user to subscribe.' as the message when trying to add
subscribers with empty input.
Fixes#15450.
This improves the logic and fixes the bug where the href was calculated
based on the current URL and not the filter of the current message list.
We now add the '/streams/public/' operator at the start of the operators,
similar to how it is represented in all other cases.
Fixes#15405
This commit removes the click handler used for
'empty_feed_sub_unsub' class.
This class was used only in home.html and was replaced
by 'stream_sub_unsub_button' in 576be51.
This reverts part of b0d632577f.
The problem was that multiple queries were combined as a single
search pill. And since we create the pills then narrow / search,
we added a comma seperator between them for the typeahead lookups
as required by the logic in `input_pill.js`.
This however introduced a new bug where the search suggestions
were incorrect as the typeahead lookup table wasn't updated, so
every time an item from the type ahead was selected it updated
the input string with an invalid operator.
Thus to resolve the first problem, we follow a simpler approach
by extracting all operators from the search string using our
`Filter.parse` logic and next add the pills, one by one.
Whenever a search pill is selected or deleted by a click the navbar
gets rendered as the searchbox loses focus. This allows the user to
be able to continue editing the search query without having to refocus
the searchbox.
A main change is that we now display the navbar if the search box
is not focused. This was already present in the search pills version
but adding it to the legacy version is an improvement.
We sufficiently increase the timeout so that the pills are actually
deleted. This was required when `filter.is_common_narrow()` is true,
as then only we render the narrow description and close the search bar.
This commit also matches another behaviour of the legacy search.
i.e. We narrow every time a search suggestion is clicked.
The now redundant "focusin" and "focusout" event handler tests are
also removed.
Two things were broken here:
* we were using name(s) instead of id(s)
* we were always sending lists that only
had one element
Now we just send "stream_id" instead of "subscriptions".
If anything, we should start sending a list of users
instead of a list of streams. For example, see
the code below:
if peer_user_ids:
for new_user_id in new_user_ids:
event = dict(type="subscription", op="peer_add",
stream_id=stream.id,
user_id=new_user_id)
send_event(realm, event, peer_user_ids)
Note that this only affects the webapp, as mobile/ZT
don't use this.
We recently removed an API call for fetching user list for our
Settings>Users/Deactivated panels, which introduced a bug where
we rendered the users table before last active information is
processed by the frontend.
This commit makes us process presence before rendering our settings
panels. We move the presence init above because we need to initialize
settings_sections before hashchange.
Fixes#15453.
When the user clicks a button that opens a modal, and if we don't break off
the corresponding click event. This condition in the global click handler
will become true and enables all mouse events outside modal.
```js
$(document).on('click', function (e) {
...
// If user clicks outside an active modal
if ($('.modal.in').has(e.target).length === 0) {
// Enable mouse events for the background as the modal closes
$('.overlay.show').attr("style", null);
}
```
Related to #12369.
This commit adds message retention policy details in the subscription_type
text below the stream description.
We do not show any text when realm-level settings is set to forever and
stream-level is set to either forever or realm_default.
This commit adds frontend support for setting and updating message
retention days of a stream from stream settings.
Message retention days can be changed from stream privacy modal of the
stream and can be set from stream_creation_form while creating streams.
Only admins can create streams with message_retention_days value other
than realm_default.
This commit also contains relevant changes to docs.
This commits adds the code for live update of stream_post_policy in
subscription_type text in stream settings.
This is done by passing stream_data.stream_post_policy_values to the
template data, which were not passed previously and the if conditions
were not evaluated correctly.
Previously, we had implemented:
<span class="timestamp" data-timestamp="unix time">Original text</span>
The new syntax is:
<time timestamp="ISO 8601 string">Original text</time>
<span class="timestamp-error">Invalid time format: Original text</span>
Since python and JS interpretations of the ISO format are very
slightly different, we force both of them to drop milliseconds
and use 'Z' instead of '+00:00' to represent that the string is
in UTC. The resultant strings look like: 2011-04-11T10:20:30Z.
Fixes#15431.
There is apparently some way to have two instances
of `.emoji-popover-emoji-map`, although I can't
reproduce it.
This causes an `expectOne` check to fail fairly
deep in the stack.
Now we report it more directly.
This commit and a few previous ones mostly
address #15348 by trying to either a) not
depending on having a single instance of
the popover or b) making it more explicit
in cases where do expect that invariant.
Fixes#15348
This is just a pure refactor for now, but
we may want to modify this to more precisely
determine the active map (in case multiple
pickers are open for some reason).
This is clearly a better home for it, since message_scroll.js is the
only place that reads it, and also lets us provide a clearer name for
the functionality.
Since we are no longer using the "pointer" value sent in
page_params.pointer for anything, there's no value in continuing to
send it from the server to the client.
The remaining code in pointer.js is logic managing state for the
currently selected message.
Since the pointer is no longer used to set the browser's position, we
no longer need this complex code to send updates to the server during
the bankruptcy flow.
It's crazy that we need to do this; one would think that Electron apps
whose sole purpose is to be used with multiple team chat tools would
at least implement the standard desktop notification API correctly.
But it seems worth making this tactical change to prevent every
desktop notification throwing a traceback on those platforms, which if
nothing else results in a lot of error spam.
Fixes#15103.
This was broken when moving the code being called to another file.
This exception caused a pretty weird/nasty bug by interrupting the
message_fetch response handler before it finished updating the
fetch_status data strutures. The end result was that in views where
the "history limited notice" was displayed, local echo would be broken
a confusing notice would be displayed.
In rare situations we would get tracebacks from
list_cursor on the line that I changed here. We
went the entire month of May without a traceback
here, and I can't reproduce the problem.
This is a pretty clear fix, though, and it will
hopefully lead to a more enlightening symptom.
The likely scenario here is that you use `q` to
navigate the stream list and then unsubscribe.
I tested that and couldn't get a traceback,
but I do think the traceback indicates some
possible issues.
The behavior I saw when I did this
appeared to be mostly harmless.
When I deleted a row (by unsubscribing), the code
seemed to effectively disable the cursor. It's
possible we should go to the next row or fully disable
the search.
I opened #15439 to follow up on this and other
cursor-related issues.
The stream_events tests were kinda messy, but
I mostly just consolidated a few sections of
code so that we didn't have to keep
re-stubbing the same functions.
For the actual code, I extracted add_sidebar_row
and then removed the unnecessarily complicated
jQuery trigger mechanisms.
This merges the `exports.get_search_result_legacy` and
`exports.get_search_result` function.
The key differences between the two code paths are as follows:
* We only want to generate suggestions for the queries which
the user is typing or can edit.
For the legacy version, suggestions are displayed for the
entire search string in the searchbox. (`all_operators`)
For the pills enabled version, suggestions are displayed
only for the input which hasn't been converted to pills.
(`query_operators`)
`all_operators` = `base_query_operators` + " " + `query_operators`.
trim is added at the end just to handle the legacy case
where we pass the `base_query` as ''.
* It is not possible to detect whether the user wants to
continue typing in the legacy version. However if the
the searchbox is still focused even after pill creation
we can assume the user still wants to continue typing.
To handle this we push an empty term as the `last` operator.
This is possible since the previous queries have been
completely entered as evident from it's generated pill.
* When using the legacy version, `search_operators` are
the same as `all_operators`, as mentioned in point 1.
In the pills enabled version we perform most of the
computations from the `query_operators`, but we do
require all `all_operators`, only for filtering the last
query's suggestion.
* And there is just one block unique to the legacy search
system. More details are mentioned in the comments of that
block.
We also refactor both the search suggestions node tests,
mainly to make them similar and easier to detect differences
when we switch over to the new version.
