We have two different frontend implementations of computing the
un-resolved form of a topic name, and they have a subtle -- but
intentional -- difference in behavior.
Factor them both out into the resolve_topic module, along with
their inverse, and with comments and tests.
These two conditionals are each relying on the other to trigger
on the same condition, and to do complementary things. Move them
together to a single place so that that relationship is easy to see,
and to refactor.
The most notable change here is that when you are adding
subscribers to a stream as part of creating the stream,
you can now use the same essential pill-based UI for
adding users as we do when you edit subscribers for an
existing stream.
We don't try to exactly mimic the edit-stream UI or
implementation, since when you are adding subscribers
during create-stream, we are just updating a list in
memory, whereas in the edit-stream UI, we immediately
send info to the server.
Fixes#20499
Prefer a regexp match over using String#replace to strip expected
prefixes and suffixes because (a) it implicitly verifies that the
input has the expected format and (b) it won’t unexpectedly strip from
the middle of the string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Muted streams are now greyed out in the personal settings,
also changes to the notification settings of a muted stream are
not possible anymore.
Also, add a bell-slash icon after the stream name of muted streams,
clicking on it unmutes the stream.
Fixes#19780.
353d0f9 removed this test as it was causing alert words test
fail non-deterministically. See 353d0f9's commit message for
some more details.
Rearranging the order to make this test run in the end can
eliminate the non-deterministic failures due to this test.
Because we reset the test database in between test files, we don't
expect there to be any issues with test files running after this.
Changing the password seems to randomly cause one of
our calls to /json/events to return a 401.
The symptom of this is that when you update alert words,
we don't get the event, and the alert words list does
not get updated.
More context here:
https://chat.zulip.org/#narrow/stream/43-automated-testing/topic/alert.20word.20flakes/near/1334824
It is possible that this reflects an actual problem in
our system when you update passwords.
For now, though, the goal is simply to make this test
reliable, so that we don't have to chase down this flake
any more. It was a particularly tricky flake to debug,
since the alert words test really wasn't at fault here.
It's plausible that we don't want to have the app declare
success when the server acks an alert word POST, and the
app should instead wait for the event to come back before
giving any confirmation to the user.
Hides 'disable' button of any kind when nothing is selected
in dropdown list widgets by removing ':enabled' selector from
the button, the button is not actually a button, it's an <a> tag which
doesn't support "disabled" attribute.
Fixes part of #20831.
It's 2022 and the WHATWG no longer recognizes the term URI. Everything
is now a URL or a type of URL. Which is great because it's way less
confusing. Details here:
https://url.spec.whatwg.org/
Moves hash_util.by_stream_uri and hash_util.by_stream_topic_uri to
internal_url so they can be used by external codebases. Due to these
functions being called in many places in the web codebase, wrappers
for both functions are left in hash_util in order to keep these
calls simple.
Also adds test for explicitly testing each function.
Move hash_util.encode_stream_id to internal_url, so it can be shared
with external codebases. Also add a test that explicitly tests escaping
special characters in stream names.
Move stream_data.id_to_slug to internal_url, making it shareable. The
function has been renamed to stream_id_to_slug to reflect that it
operates on a stream id.
Moves the encodeHashComponent and decodeHashComponent functions out of
hash_util and into internal_url which belongs to shared. This is to
accommodate sharing of this code with mobile or any other codebases that
do not wish to duplicate logic.
In order to accommodate the sharing of hash_util with other codebases
including mobile, UI and web specific code should be removed. In this
commit, we remove exception handling for the decodeHashComponent
function and instead add the UI handling of it further up the call
stack.
The stream_data.id_to_slug and stream_data.name_to_slug
functions mistakenly used Javascript's String.replace method,
this commit changes it to use String.replaceAll, the result
being slugs generated from streams with names greater than
2 words are now properly formatted.
This changes the method of rendering list of alert words in DOM,
earlier it was rendered using 'for' loop over the array of alert_words
which is now changed to render using ListWidget, which gets a array
of objects from get_word_list() in alert_words.js.
The use of ListWidget helps to define a parent_container and $container
in table-body of alert-words-table using which we can now apply sorting over
alert words with the help of handle_sort() function in list_widget.js
Changed the method of adding alert_word_settings_item row in table body
through {{#with}} loop because of rendering through ListWidget, which was done
earlier using for loop over each alert-word in while rendering the list.
this commit also mocks template of render_alert_word_item
while mocking ListWidget.create() function in render_alert_words_ui().
and checks that ListWidget.create() is not called when variable `loaded`
is set as false.
Fixes#21142.
We follow how other apps present older messages, e.g. Gmail,
Facebook Messenger, etc. display it.
Specifically, the logic we use is:
If the time is <24hr ago, show an absolute time, like "21:30" (or "9:30pm").
Otherwise, show what day it was, and not a time
If the day was yesterday, say "Yesterday".
Otherwise, if it was <7 days ago, say the day of week, like "Friday".
Otherwise, if it was <1 year ago, say the month and day, like "Sep 6".
Otherwise, say the year, month, and day, like "Sep 9, 2020".
With some tweaks from Tim Abbott to better handle the future case.
Fixes#19775
This commit changes the code to call update_view_on_deactivate function
from server_events_dispatch.js on receiving the user/bot remove event
instead of having it repeatedly in the success_continuation method
of click handlers.
We also add check to make sure we return early if the relevant settings
page is not opened yet.
This simplifies some of our dependencies.
As an example, we really don't want compose.js
to depend on stream_subscribers_ui.js, since
the former doesn't use any actual UI code from
the latter.
We also rename the two functions here:
invite_user_to_stream -> add_user_ids_to_stream
remove_user_from_stream -> remove_user_id_from_stream
(The notion of "inviting" somebody to a stream is
somewhat misleading, since there is really no invitation
mechanism; you just add them.)
Apart from naming changes this is a verbatim code move.
Finally, we eliminate a little bit of test cruft--the
`override` helper already ensures that a function gets
called at least once during a test.
These tests have been historically difficult to maintain.
We have pretty good direct test coverage on the
components used by stream_edit.
The code tested here was mostly glue code and jQuery
code, which the node tests are particularly poorly
suited for testing.
Note that we lose 100% line coverage on
stream_settings_containers.js, but that module
is literally a single-line function to describe
a jQuery container, and the node tests for that
would be more convoluted than helpful.
Since we do not allow to remove owners from bots, it is better
to keep owners for the bots in development environment as well.
We need to change puppeteer tests here because now desdemona
already has bots in dev server and thus "Active bots" section
is opened by default in the settings instead of "Add a new bot"
section.
Notifies user when messages are not being marked as read through a
banner that lets them mark all messages in the narrow as read. Note
that the banner is only displayed if the user's actions, like
scrolling, would've actually marked the messages as read.
This avoids distracting the user when viewing a thread they've already
read.
tabbott has verified that if new messages come in, the banner will reappear.
Fixes: #18768.
Show/hide scroll to bottom button when the last message is
not visible in the current scroll position.
We adjust the bottom offset of the button based on compose box
height.
Fixes#19862
Added a property `mouse_moved_since_typeahead` to the typeahead class
which tracks whether the mouse has been moved since the typeahead
menu appeared.
The hovered over menu item is highlighted on `mouseenter` only if
`mouseMoved` is true. Otherwise, the cursor is hidden temporarily.
Code substantially reorganized by tabbott.
Fixes: #21018.
We want to avoid submit handlers here, because we may
have embedded widgets that have their own forms or
buttons.
We use "finalize" here to distinguish the two Create
buttons related to streams. You hit one button to
start the UI and then the second button to finalize
the process.
I also fix the bad test idiom of clicking on the
sea-green button.
When viewing a narrow such as a search or `sender:` view, where
consecutive messages in the view may not be consecutive in their
original stream/topic context, we should avoid displaying the messages
with a shared sender/recipient bar header, as that creates the
incorrect perception that they are consecutive.
Back in 2013 (bc8bc8567b), we
implemented this via the collapse_messages flag, but it appears more
recent refactoring (no more recent than
dbffb2a614) made it always true.
The original logic was incorrect, in that it only considered full-text
search views, and not other views with this property.
I originally planned to use the existing logic for
can_mark_message_read designed for this purpose, but I think there
might be product reasons why might want the logic to be independent.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm typeahead and the mentions typeahead.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Fixes: #19865.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm pills. Due to the fact that we use the same
pills system to render in the user_group, we need to add a
conditional to prevent rendering there since the user status is not
valuable there.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Previously the emoji_status set by the user would only be seen a few
places, it was decided that it would be useful to show the
emoji_status in a few additional other places as well.
Use the status_emoji template to show the status emoji in the
message_body and also implement live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously the emoji_status set by the user would only be seen in the
buddy list, it was decided that it would be useful to show the
emoji_status in other places as well.
As such this commit uses the status_emoji template to show the status
emoji in the PM list and also implements live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Greg Price
Steve Howell
Anders Kaseorg
Tim Abbott
Julia Bichler
Dinesh
NerdyLucifer
Austin Riba
jai2201
Aman Agrawal
Sahil Batra
N-Shar-ma
YashRE42
AnushaNathRoy