This declaration already exists in the default CSS.
This declaration was present when the edit history modal was first
given a night mode (then called "dark mode") style in November 2017 in
4f81bdd0a6. It also existed in the
default CSS at that time.
Previously, topic edit diffs in the edit history modal were not
highlighted in the same way as content diffs because the highlighting
CSS rules were inside a .rendered_markdown block. So they affected the
content diffs, which are classed as such, but not the topic diffs.
This commit moves the highlight rules to a
.message_edit_history_content block inside the already existing
#message-edit-history block. .message_edit_history_content had
already existed in the edit history template message_edit_history.hbs,
and is assigned to both the content and topic diffs.
The ability to see topic edits in the edit history was added in
March 2019 in 38be5ea74394d2fd8586038de6ac447b4bbfbf67; the
highlighting worked at that time. It broke four mounths later in July
2019 in 38ffde37e5 when the highlight
rules were moved into a .rendered_markdown block after having been
global.
(As a further aside, .rendered_markdown was only added to the content
diffs in April 2019 in 5c36918c17.
.message_edit_history_content had been first added, to the content
diffs, in February 2019 in 7d42d7b4dbe6eb144a148135db50ad35efc01295.)
Aside from fixing topic edit diffs, this change is just more correct;
the highlight rules don't belong under .rendered_markdown, and they
don't need to be applied globally.
Previously, the edit history modal did not respect the time format
setting (whether to show times in 12-hour or 24-hour format) when
displaying message edit times (#15171).
This commit fixes that by passing the edit times to
timerender.stringify_time(), which takes that setting into account,
instead of just doing a static string formatting operation.
This bug has existed since February 2017, when the edit history UI
was first added in 1a697b6e02.
Fixes#15171.
Currently, the edit history modal does not respect the time format
setting (whether to show times in 12-hour or 24-hour format) when
displaying message edit times (#15171).
This commit refactors how fetch_and_render_message_history() handles
times in order to make fixing that issue in a reasonable way easier.
It will be fixed in a following commit.
Previously, the show_date_row flag for the first entry in the edit
history modal was directly set to `true`, while in all other entries
it was calculated with identical code. Though show_date_row for the
first entry should indeed always be true, there's no need for it to be
a special case.
In preparation for factoring out the calculation of show_date_row,
this commit nominally calculates the first entry's show_date_row with
the same code that is used to calculate show_date_row for all other
entries. Nominally, because it will still always end up being true.
Previously, the logic for when to add a date row to an edit history
entry was checking against the date of the original message (which is
always the first entry in the message history), not the date of the
previous edit. This caused every edit not made on the date of the
original message to show a date row, even if it wasn't the first edit
on that date.
This commit fixes that bug by updating prev_timestamp after processing
each message history entry, whereas before it was only updated after
processing the first one — the original message.
This bug has existed since June 2017, when
84e5fe733c changed how date rows worked;
from only showing one at the top labeled "Earliest" to each entry
having a possibilty of showing one.
Previously it was impossible for a topic-only edit to show a date row
in any circumstance; the code that handles topic-only edits didn't
even attempt to set show_date_row, the flag that determines whether a
date row should be rendered. Now a topic-only edit will show a date row
in the same circumstances as any other edit[1].
This bug has existed since March 2019, when rendering of topic-only
edits was first added in 38be5ea743.
[1] Currently, "the same circumstances as any other edit" means
there'll be a date row on the original message, and then on every edit
not made on the same date as the original message, even if it was't
the first edit on the date it was made. This is a bug that will be
fixed in a following commit. This commit is being made first since
it's fixing a lack-of-information bug, whereas the other bug is a
somewhat less important repeating-information bug.
The activity.process_loaded_messages code path was called when these
tests were originally written in f8e0137. We stopped calling that
code path in 43e5b2d (#15118). This assert test code is no longer
relevant; tested by adding console.log in the function. I came
across this when working on removing activity from the window.
Waiting till DOMContentLoaded event is triggered helps avoid flakes since
puppeteer is very fast and starts doing another task before
everything on the page is loaded. Adding this to log_in function
as almost all tests depend on this which leads to flaky tests if
the other parts of tests just start without even the page being
loaded.
One example this commit helps is for the test `02-site.js`
which is dependent on a function that runs some jquery on the site.
But because of the page not being loaded, we miss jquery and thus
the test fails. `02-site.js` and related code is added in the next
commit.
Co-authored-by: Priyank Patel <priyankp390@gmail.com>
When no credentials are sent to `log_in` function we want to
use the default generated test credentials. This saves us the
work of importing test_credentials everytime we run this function
in a different test which doesn't focus on what credentials are sent
to login.
The `wildcard_mentions_notify` key was missing from the initial
sub data when a new stream was created. Thus `wildcard_mentions_notify`
was undefined and `wildcard_mentions_notify_display` was false.
(This key is used to render the data in the templates)
This caused a bug where the wildcard notifications was unchecked
in the stream personal settings and the newly created stream was
displayed in the stream specific notifications table.
Old topic of the msg edit event can be used to help the client
calculate useful information such as if a change
in current narrow is required.
This fixes our re narrow logic after a stream edit of a topic, with
no change in topic name itself, since the original topic was not
present in the event received and hence the `orig_topic` was
undefined in this case.
This adds 'target_users' parameter to 'attempt_unsubscribe_of_principal`
function in test_subs.py, which accepts list of UserProfile objects to be
unsubscribed, instead of defining users in the function itself.
This change makes the code cleaner and more readable.
Also, 'other_user_subbed' parameter is changed to 'target_users_subbed'
to clearly depict the use of this parameter.
Prior to commit 8b7e70ac27 this system
would simply just .hide() forms when they were closed and
.empty().append() every time it needed to "show_edit". This was not a
very clean way of handling the action of canceling an edit, so
8b7e70ac27 introduced a change that had
the "show_edit" function append the form and the "hide" function
.empty() the form.
However, we overlooked the fact that the user could use browser
history to navigate away and back to the form and use "e" or
"left arrow key" to successfully append another form and get to an
ugly, broken state.
This commit does not revert 8b7e70ac27
as it is still accurate to .empty() when hiding the form, but we add
an early exit if a form already exists, to avoid bugs like the above.
Using an early exit instead of eg .empty().append() ensures that the
user doesn't accidentally lose the entire content of an edit, if they
deselect the input box and press `e`.
Fixes: #15045.
Fix a bug where the color picker reverted the custom color to the
previous one after clicking outside the popover. The bug occurred
because although there is a confirm button, the 'clickoutFiresChanges'
option was set as true, which made the frontend always send two POST
request to edit the stream and, for a reason I wasn't able to discover,
if you hit the confirm button and click outside fast enough, the change
fired by the clickout event sent the old color to the server. It was
fixed by setting the 'clickoutFiresChanges' option to false.
Fixes#15101
If typeahead is used, this adds comma separated search queries
so that multiple search pills don't get combined as one and the
search behaviour remains same as search_pills_enabled = False case.
If typeahead is not used, this prevent the typing of a single comma
after the pill gets created.
Now node_tests/search.js and node_tests/search_legacy.js have
almost identical test besides the search pills related data
processing work.
This is possible since we no longer depend on the values stored
in the input pills and can narrow or search for term based on
the `#search_query` box value.
This was done in commit 02ab48a61e.
This commit removes the 'get_active_user_for_email' function
from people.js. We have removed the use of this function
in the previous commits, which changed the functions using
'get_active_user_for_email' to use user_ids instead of emails.
This commit changes the would_receive_message to use user_id
instead of emails.
This change is done because user_ids are immutable and using
user_ids is the correct way of uniquely identifying user.
The change in 'would_receive_message' also leads to change
in util.is_pm_recipient to use a string of user_ids instead
of emails.
We also know that user_ids passed to 'would_receive_message'
are active user_ids, since we get them from buddy_list.
So we don't need to check whether the user is active, which
was previously being checked by get_active_user_for_email.
This commit changes the needs_subscribe_warning function to
use user_id instead of emails.
This change is done because user_ids are immutable and using
user_ids is the correct way to uniquely identify a user.
We already know that user_ids being passed in this function are
active user_ids, since they come from typeaheads.
So, we only need to call 'people.get_by_user_id', to get the user
object from user_id and do not need to check the active status of
user, which was done previously using 'get_active_user_for_email'.
This commit extracts removing_someone_else logic to the function
'check_if_removing_someone_else' for better readability.
This is a follow up to 2187c84.
Anders Kaseorg
Johannes Hochreiter
Sharif Naas
SiddharthVarshney
Priyank Patel
Dinesh
Ryan Rehman
Aman Agrawal
sahil839
anshgit101
YashRE42
João Maurício
Tim Abbott
Kartik Srivastava