When the user logs in as an admin, and clicks on the 'edit user'
button under the url path #organization/user-list-admin, the modal
that was displayed didn't contain the user's email address under the
list of information. This commit adds the email input as a readonly
element, which at the very least provides helpful confirmation that
you have the right user.
Fixes part of #11453.
The night logo synchronization on the settings page was perfect, but
the actual display logic had a few problems:
* We were including the realm_logo in context_processors, even though
it is only used in home.py.
* We used different variable names for the templating in navbar.html
than anywhere else the codebase.
* The behavior that the night logo would default to the day logo if
only one was uploaded was not correctly implemented for the navbar
position, either in the synchronization for updates code or the
logic in the navbar.html templates.
Add a background highlight to vote count button if currently
logged in user votes on that option.
Tweaked by tabbott to use better variable names and Rishi for better
styling.
This just puts the style more clearly that one shouldn't be using
`this` to refer to the outer MessageListview object, because that
breaks unexpectedly when inside a loop.
This is the real guts of how we render messages.
It only excludes the border effects, which we
leave in single_message.handlebars.
This is a pure code move, and should remove a lot of nesting that
would otherwise clutter one's view.
The bool `include_sender` will always be `true`
for status messages. Here is the relevant
excerpt from MLV:
message_container.status_message = // ...
message_container.include_sender = true;
We don't need the `include_sender` check in the template.
We could probably also fix the above code, but it's
semantically correct. I mostly care about simplifying
the template.
This is a pure code move. All three places where we use
this partial had the exact same markup, except one place
where I think `auto-select` was inadvertently left off.
This is a pretty coherent chunk of template code
related to these icons:
- edit pencil
- reactions
- chevron
- star
Moving it to a partial will simplify future diffs
where we re-work the message HTML.
This is a pure code move.
Some changes here:
* more whitespace
* avoid else, and just re-state the condition
* avoid long if blocks, just re-state the condition
* use standard `{{#if foo}}` construct
The refactoring of conditionals here will make more
sense in subsequent commits.
This is a pure data function, so it shouldn't be in popovers.js file
(Steve Howell added test coverage here, and tabbott removed an
accidental functional change.)
This fixes an issue where blank lines between blocks were causing
auto-numbering of list to stop before the blank line resulting
in two separate numbered list instead of one.
Edited significantly by tabbott to explain the tricky details in the
comments.
Fixes: #11651.
After discussion, we decided that the red color is too distinct
and does not convey the idea of "almost offline".
This changes the new "unavailable" status circle's color from dark
red to grey, the same color used by the "offline" status circle.
Fixes#11589.
Adds SCSS style for the "unavailable" user status and enables its
usage in `buddy_data.js`.
The style is a red circle with a horizontal line. The values might
look a bit 'magic' but they were considered carefully ` height` of
1px was too thin, 2px was too thick, thus 1.5px was chosen.
Fixing this involves fixing the backend to handle unchanged field
submissions of the Zoom credentials without trying to re-validate the
credentials (for performance) as well as to fetch the already-sent
secret.
Visually, #zoom_help_text acts like
.organization-settings-parent div:first-of-type when the Zoom option
is selected, but isn't treated as such.
No visual change with the #google_hangouts_domain change; just there to make
the code more readable/defensible.
If you topic-edited a single message within a narrow, we would update
all our unreads/sidebar/etc. data structures, and would rerender the
message if appropriate. However, for the corner case of being inside
a topic narrow when you did this, we didn't have logic to remove the
message from the narrow (which is the appropriate situation when you
just topic-edited a message in a narrow).
When topic-editing multiple messages including the currently selected
message (the more common case), we would end up changing the narrow,
resulting in this issue being masked.
Fixes#11601.
The correct behavior here is that we want to ensure there is
whitespace in between the syntax being added and the content on either
side. Our smart_insert logic handled this for the cases that were
common with inserting emoji (etc.), but didn't handle the more complex
cases with "quote and reply".
Fixes#11702.
Accomplished by adding a function to clear the status message with
an empty string. The html is then updated to reflect changes without a
refresh.
Currently, it's a small hassle to clear a status message. This option
makes things a bit easier.
Fixes#11630.
This new helper allows us to do the same operation
on every message in our message_store. We will
use this in a future commit to clear the `is_tall`
flags on all messages, after a resize.
We should be somewhat cautious about using this,
but simple operations should be really fast, even
if you have lots of messages in the store.
Previously, if you were in the process of editing the last message in
a narrow and a new message came in, we'd rerender that second-to-last
message, causing your editing widget to lose focus (and thus the next
few keys you typed to be interpreted as keyboard shortcuts, which
had a good chance of resulting in your navigating somewhere random).
This rerendering was essentially unnecessary; the only change to state
going into the rendering process was the next_is_same_sender CSS class
being toggled on the messagebox in the message. So, at most, we
should have been just toggling that CSS class (and this commit makes
us do precisely that).
It seems like we could further improve this code by just removing the
next_is_same_sender CSS class entirely and removing this block, but
I'm leaving that for follow-up work.
Fixes#11656.
This fixes an issue where closing stream search was not working if
user had not entered a search term and tried to close the search box
by clicking on the close icon; the problem was that we'd end up
re-opening the widget immediately after through event propagation.
Fixes: #11636.
The is_editable field includes topic edits, so we need a separate
field for whether to display these icons which are all for content
editing.
Fixes#11666.
Adblock Plus's "Block social media icons tracking" setting blocks
images with for social media platforms in their names from loading, so
we rename the Google logo to bypass this.
Adblock Plus's "Block social media icons tracking" setting blocked
integration logos for social media platforms from loading, so the logos
are renamed to bypass this.
Fixes#11590.
When copying a message by clicking on "copy and close" button in
message edit box an alert appears that says "Copied!"; Background
of the message is set corresponding with the day mode but not the
night mode. This changes the background of the alert message to
the dark color in night mode.
Also adds tests to ensure that we do not accidentally overwrite
the 'beginning' variable that contains the message content upto
that point. These should prevent similar errors in the future.
The bug was added in 8119258c4d.
The bug here was that when we rerendered messages following local echo
through the echo.process_from_server code path, the eventual call to
_rerender_header() made the implicit assumption that all messages in a
message group had the same date. As a result, it created a totally
new/fake message group and called the rendering logic on that group
without calling the functions for setting up recipient row dates,
which would always result in no recipient bar date being added. This
bug was latent/invisible before, because when introduced, the locally
echoed messages were always being added to a recipient group from
today, where the recipient bar's date area was by default empty anyway.
This latent bug was revealed when we modified the structure of the app
to do date dividers between individual messages within a message
group, rather than strictly between message groups.
When we're handling a single message that was locally echoed, there
will very likely be 0 messages not removed by
`echo.process_from_server`, and we can skip the unnecessary call to
`message_events.insert_new_messages`. This is a small performance
optimization and logical simplification when sending messages.
This commit achieves two things:
1. Changes the UI of the "Create stream" form to make the
textarea previously used to get the stream description
a simple input field of type text (to suggest a single
line description).
2. Adds an extra check on the frontend side to make sure that
when users create a new stream via. the "Create stream"
option in the settings panel, they can't enter any newline
characters (i.e. we disallow the enter key from being
registered when typing out the stream description).
We must also make sure that they cannot copy-and-paste over
descriptions containing newline characters.
resolves#11617
For consistency, we should keep all the code that works with
@mentions in markdown.js. In this case, message_list_view was
rewriting the contents of the mentions in cases where users'
names had been changed since we rendered their mention.
This change should help people discover to distinguish
silent mentions in text as a part of Zulip syntax while
differentiating them from regular mentions.
To test formatting we want a hard coded date, so we
can verify the date arithmetic with stable dates.
To make the test less brittle, we disable the
feature to remove old drafts.
This was an emergency fix. We should probably just
remove the last N drafts instead of having the 30-day
limit. Or we should have a better way to stub the cutoff
date.
The background color of the portico pages aren't true white,
so this commit adjusts it to match the actual portico page
background color to eliminate differences.
This is mostly adding markup, calling some convenient
functions in buddy_data.js, and adjusting CSS.
To make the circles update dynamically, I mostly
orchestrate this though activity.js for now. It's
possible we'll want to adjust that eventually to
happen through something like a `presence_events`
dispatcher, but that's essentially what
a good part of `activity.js` does now.
We're soon gonna have user circles in four different places,
and the fourth place, Private Messages, will have different
size/position CSS.
Now each component does positioning and sizing in its
main CSS file:
user info, group info -- popovers.scss
buddy list, group PMs -- right-sidebar.scss
(We also use the more explicit syntax for padding each
side.)
We now have a function get_user_circle_class
that returns one of these values:
"user_circle_green"
"user_circle_orange"
"user_circle_empty"
And we put that in the templates.
And then CSS renders the circle of the appropriate
color.
The unit tests now explicitly capture whether
we are rendering the correct kind of circle.
This is a pure code move.
We want to use user circles in the left sidebar,
so this code will no longer belong in
right-sidebar.scss.
This code is just related to drawing the circles.
We can still position in size in other CSS files
(with more context-specific selectors).
This fixes a longstanding UI issue when you have way too many recent
private message conversations, as you can now scroll down the list to
find what you're looking for.
Fixes#5384.
Date separator exists inside the message_row, which causes the
message controls to be visible even when hovering on date
separator. These two rules are redundant and cause this buggy
action. Other rules handle the behaviour of message controls
being visible on message box hover. Hence these can be removed.
Previously, if you scrolled down all the way in the left sidebar, and kept
your mouse hovered over a link, you had a feeling that there was still "more
stuff", since you could see the top of "Back to Zulip" peeking out over the
top of the URL Chrome (and maybe some other browsers) add in the bottom left
corner.
This just adds a bit of margin so that "Back to Zulip" is above that when
scrolled all the way down.
The function that was called here has no side
effects. If you don't use its value, it's just
wasted computation. The real action happens
in the subsequent calls to `rebuild_recent`.
Having it say "Clear" when you delete an existing status was a nice touch,
but it's confusing when you first open the modal and the text of the button
says "Clear".
I think the right medium-term solution here is for this modal to have "Save"
and "Cancel" buttons, and for there to be a small UI element in the user
popover itself that allows you to clear your current status.
We now use `fix_positions` to avoid cropping the emoji
picker. You can see cropping pretty easily on a short
screen if you click the smiley icon for reactions on a
message. It's a bit tricky to repro, since some
of the current top/bottom placements are correct, but
it's definitely reproducible.
I think there are opportunities to both simplify
and optimize `popovers.compute_placement`, so that it
plays nicer with `fix_positions`. For example, I would
bias it even more strongly toward favoring right/left
placement. But there are complicating factors--it is
also used by the hotspot code.
And I wanted to especially preserve the current
behavior when you launch the picker from the compose
box. That's one place where it looks pretty bad if
you select "right" instead of "bottom".
The fix_positions argument here fixes the horizontal
position of the stream popover.
It also fixes the vertical position, both in the default case, and
also doing an appropriate adjustment for the case that the color
picker is open.
This contains a few changes by tabbott to, rather than hiding the
arrow unconditionally, only do so when it would no longer point at the
right part of the screen.
Fixes#2374.
Fixes#6059.
Fixes#7290.
We use the `fix_positions` options every time
we launch a user popover, whether it is from
the message pane avatar or the buddy list
chevron.
For the message pane case, we can eliminate
some complexity related to trying to put
the menu above or below the avatar. We now
always suggest "right", and if there are
constraints due to being close to the edge
of the screen, the fix_positions code
will take care of it.
The patch to bootstrap will make the position smarter, but we still
want to preserve the 100px default vertical offset we chose for visual
reasons.
Tweaked by tabbott to preserve the visual design.
Changed <h5> to <p>, and removed the special formatting of
.empty_search_text to make this more in line with the formatting we
generally use with empty narrows.
This removes the left border extending the stream label from the
recipient bar in from the drafts in drafts modal. Those borders are
important in the message feed for containing several messages, but
here we're only ever going to show individual drafts, and this change
avoids potential color clashes with the blue box surrounding the
recipient blocks.
This removes the change in background to a darker one for active draft,
also removes the change in recipient_row_date color to blue; adds a blue
border around the draft box.
Since the bootstrap popovers are destroyed asynchronously so opening a
emoji popover in quick succession like by clicking the reaction button
on another message was causing a race condition which was causing some
operations to be applied on a destroyed emoji popover. This commit
fixes it by making sure to apply any operations only to the currently
active popover.
Fixes: #9851.
I'm torn about this, since there is good content here. But ultimately I think
* This page is a lot of work to write and maintain.
* In most cases, the right thing is for people to find the page that
explains the full feature. E.g. if you don't know what an "administrator"
is, the page I hope you find is "Roles and Permissions". For bots, it's
"Bots and Integrations". Writing a punchy short summary for a glossary
that does better than that is possible, but not fast.
* People find things via search, e.g. by Googling "What is X in Zulip",
rather than looking for a glossary.
* This page was written more than 3 years ago, before we had 100+ help
articles. So it may have served a purpose in the past that no longer
exists.
Adds three helper functions - `row_with_focus`, `row_before_focus` and
`row_after_focus` to get the focused, previous and next to focused
draft rows respectively.
`delete_id` in `drafts.js` referred to the next draft row which was
to be focused when deleting using hot keys. The var name was absurd
and is hence renamed.
Adds a `remove_draft` function which deletes the draft and updates the ui
by removing it from the list of drafts.
Also adds comments to increase readability.
Show "sent to different narrow" notification and other such notification by
notifications.notify_local_mixes for non locally echoed message sent by
current client.
With significant new comments added by tabbott.
Fixes: #11488.
Previously, this was only available in the Zulip development
environment.
Further work is needed on documenting this and how to use it for
managing work to follow up on.
The width of the messages div is set to 600px, while the
digest-email-container can be 500px at the most. Increasing the width
of the digest-email-container makes the /digest slightly more
readable.
The padding changes move the number a bit to the right and down, towards
where the bottom right corner of an unread count box would have been. This
makes the number look better aligned with the unread count boxes above it.
We swallow the error if our python_to_js_filter code is
unable to parse some python regex properly. This ensures
that the web app stays responsive.
We would fail to show an accurate local echo for these
regexes, however, the backend would act as the final
authority for handling the realm pattern conversion.
Since on replacing the first 'P<>' group, we remove this text from
the string, we have to make the RegExp start looking from index 0
again to properly convert later 'P<>' groups to JS regex syntax.
We want the search widget, when visible, to be
outside the scroll container for the stream list.
One obvious use case is if you start scrolling, and
then realize it might be less effort to search.
Also, for user search, it already worked this way.
We have to add a couple resizing hooks here, but
it's not necessary to change the actual resize
calculation, since we move the section inside
of #streams_header, which is already accounted
for.
The only markup change here is to add
a `stream_search_section` class. I don't
know why we use `notdisplayed` here instead of
jQuery, or what `input-append` is for, but I
considered them outside the scope of this change.
We can also remove some crufty CSS that was
compensating for it being inside the container.
First, we are not removing Group PMs from the
right sidebar, where most people see it.
There is a setting called:
[ ] User list in left sidebar in narrow windows
There are probably very few people that turn that on,
and even when they do, the setting only takes effect
when your window is less than a certain width.
This feature bitrots very quickly, because very few
core maintainers use it.
It's already kind of broken. It gets very crowded,
and we get CSS bugs when we move the right sidebar
into the left sidebar. (We can fix those bugs, but
they crop up unexpectedly due to the nature of CSS.)
We historically tried to maintain a ratio between
stream list, single-user buddy list, and group-user
buddy list, but the group-user buddy list gets
particularly crowded out, and it's basically useless
now.
We want to revisit the entire feature eventually, but
this commit at least gives the normal buddy list some
breathing room.
Also, if you need to see the info in the group PM
list, you can basically expand "Private Messages" to
see your recent group PM conversations. And if you
want to see who's actually online, that info is
already implicit from the normal buddy list.
If users have the option to put user lists in
the left sidebar for narrow windows, they will
now get 15px more of real estate in the left
sidebar.
I just removed the `-15` fudge factor.
We were double-counting the keyboard icon's
margin (8px) when figuring out how much room
we had for the two users lists.
Now we just use the safe outer height of
the anchor tag.
This change only impacts users who have the setting
to put the user lists in the left sidebar when they
have a narrow window.
First, we move ".right-sidebar-items" as an entire
group.
Second, we append the items to "#left-sidebar"
instead of ".narrows_panel".
The name `bottom_sidebar` was misleading, because it
includes the entire "normal" left sidebar.
It includes the 4 narrow links at the top plus the
stream/topic list.
We now call is narrows_panel.
Note that the left sidebar sometimes also includes
the user list (with a display setting turned on).
And it will eventually include other views.
We also remove an intermediate value in the resize
calculations.
This adds date dividers within a single message group when the only
reason we had previously been splitting apart two message groups is a
change of date. The overall effect is a cleaner message list user
experience.
The downside of this change would be that the recipient bars no longer
will always show a new date for date changes; to fix that, we rewrite
how the floating recipient bars both set the date field on the
floating recipient bar itself, as well as ensure that non-floating
recipient bars don't show duplicate dates.
In a future design update where we modify how message recipient bars
look, we may very well be able to simplify this logic by removing some
of the dynamic nature of the recipient bar calculations. But this is
a good implementation of what remains.
Tweaked significantly by tabbott from Steve Howell's original, both to
extract these changes from a larger PR as well as to modify the
first_visible_message logic to handle some tricky corner cases.
Fixes#10171.
On clicking the edit button for a stream description, the stream's
unrendered description should be made editable as text instead of
the stream's rendered description (which would be displayed as HTML
instead of text).
This completes the effort to use backend-rendered stream descriptions
here. Fixes#11272.
Use the results of commit #73d26c8 to remove the method
`render_stream_description` in static/js/stream_data.js and instead
use the rendered_description attribute now being sent by the backend.
This will be a valuable optimization and a step towards removing the
need for the marked.js markdown parser and speeding up the client end.
This changes the border-radius to 6px for the tabbed display, which is not
in line with the current Zulip style for border-radius (4px). However 6px
really looks a lot better for this (possibly because it's a bigger box than
most of our other boxes?)
The message_edit_history UI was incorrectly inheriting its content
div's structure from message_edit_content, i.e. the form for editing
message content, and not message_content, i.e. the class for rendering
the content of messages in the message feed (which we also use for
drafts).
Fix this by changing the inheritance, while also adding a (currently
unused) class for any future customizations.
Fixes: #5629.
This extract functions `get_mention_candidates_data` &
`filter_mention_name` to make code reusable and cleaner and further use
the logic in silent mention syntax.
Having a tiny bit of margin below the stream list
makes it possible to see the bottom of the scrollbar.
It also makes it so that the scrollbar activates
for a tiny range of list sizes where before the
last element would have been right up against the
bottom of the page, but we wouldn't scroll.
We need to move the update_group_date_divider call to run when a
message group is created. This achieves a few things:
* Fixes calling this multiple times useless for long message groups.
* It will soon no longer be correct to assume that every message
within a group has the same date, and in that case, we want to process
the date of the first message in the group, not of the last.
We only generate message_containers in one place, and that code path
already calls update_timestr. And update_timestr's effect only
depends on the message. Thus, this code was useless.
In small screen sizes, when the user presses shortcut `w` to search
for another user, the hide_all function calls in the search code path
would hide the right sidebar, immediately after opening it, making the
hotkey basically unusable.
We fix this by extracting a separate hide method that hides all true
popovers, but not the user list sidebar.
Fixes#11463.
The `uploadFinished` code switches on the composing mode, if we aren't
in the composing mode already. This causes the focus to be incorrect
when this code path runs due to an upload from the message edit
box. This commit fixes that logic to turn on the composing mode or
switches focus to the message edit box, depending on where the upload
was triggered.
So the top navbar is above the left sidebar
on the z-axis, not the y-axis.
So it doesn't make sense to use the top
navbar in calculating the size of the left
sidebar.
It kind of coincidentally works, since these
two numbers are closely related:
left sidebar top margin = 50
navbar height = 40
Calculating `bottom_sidebar_height` correctly
decreases its value by 10.
And then the only value that depends on it
is `stream_filters_max_height`. We were
subtracting out 10 there to make it work,
since `bottom_sidebar_height` was inaccurate
by +10. Now that's fixed.
The comment there was inaccurate--the
`stream_filter` div actually has a bottom
margin of 22px. The bottom margin does
have some consequences for scrolling,
but the main goal here is to make the
calculation return the same value but
be more accurate about what happens
toward the top of the screen.
We have always intended to have 10px of whitespace
below the navbar, and this enforces it directly
and explicitly in the CSS.
Note that the three major panels still should
have a margin of 50px, which is equal to
the safe outer height of the header (40px + 10px).
The border makes the alignment look nicer. Without
a border your eyes plays tricks on you and makes it
seem like numbers are not in the same column.
The border color is the same subtle color as the
backgrounds in others.
Because CSS is annoying, you have to tweak the padding
to make room for the border.
(It should look ok in night mode, too.)
Since the main autoscroll feature was implemeneted, the
maybe_advance_to_recently_sent_message logic had an unfortunate
structure, where the code for this potentially large scroll was
running AFTER the autoscroll decision was made, but before an actual
scroll could have occurred.
This resulted in code that was very difficult to reason about, as
there were 2 potential sources of scrolling when you send a new
message, with little connection between their implementations either
in location or implementation.
Moving this into the main autoscrolling code path clarifies the code,
with the added benefit of fixing a bug where we would report to the
user that they needed to scroll down when in fact we were just about
to scroll the bottom of the feed into view (via
maybe_advance_to_recently_sent_message).
With this change, we never display the "you need to scroll manually"
message in the cast that we just scrolled you there via selecting a
message.
When you just sent a large message, our logic for "you need to scroll"
notifications did not correctly take into account the height of the
compose box. This was easily reproduced when sending very long
messages. The correct solution requires a bit of math to compute what
the visible area will look like after the compose box is closed.
This should be the final fix to #11138.
This adds a function that controls the whole process of applying
markdown and displaying the markdown rendering preview on request;
This is required to avoid code duplication when adding preview feature
to message-edit UI.
We had disabled reference style links in bugdown, however,
we hadn't disabled them in marked. This commit rectifies
that and adds test cases for the same.
Fixes#11350.
The beforeSubmit function was a feature of the jquery-form plugin that
we removed months ago; the appropriate similar feature of jQuery's
built-in AJAX library is beforeSend.
This code will correctly add video call link to the message
textarea based on whether 'Add video call' was selected from
message composition form or message edit form.
The implementation was semi-rewritten by tabbott to remove an
unnecessary global variable, with fixes for the unit tests from
showell.
Fixes#11188.
This is primarily a feature for onboarding, where an organization
administrator might send a bunch of random test messages as part of
joining, but then want a pristine organization when their users later
join.
But it can theoretically be used for other use cases (e.g. for
moderation or removing threads that are problematic in some way).
Tweaked by tabbott to handle corner cases with
is_history_public_to_subscribers.
Fixes#10912.
This replaces the current usage of stream names with stream ids.
This commit also removes the `traditional` attribute from the invite
form as now we are sending stream_ids as an argument; this was the
only place in the codebase we used traditional=true, and it's great to
have it removed.
This function unlike `invite_streams()` returns an array of objects having
various info (name, stream_id, invite_only, default_stream) related to
streams rather than an array of names of streams.
We now compute the class that drives the tiny
green/orange/empty dot in the user popover using
the same logic as the buddy list.
This was broken in the early implementation of
set/clear-away, but it was never released.
Fixes#11413
This makes it possible to mention a user with a name like Gaël that
contains diacritics by typing e.g. "Gael", significantly reducing the
need to use a special keyboard to mention other users.
Fixes#11183.
The only time we set the `home` flag to true
is when it's the last (and only) item in the
list, in which case we flip `hash` to false
at the end of `make_tab_data()`.
So the section of code where both `home` and
`flag` were true is dead code.
Also, we can use `else` instead of `unless`.
The following elements in the top left corner
are major components of our app:
All messages
Private messages
Starred messages
Mentions
We can now find them directly:
$('.top_left_all_messages')
$('.top_left_private_messages')
$('.top_left_starred_messages')
$('.top_left_mentions')
Before this, we had to build up complicated selectors
like below:
exports.get_global_filter_li = function (filter_name) {
var selector = "#global_filters li[data-name='"
+ filter_name + "']";
return $(selector);
};
I don't think any newbie would know to grep for "global_filter",
and I've seen a PR where somebody added specific markup here
to "Private messages" because they couldn't grok the old scheme.
Another thing to note is that we still have a "home-link"
class for "All messages", which overlapped with portico
code that had the same name. (There were some inaccurate
comments in the code relating to the tab bar, but we don't
actually have a way to click to the home view in the tab
bar any more.) I'll eliminate that cruft in another commit.
For this commit the four elements still have the
"global-filter" class, since there's some benefit to being
able to style them all as a group, although we should give
it a nicer name in a subsequent commit.
Most of this PR is basic search/replace, but I did add a
two-line helper: `top_left_corner.update_starred_count`
We had initially designed the poll widget like a blog
post with comments beneath it but it makes more sense
to think of it as just a simple poll with options.
We add a new syntax which converts the messages like the following:
```
/poll Who do you support?
Nadal
- Djokovic
```
to a poll with the two names as options. The list syntax is optional
since anyone making a poll is likely to want to create a list anyway.
When you hover over a user that has set a user
status, we now show something like "out to lunch."
You can test this in the console by doing:
user_status.server_update({status_text: 'out to lunch'})
And then hover over your name in the buddy list.
The name `insert_user_into_list` is sort of misleading,
since we are often just redrawing the user's existing
item in the buddy list.
I chose `redraw_user` over `update_user` to emphasize
that we're just going to redraw it with whatever data
has been updated by the callers.
This fixes an annoying bug where clicking to subscribe to a stream
would change the color shown in the "manage streams" UI immediately
after you click.
Fixes#11072.
This adds a setting under "Notification" section of
"Organization settings" tab, which enables Organization administrator to
control whether the missed message emails include the message content or
not.
Fixes: #11123.
The commit f863a9b567 had modified
jquery.filedrop's paste method to exit early if any of the items in the
clipboardData is of the string kind. The early exit was added to prevent pasting
an image thumbnail for text copied from software like MS Word, instead of
pasting the actual copied text content. When copying an image in a (modern?)
Browser, though, the clipboard seems to contain a html `img` tag item, along
with the actual image file. This resulted in pastes being broken.
This commit modifies the condition checked for the early exit. We now actually
look at the html content in the clipboard to see if it is an `img` tag, in which
case we upload the image, instead of exiting early.
Closes#7130.
This is likely not the "right" fix in that it involved a negative
margin, but this does eliminate an annoying visual glitch where the
scrollbar overflows above its container in the left sidebar, without
creating other apparent problems.
Fixes#8731.
User was able to click delete button multiple time which could cause
multiple delete requests. This commit disables and hides the delete
message button after the first click and shows a spinner until http
the delete request responds.
Also adds a casperjs test to ensure that spinner becomes visible and
delete button becomes invisible after clicking on delete button for
first time and hides spinner and show delete buttton when message is
deleted.
Fixes: #11219.
This fixes a section of code that hasn't really
been turned on yet. We decided to rename
"info" to "status_text", and I apparently missed
this. We don't have any UI to set these yet,
so it was a harmless bug.
I'll try to get some better test coverage on this
when I tweak the buddy list to show user status.
This commit takes away the ability for non-admin members to create
streams where only admins can post messages by hiding the option from
them.
Fixes#11290.
You can now pass in an info field with a value
like "out to lunch" to the /users/me/status,
and the server will include that in its outbound
events.
The semantics here are that both "away" and
"status_text" have to have defined values in order
to cause changes. You can omit the keys or
pass in None when values don't change.
The way you clear info is to pass the empty
string.
We also change page_params to have a dictionary
called "user_status" instead of a set of user
ids. This requires a few small changes on the
frontend. (We will add "status_text" support in
subsequent commits; the changes here just keep
the "away" feature working correctly.)
We had a bug where if you started typing a message
and then used quote/reply (after the fact), we
would overwrite the user's original message.
The bug was kind of subtle--the internal call
to "respond" to the message would select the message
text, and then `smart_insert` would replace the
selection, unless it was Firefox.
Note that we now also allow you to cross-post
replies, which is a plausible scenario, although
possibly unintentional at times, too. I'm erring
on the side of giving the user control here, but
I'll add a warning in the next commit. Our compose
fade feature should also prevent unintentional
mixes here, too.
We often need to go to the server to get raw content.
The exceptions are messages for which we've already
fetched the raw content for some other reason (maybe
a previous quote-and-reply) or which are locally echoed.
Whether we can get the raw content locally or from
the server, the replace_content() logic is the same.
NOTE: If you revert this commit, you want to revert
the immediately prior commit as well. The history
is that Ishan made some improvements to the widget,
but there were some minor bugs. I decided not
to squash the commits together so that the git
history is clear who did what. (In particular, I
want questions about the JS code to come to me if
somebody does `git blame`.)
Anyway...
This is a fairly significant rewrite of the polling
widget, where I clean up the overall structure of
the code (including things from before the prior
fix) and try to polish the prior commit a bit as
well.
There are a few new features:
* We tell "other" users to wait for the poll
to start (if there's no question yet).
* We tip the author to say "/poll foo" (as
needed).
* We add edit controls for the question.
* We don't allow new choices until there's
a question.
This also fixes few unusual UI issues like an invitation got failed when
certain emails can't be invited then the error box is left with "warning"
even when next request got succeed and another case when invitation got
succeed after failing it's still reported with "alert-error" class alert
banner.
It's no longer used, as can be seen in
2d52463b61, in past we use `type` for
specifiying whether status is 'subscriptions-status' or else, which isn't
used now, hence `type` is removed here.
This reverts the temporary fix done in commit
46f4e58782 and replaced it with the fix that
non-admins should be able to see a dropdown to select a non-admin type of
invited user i.e. normal member or guest user.
This commit fixes a bug that caused:
1: A valid full name on an onboarding form to be cleared after an
invalid submission.
2: Incorrectly cleared name populated from LDAP which was janky from
UX perspective.
Ideally we should disable name change for LDAP as next login
will overwrite any changes but I think that can be done in a
separate PR.
Fixes: #10867.
On the backend, we extend the BlockQuoteProcessor's clean function that
just removes '>' from the start of each line to convert each mention to
have the silent mention syntax, before UserMentionPattern is invoked.
The frontend, however, has an edge case where if you are mentioned in
some message and you quote it while having mentioned yourself above
the quoted message, you wouldn't see the red highlight till we get the
final rendered message from the backend.
This is such a subtle glitch that it's likely not worth worrying about.
Fixes#8025.
These mentions look like regular mentions except they do not
trigger any notification for the person mentioned. These are
primarily to be used when you make a bot take an action and
the bot mentions you, or when you quote a message that mentions
you.
Fixes#11221.
Users can preview their profile from user settings. If user
open preview profile modal from user settings, then closing
preview profile modal should redirect them to settings modal
again (since probably they want to keep editing).
This commit fixes above issue.
This adds the same style of "Saving"/"Saved" loading spinners we use
elsewhere in our settings.
Tweaked significantly by tabbott to fix issues with the notifications
being on the wrong screen for reactiving/deactivating users; this was
done by introducing the get_status_field helper function and using it
everywhere.
The legacy "Updated Successfully" message shown after saving changes,
is removed, and replaced with our standard "Saving" spinner and
animation.
Fixes: #11177.
This code will correctly render emoji to the message textarea based on
whether emoji was selected from message composition form or message
edit form.
Fixes part of #11188.
AFAIK I should this never fail, hence the blueslip.error line. But it
is failing in practice when rendering user groups after looking them
up by ID, and the error handling should definitely be softer.
Our recent work on inviting users as guests accidentally set the
invite_as argument in a way that would fail for non-admin users.
Fixes#11283, fixes#11255.
We do this because now we send a message to stream if a reminder
is set and won't need the notification above the compose box saying
that we set a reminder. We would still need that notifications for
the send later feature so we make the construct conditional.
In between releases, the following commit introduced
a bug where we agressively scroll to the top every
place we call `ui.update_scrollbar`:
092b73d0b7
The main symptoms were that the left and right sidebars
would go to the top for things like selecting a topic,
getting activity updates from the server, and resizing
the window. It was very jarring.
The recent commit looked innocuous--the root of the problem
was the original API expressed an intent to scroll to the
top, but didn't actually do it, so it was a bug in hiding.
There are **some** occasions where it's actually appropriate
to scroll to the top, mostly around search filtering, and
in those places we now call the new `ui.reset_scrollbar`
function.
This is a bit of an emergency fix, so particularly with
the settings stuff, we may get more reports of glitches here.
The important thing here is that you almost never want to
reset the scrollTop for sidebars.
This seems like a small change (apart from all the
test changes), but it fundamentally changes how
the app finds "topic" on message objects. Now
all code that used to set "subject" now sets "topic"
on message-like objects. We convert incoming messages
to have topic, and we write to "topic" all the way up
to hitting the server (which now accepts "topic" on
incoming endpoints).
We fall back to subject as needed, but the code will
emit a warning that should be heeded--the "subject"
field is prone to becoming stale for things like
topic changes.
We recently added a feature to warn users that they
may need to scroll down to view messages that they
just sent, but it was broken due to various complexities
in the rendering code path.
Now we compute it a bit more rigorously.
It requires us to pass some info about rendering up
and down the stack, which is why it's kind of a long
commit, but the bulk of the logic is in these JS files:
* message_list_view.js
* notifications.js
I choose to pass structs around instead of booleans,
because I anticipate we may eventually add more metadata
about rendering to it, plus bools are just kinda brittle.
(The exceptions are that `_maybe_autoscroll`, which
is at the bottom of the stack, just passes back a simple
boolean, and `notify_local_mixes`, also at the bottom
of the stack, just accepts a simple boolean.)
This errs on the side of warning the user, even if the
new message is partially visible.
Fixes#11138
We now have two functions:
add_new_messages
add_old_messages
This is a lot easier on the eyes, and it will also
prevent us from exceeding line length in future commits.
We also remove an unneeded stub in the narrow_activate
tests.
This commit makes it a bit more explicit about
why we're updating 2 or 3 message lists every time.
It looks funny now to repeat the home-list updates
in both sides of the conditional, but this will be
more obvious in a subsequent commit, where we want
to capture return values from rendering.
In a recent commit we allowed for `scroll_amount`
to be zero (as an indirect consequence of letting
`scroll_limit` be zero without early exiting).
See 0f75be3e8e
We want to short circuit the call to
`system_initiated_animate_scroll`, partly to save
unnecessary computation, but in particular to avoid
invoking the suppress-pointer-update logic.
It's convenient to have visible_bottom as well
as top/height, and the extra computation is
trivial (it's just arithmetic, no extra jQuery
involved).
There's some minor cleanup here too.
This adds a proper template for the /digest page, making it a
reasonable way to view the digest email content for development and
debugging.
Fixes: #11016.
Guest users can not add subscribers to subscribed or unsubscribed
streams. Therefore hide add-subs html element if current user
is guest user.
Tweaked by tabbott to use the early-return pattern.
Add explanation in popover on disabled add-subscriptions input elements,
admin can't add subscribers to non subscribed private streams, only
subscribed users can.
Fixes#10593
There's a subtle change here in how we handle the
hypothetical case that the selected message is above
the top of the feed. Instead of early-exiting
from _maybe_autoscroll(), we just treat the limit
as zero, which will have the same effect.
We also change a var name be just `scroll_limit`
instead of `available_space_for_scroll`. A longer
name would be valuable if it were somehow more
specific, but it was needlessly verbose.
The idea is to use this field for storing the best matching alias
to be displayed in search results. In subsequent commits I will
replace the search and rendering logic to use this field instead
of creating new objects on each search.
Since we have already added the `invite_as` field to models, we can now
replace usage of `invite_as_admin` properly with its equivalent `invite_as
== PreregistrationUser.INVITE_AS['REALM_ADMIN']`.
Hence, also removed now redundant `invite_as`.
This couples the behavior of Enter to Save with Enter to Send.
Extracts and exports functions responsible for checking if enter
does send/edit and handling default behavior otherwise.
Changes made in static/js/message_edit.js and
static/js/composebox_typeahead.js
Fixes#10320.
This adds two functions to static/js/composebox_typeahead.js.
should_enter_send(event) checks if enter should actually send.
handle_enter(textarea,event) emulates browser's default behavior
if enter doesn't send.
These two are just straight extractions of portions of the compose box
logic.
It's a bit dangerous for the user to hit escape
to close the feedback widget, since it can
disappear suddenly, but users will try it, and
we should just close the widget.
(Hitting escape should be a noop if the box
is closed, but now it goes to "All Messages".)
We only need these once, not during every show()
call. We actually were only setting up the
click handlers one time, but we had redundant
mouse handlers.
More importantly, we stop a runaway timer
that tries to fade out our feedback widget
every 100ms or ten times per second!
A few things are still hard coded, but the class exposes
show() and dismiss() now.
The show() method is configured with callbacks for
populate() and on_undo().
We calculate a few values higher up in the function.
This reduces a bit of code duplication and removes
a somewhat janky expression that happens against
a mutated list.
I use shorter var names in frb_botom() and do early
return in obscured_recipient_bar().
Also, we always call exports.hide() if we don't find
a valid recipient bar to "float."
There is no reason not to initialize people.js
super early in the process, as it only reads
data from page_params. Also, other modules
are likely to want its data during their own
initialization steps.
This is the preferred way to check that a user
id belongs to the current user.
We have a recent bug where the current user's
circle doesn't turn green right away. It's not
clear this is the fix, though. (It's hard to
repro locally.)
This is mostly for testing purposes. The code
structure here is pretty stable--we will probably
always use level() here to either sort or
group users, and being able to test it directly
is nice, rather than bringing in all the other
machinery.
This makes it possible it include our standard markdown formatting in
one's custom profile fields, allowing for links, emphasis, emoji, etc.
Fixes#10131.
While we're at it, we remove the JSON parsing that was part of the
user field code path, since this function isn't responsible for
rendering user fields.
Apparently, our custom profile fields feature was parsing the "user
list" field type in multiple places, and ignoring the results in one
of them. That code had been causing some confusion; the correct
solution is to just delete it, since the template rendering process
ignores that value for this field type.
Our logic for doing pageup/pagedown calculation inside compose was
written too tightly, and ended up breaking the keys inside message
editing.
Fix this by using generic selectors that don't hardcode compose.
Previously, messages with more than one line did not parse '/me' at
the beginning of the message. Since there's a reasonable way to
render multi-line messages, this commit adds support for doing so.
This change does potentially break with the expected behavior of other
slash commands, but it seems worth providing useful functionality over
a blind focus on consistency.
Fixes#11025.
If branch for showing the profile details would
not have executed if the subdomain was root ("").
The check was changed to check for select input
instead of checking for subdomain.
This avoids a bunch of potential confusion around users trying to
interact with these UI in situations that don't make sense.
(E.g. showing a menu to start editing the message when the menu is
already open).
Fixes#3802.
We instead get the specific fields from message
that we use. This is particularly helpful
for subject -> topic migration; we no longer
have to account for "subject" fields in
client-side templates.
This continues the effort to isolate "subject" references
to util calls.
Also, we fix a comment.
Finally, we use canonicalized operators in a switch
statement.
This adjusts the spacing so that the out-of-view notifications for
group PMs (which have particularly long text) don't end up with the
"x" to close the notification overlapping the text.
Fixes#11058.
As part of giving the stream/topic fields in the
compose box longer ids, I broke the autocomplete
code that handles re-focusing the cursor after
a user hits enter. The worst symptom of this was
that we tried to send a message before compose
finished (although it wouldn't fully deliver the
message).
The new code should be a bit easier to grep for
if we rename these fields again, as we explicitly
use selector syntax.
Previously, we were searching the whole message_row object for emoji,
mentions, etc., which has a bunch of UI elements that can't contain
the syntax we want to modify. This should be a slight improvement in
the performance of message post-processing, which runs a lot of times
and thus is fairly important.
This check caused us to only run the code inside that block if the
message mentioned the current user (since that's when the `mention`
class is added to the main message row).
While this was a useful performance optimization, it probably was a
small one, not worth it for the correctness cost.
This adds a new realm_logo field, which is a horizontal-format logo to
be displayed in the top-left corner of the webapp, and any other
places where we might want a wide-format branding of the organization.
Tweaked significantly by tabbott to rebase, fix styling, etc.
Fixing the styling of this feature's loading indicator caused me to
notice the loading indicator for the realm_icon feature was also ugly,
so I fixed that too.
Fixes#7995.
Logic for checking if the last message in the current table is visible was
already written in message_viewport.js; Code in notifications.js is changed
to reduce redundancy.
We are trying to carve room for a more specific
"user_status" concept, which refers to statuses
that users specifically set, like "I'm away".
So we call this function "update_presence_info",
which reflects that it's more about actual
"presence"--i.e. the user really is present
in the browser, even though the actual human
may not want to be disturbed.
The current user gets excluded from all non-empty
searches, even ones that match the user, since
it can look funny when the user's at the top of a
search, and you'd never need to search for yourself
(again, since the current user is at the top of
the buddy list).
Apparently, we didn't have one of these, and thus had a moderate
number of generally very old violations in the codebase. Fix this and
clear the ones that exist..
We move all of its logic into settings_sections.
Note that this is slightly more than a refactor.
We are slightly more aggressive about resetting
sections. For example, if you go into Settings,
then exit the overlay, then go into Manage
Organization, we will now reset sections for both
groups.
We now rely on set_up() methods to call their
own module-specific versions of maybe_disable_widgets()
in the codepath for admin_sections.load_admin_section().
And then for live updates, we just explicitly call
all four modules that support maybe_disable_widgets().
This should make switching between sections slightly faster,
and it also reduces the risk of module A messing with
module B's state. (Granted, we have lots of other ways
that modules can mess with each other's state.)
Bootstrap's typeahead is the main part of the project that we've
forked, and moving it to its own module should help unlock our ability
to upgrade bootstrap itself.
This form isn't actively used, which is how it ended up broken, but it
basically didn't display its content properly at all.
Convert it to use our standard white-box framework.
This still doesn't look great in various ways, but it's at least not
obviously totally busted now.
Since we're adding this to a large number of portico pages, there's no
guarantee that these pages actually have a CSRF input.
Though given that the logout template contains a CSRF input,
realistically it should always be present.
We weren't using the actual sorted data to find
the last element. This probably worked by accident
in some cases, but this commit makes it more
deterministic.
We want the return value from this for the next
commit, so we no longer call `format_drafts` indirectly
from `populate_and_fill`, and we rename the latter
to `render_widgets`.
We had an anonymous callback for drafts that was
hard to read. It's much easier to flatten the code,
give functions actual names, and stub them as needed
in the unit tests.
Since we're adding this to a large number of portico pages, there's no
guarantee that these pages actually have a CSRF input.
Though given that the logout template contains a CSRF input,
realistically it should always be present.
If a user has an old mention and has since been renamed, there's
really nothing for us to do to render it; we should just return as
though we have no data.
Fix an issue that when a message is being edited, sometimes compose
options are hidden if there is no time limit. Also, move the options
further from the time limit to make them more noticeable.
Fix#11056.
The `replying_to_message` field was used in some
early versions of compose fade, but it has no more
use in the current code.
The drafts implementation didn't really make any sense,
anyway, as we were claiming to reply to the same
message we were drafting.
A common source of confusion for new users is sending a message when
you're scrolled up in the message feed; in this case, it's nice to
communicate to the user why the message is not in view.
Fixes#10792.
Restructured by tabbott to replace overly complex logic for getting
the position of the new message with a `message_list.get_row()` call.
Now, we correctly avoid calling various password quality/strength
functions in the registration flow in the event that there isn't a
password form on the current page.
Before, some code wasn't inside a block at all, while other code was
using an incorrect check (an empty jQuery object is not falsey).
The overall result was that this would often crash on certain
pages/flows, stopping JS execution and causing various secondary
problems.
The first bug fixed here has been around for a long
time--we were redundantly updating unread counts
indirectly via muting_ui.initialize(). The
unread counts also get updated in
unread_ui.initialize(), when we have more valid
state. (And it's worth noting here that the unread
counts get updated yet again once message fetches
complete.)
The second bug was a very recent regression from
my recent stream name -> stream id cleanup in the
muting system. We now depend on stream_data to
initialize muting data, so we need to initialize
muting.js slightly later in the process.
These fixes are intertwined, because they were both
somewhat caused by the anti-pattern of having
muting_ui.js initialize unread_ui.js and muting.js,
instead of doing more direct, fine-grained initialization
from ui_init.js.
Essentially we replace this code:
exports.update_muted_topics = function (muted_topics) {
muting.set_muted_topics(muted_topics);
unread_ui.update_unread_counts();
};
with this:
exports.initialize = function () {
exports.set_muted_topics(page_params.muted_topics);
};
And the modules load like this:
stream_data
...
muting
...
unread_ui
And we don't need any page-load initialization for muting_ui,
which is mostly used for Settings/Muted topics.
This function used to be called initialize_from_page_params(),
and we called it indirectly through `subs.js`.
Now we call it directly from `ui_init.js`, which gives us a
bit more control over how things are initialized. In fact,
this sets us up for the next commit, where I fix a recent
regression I introduced.
The data attribute here has some value if you're
inspecting the HTML in the browser, but it's not
worth the extra code.
All the list items have data-stream-id, so there's
no need for the parent to have it.
The stream_list test that was fixed here was sort of
broken. It accomplished the main goal of verifying
what gets rendered, but now the data setup part is
more like the actual app code (and simpler, too).
This fixes the most core data structures inside of
muting.js. We still use stream names for incoming
data to set_muted_topics and outgoing data from
get_muted_topics.
This will make us more resilient to stream name changes.
Before, if you were logged on when a stream rename
occured, topics that were muted under that stream would
appear to be unmuted. (You could fix it with a reload,
but it can be jarring to have a bunch of unread messages
appear in your feed suddenly.)
Fixes#11033
The fixture changes are because self.upgrade formerly used to cause a page load
of /billing, which in turn calls Customer.retrieve.
If we ran the full test suite with GENERATE_STRIPE_FIXTURES=True, we would
likely see several more Customer.retrieve.N.json's being deleted. But
keeping them there for now to keep the diff small.
Like the other similar commits, we were doing the same work in all
code paths, just with a much more error-prone approach.
We can also now remove the now-unused finish_initial_narrow function.
Like the other commits in this series, we were already doing this in
all of the callers of load_messages; this centralizes that logic in a
less ad-hoc feeling way.
We no longer use or need the start_initial_narrow function.
Previously, each individual caller of load_messages that passed
num_before > 0 would do its own manual management of fetch_status;
now, we just do it inside load_messages.
Apparently, the older side of the FetchStatus object for home_msg_list
was incorrectly not being maintained. We got away with this, because
the do_backfill code path (which runs after we're done with the
load_more cycle) will correct the error for found_oldest. But we
didn't have proper handling for history_limited here.
When we're doing the load_more frontfill, we were not correctly
declaring that we were in the process of doing a fetch. Because the
next load_more call clears this state anyway, this was generally a
short race, off-screen, but it is still a data flow bug.
See the upcoming commits for a refactor that will eliminate the
possibility of this sort of bug.
When a user's name is edited, currently we still show the old name is
mentions (though clicking on the item does the right thing).
However, at present, it creates a new problem in search results, where
the highlighting is removed by this substitution.
This styles the avatar and username that show when the registering
user is importing their settings from an existing Zulip account.
Tweaked by tabbott to fix the test/linter failures, a bit of styling,
and tag strings for translation.
A bug caused background links to open even when a modal in the user
settings overlay was active in the foreground. This commit fixes this
by disabling mouse events for the background when the modal is active,
and restoring them as soon as the modal starts closing.
Fixes#10654.
This adds a line to static/js/hotkey.js for focusing the "Close"
button. Tweaked by tabbott to make more clear that we don't expect
there to ever be both a close button and a save button, since in that
case this code would be busted.
Fixes: #3830.
The stream/topic edit areas now have these ids:
#stream_message_recipient_stream
#stream_message_recipient_topic
They are pretty verbose, but being able to grep
for these without noise does have some value.
Also, add a new notification sound, "ding". It comes from
https://freesound.org, where the original Zulip notification sound comes
from as well. In the future, new sounds can be added by adding audio
files to the `static/audio/notification_sounds` directory.
Tweaked significantly by tabbott:
* Avoided removing static/audio/zulip.ogg, because that file is
checked for by old versions of the desktop app.
* Added a views check for the sound being valid + tests.
* Added additional tests.
* Restructured the test_events test to be cleaner.
* Removed check_bool_or_string.
* Increased max length of notification_sound.
* Provide available_notification_sounds in events data set if global
notifications settings are requested.
Fixes#8051.
The Casper code that I eliminated here seems to be
bogus, in that I don't think it really waited for
all the clicks.
I **think** the intent of the test was to verify that
when you leave settings and go back into it, it remembers
the panel. I was able to verify this manually.
We have an upcoming change that lets us use the
back button after going arrowing through multiple
settings pages.
Without first adding this commit, we would have an
infinite loop when you came back to '#settings' and
then '#settings' would rewrite the url with the current
hash.
Just replacing the browser state allows the browser
to do the right thing.
The history protocol is pretty well supported:
https://caniuse.com/#search=history
We can eliminate the janky `setup_page` methods
and just pass in section from `hashchanged`.
This sets us up to handle browser history more
nicely when you load '#settings' and we could essentially
redirect you to '#settings/your-account' (or similar
things). A future commit will address that.
We also use `launch` as the new entry point, which
is more consistent with other modules.
The prior name of this was a bit inaccurate, as we no
longer ever hide the menu item for non-admins. Also,
it belongs more naturally in `gear_menu.js` at this point.
Also, we remove one call to this, which was in a place
where it was no longer necessary.
We now run the code to disable widgets every time
we reload a section, which was the original intention
of the code, but the call to it only happened when
you first launched the page.
We also continue to run this logic for live updates
of is_admin, although it's worth noting that the
code still only handles the "demotion" case of going
from admin to non-admin. (If somebody makes you an
admin, you continue to need to reload to get
widgets enabled.)
This ensures the "account settings" UI for managing a user's own email
address uses the delivery email, since that's what users care most about.
Eventually, we'll need to add support for at least viewing both email
addresses in "account settings", but this is the right long-term
behavior.
This new setting is still hidden in the UI when not in the development
environment, because the feature isn't ready for production, but
merging this will help simplify future work on the feature.
When the list of recipients of a group private message conversation is
truncated due to being long in the "Private messages" area, we didn't
provide easy access to the full list of people. Fix this by adding a
title attribute for the area.
Fixes#10978.
This correctly shows guest users that they cannot interact with
anything in the "Organization" tab, though we preserve the read-only
access to it so that they can (e.g.) browse the organization's custom
emoji.
Previously, Topic editing was offered in the UI even to message
senders and organizations admins only if the message was no more than
one day old. This was correct for the "community topic editing" case,
but not for message senders and organization admins.
While we're at it, this also centralizes some previously haphazard
logic to always call message_edit.is_topic_editable().
Tweaked significantly by tabbott to fix the logic.
Closes#10568.
okmanl
Alexandra Ciobica
Tim Abbott
varunvaruns9
Steve Howell
vinitS101
overide
Boris Yankov
Rishi Gupta
Mohit Gupta
Wyatt Hoodes
synicalsyntax
Rohitt Vashishtha
Vaibhav
Anders Kaseorg
Hemanth V. Alluri
alex
sahil839
Challa Venkata Raghava Reddy
Vishnu Ks
Harshit Bansal
Pragati Agrawal
YashRE42
Puneeth Chaganti
Natsu Kagami
Amadeo234
Abhinav Singh
butchyyyy
Shubham Dhama
kunal-mohta
ss62171
Adarsh Patel
TharunThomas8
ishanrai05
Yashashvi Dave
Jeswin
Aditya Bansal
Shoumorup
Marco Burstein
Akash Nimare
AsociTon
Cynthia Lin
Archit Kaushik
Eeshan Garg
seresheim
Joshua Pan
Max Nussenbaum
Aditya Jain
Marco Burstein
onkar shedge