Modify structure of template data used to render
`user_profile_modal.handlebars`.
This is preparatory commit to display user pills in user profile
popover instead of user names in user type custom fields.
This commit add FIELD_TYPE_CHOICES_DICT to page_params and replace
FIELD_TYPE_CHOICES.
FIELD_TYPE_CHOICES_DICT includes all field types with keyword, id
and display name. Using this field-type-dict, we can access field
type information by it's keyword, and remove all static use of
field-type'a name or id in frontend.
This commit also modifies functions in js where this page_params
field-types is used.
Choice type of custom field, displays index of selected choice by user
instead of value of choice.
Fix this by parsing choice-type custom field to get field value before
rendering user popover template.
Fixes#10239
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
actions_menu_handle_keyboard now only gets the action menu items
and passes them to the newly added popover_items_handle_keyboard.
popover_items_handle_keyboard takes the key and menu items as its
parameters. The function can be used when handling keyboard input
like user profile popover. Similar refactor has been carried out in
focus_first_action_popover_item. This refactor is a part of adding
the missing support of keyboard navigation to user profile popover.
In user profile popover, date type of custom fields values are
not showing in correct format as "date_joined" value.
Fix this using moment.js to render date type of fields
in correct format.
This is preparation for enabling an eslint indentation configuration.
90% of these changes are just fixes for indentation errors that have
snuck into the codebase over the years; the others are more
significant reformatting to make eslint happy (that are not otherwise
actually improvements).
The one area that we do not attempt to work on here is the
"switch/case" indentation.
Add realm setting to set time limit for message deleitng.
Set default value of message_content_delete_limit_seconds
to 600 seconds(10 min).
Thanks to Shubham Dhama for rebasing and reworking this. Some final
edits also done by Tim Abbott.
Fixes#7344.
We consistently either pass a `then_select_id` into narrow.activate,
or were using the select_first_unread option. Now, we just compute
select_first_unread based on the value of then_select_id.
We fallback to using data-user-email attrib for mention messages
from the times when we use to expose user emails to frontend.
This is only required for cases where we are dealing with anything
that isn't rendered dynamically (like the messages that were already
sent and stored long time ago). Hopefully we won't be needing this
kind of fallback logic in more places so I am putting off efforts
to try to extract fallback logic for common use. Also this is like
this because it will probably be tricky to extract out a common
fallback logic in this case because of different situations involved.
Fixes: #8588.
compose_action.respond_to_message and compose_action.start starts new
compose box so we should check whether we are already composing
or not. So, behavior, when we are composing, is that the user we want
to mention is added to the same compose-text without the changing stream
and topic name.
Use compose_ui.insert_syntax_and_focus() when we need to insert text
inline-ly followed by the focus to compose textarea because it does
this job more smartly(it take cares of spaces).
No need to have separate click handler for user_popovers and
message_info_popovers as the same user-id can be extracted similarly
from the target of both the click events.
Another refactor, `sender_info_popover` was confusing as it doesn't
fix into the context of rightbar user popovers so changed it to
`info_popover_actions` since that section of popovers contains popover
actions.
Hotkey reminders in user popovers( i.e. `@` and `R`) should be present
only for sender info popovers, hence for user-mention and user-presence
popovers it will show no such reminders.
Fixes: #8313.
This removes some options when a user clicks on their own profile, and
replaces them with an option to edit their own profile settings.
Front end test adjusted because it was testing an option that does not
appear if a user clicks on their own profile.
Fixes#5075.
This adds a click handler to `.user-group-mention` which works in a
fashion that is quite similar to `.user-mention`. It generates and
displays a popover.
The popover has a list of members, their online status (if they are
not bots) or their bot status if they are bots (it's not clear whether
ultimately bots should be able to be members of usergroups, but I'm
able to add one, so I thought it would be worth supporting).
The popover's `UL` element has max-height and overflow-y atttributes
so large groups will grow a scrollbar.
Fixes#8300.
This change resets the list_of_popovers array to a new empty array after
hide_all has been called. Prior behavior kept it around, and it kept
pointers to orphaned DOM nodes.
Fixes#8416.
Wait until the server acks a message before we enable
the message popover menu. This prevents a whole class
of bugs related to re-drawing the message and changing
the message id, and it also makes room for a little
spinner in the future.
Users with decent internet connections will generally
get server responses before they can click on the
chevron or hit esc/i, anyway.
Trying to collapse a locally echoed message is a rare
thing to do, and it was buggy before this due to races
between the server acking the original message and the
user flipping the collapsed flag.
We now calculate `should_display_collapse` and
`should_display_uncollapse` in the JS code and simplify
the template by eliminating all the inline if/else
logic.
(Note that we are about to disable the message menu
altogether for locally echoed messages, so this change
is partly future-proofing for when we put the menu
back for more innocuous commands.)
This applies the same overflow changes to “.message-info-popover” by
imposing a max width on the popover (so it doesn’t increase in width
when it gets larger) and adding the tooltip on hover.
We were incorrectly reporting active bots as non-active in
popovers, and we had no test coverage for cross-realm bots.
We also rename the function to is_active_user_for_popover,
since the old name, realm_user_is_active_human_or_bot, suggested
the wrong semantics for cross-realm bots.
Last but not least, we only do a blueslip warning if a user id
is not found. When lookups fail, we are pretty confident that
the user is not active, so an error is overkill. We can change
that as part of issue #7120.
Fixes#7153
Apparently this is a bug that slipped in when we started showing
normal users as deactivated in the user popovers: all bot users were
treated that way as well.
We'll want to do #7153 as a follow-up to get things fully working how
we want them.
We are about to stop supporting the presence status of "unknown."
Part of this fix is to stop checking for that status.
The implication of this change is that when we go
to display the time a user was last online, we now
mostly just look to see if presence.last_active_date
is undefined. We were wary of that approach before, but it
is probably the most sane approach here.
I updated the comment abover this section to reflect
our philosophy going forward.
BTW the timestamp is kind of buried in the UI for now, as you have to
open the popover and then hover over the circular presence
indicator.
In the refactoring in 31d3b1ecc0 that
fixed live-updating of the medium-size avatar data, we started just
fetching the normal-size avatar, not the medium-size avatar. We fix
this by changing this code path to pass in the user object and
construct the URL using that.
While we're at it, we switch to using the user ID, not the email, to
construct these avatar URLs.
Previously, we relied on fetching the name of the user from the data
attributes on the individual elements, when we can get a more reliably
up-to-date value from the people.js data structure we're fetching
anyway.
This commit extends the `compute_placement()` function in
`popovers.js` to take into account height/width of popover as well as
positioning preference. If vertical positioning is desired and the
popover fits in either 'top/bottom' positions then we don't check for
`left/right' positions. Earlier the behavior was to prefer
'left/right'positions over 'top/bottom' positions, which resulted in
the emoji picker popping incorrectly to the left.
For whatever reason, the clipboard doesn’t want to work if you use a
jQuery click trigger. Perhaps because the jQuery event trigger doesn’t
create a native event at all. By doing this however, it doesn’t appear
to affect any other code but does allow for the clipboard to work again.
Fixes: #6002.
compute_placement utilizes the dimensions of the viewport, viewport location of
an element, and dimensions of an element to determine if a popover will fit
horizontally and/or veritically given its orientation. The default placement
is now viewport_center, which displays the popover, without an arrow, in the
fixed center of the viewport.
This should be particularly useful for hotspots on mobile or large popovers
that contain a lot of content. The property hotspot.location.popover can be
optionally set to fix the orientation of a popover (most likely to
VIEWPORT_CENTER).
This removes the `no-new` rule which is relatively detrimental to
code cleanliness in our codebase because third-party libraries may
utilize data structures that don't fly well with our linting rules.
This also fixes abstractions that were created due to the limitations
and impositions of this lint rule.
This new setting controls whether or not users are allowed to see the
edit history in a Zulip organization. It controls access through 2
key mechanisms:
* For long-ago edited messages, get_messages removes the edit history
content from messages it sends to clients.
* For newly edited messages, clients are responsible for checking the
setting and not saving the edit history data. Since the webapp was
the only client displaying it before this change, this just required
some changes in message_events.js.
Significantly modified by tabbott to fix some logic bugs and add a
test.
For bots and users who have not logged in for a long time the presence information is not known. For the these users make the presence indicator hidden.
This makes it possible for Zulip administrators to delete messages.
This is primarily intended for use in deleting early test messages,
but it can solve other problems as well.
Later we'll want to play with the permissions model for this, but for
now, the goal is just to integrate the feature.
Note that it saves the deleted messages for some time using the same
approach as Zulip's message retention policy feature.
Fixes#135.
Yashashvi Dave
Joshua Pan
Steve Howell
Armaan Ahluwalia
Shubham Padia
Shubham Dhama
Aditya Bansal
Vishnu Ks
Tim Abbott
Priyank
Marco Burstein
Priyank Patel
ryan
Eric Eslinger
Balaji2198
Brock Whittaker
Tommy Ip
Rohitt Vashishtha
Cynthia Lin
Garvit
derAnfaenger
Rhea Parekh
Harshit Bansal
Jack Zhang
Vishnu Ks
Durga Akhil Mundroy
Cory Lynch
K.Kanakhin
Steve Howell