This is general fix that makes sure that we
apply all message-modifying events after we
apply the events for the initial incoming
messages.
The particular scenario that was reported here
was when you would have two tabs for Zulip,
with one of them open and in a PM view, and
with the open tab being at the bottom of the
feed, such that incoming messages would be
immediately visible.
Now suppose the other person in that PM
conversation sent you a message.
The open tab would properly immediately
mark the message as read, and notify
the server. The problem was that the closed
tab would not process the main message event
until it "woke up", by which time the flag-update
event was bundled into the same event batch
as the main message event. We'd then process
the flag-update first, which essentially was
a noop, since the actual message wasn't in
the message store yet. The user would then
see unread counts increment in the closed tab,
while the open tab didn't increment. This
was confusing.
Now `server_events.js` processes the actual
message first and does the flag-update as part of a
`post_message_events` loop.
We include events for updating message flags,
deleting messages, and attaching submessages
to messages in the `post_message_events` array.
This bug was a bit difficult to simulate in a dev
environment, since you needed your "open" tab
to be in focus to simulate the race, but as
soon as you tab to another place to deliver
a message (whether from the browser or otherwise),
the open tab is no longer in focus.
I did this in the console of my "open"
tab to work around it:
unread_ops.process_visible = unread_ops.mark_current_list_as_read;
This problem was easy to reproduce, but it wasn't
entirely consistent. I often needed to send
several messages in succession to trigger event
batching and force the race condition. (This wasn't
precisely a "race", as events actually arrive in the
correct order; it was having them arrive in the same
batch that triggered the bug.)
This commit fixes multiple invite-user-email sent to user.
In invite-user-form, submit-form click handler is getting
called multiple times on submit-invite-user-form event, which
results in multiple invitation mail to user.
Because, we registered same submit click handler multiple times.
Submit form click handler is registered when user opens invite-user
modal. If user opens modal multiple times, click handler get
registered multiple times.
We should register this click handler on `exports.initialize`
function instead of `exports.launch` function. This modal is unlike
other modal, where we append html when user opens modal. In this
case, we append modal on initialization. We only show modal when
user opens. So on initialization, modal element already exists,
register click handler on submit-btn element, on intialization
not when user open modal.
Fixes#10354.
If a caller passes undefined to go_to, it is
almost certainly a programming error, so we
shouldn't silently ignore it just because
the current key is undefined.
We also avoid setting curr_key until we
validate the incoming key.
When non-admin users visit the custom profile fields settings page,
the `Sortable` error
Uncaught Sortable: `el` must be HTMLElement, and not
[object Undefined]
is thrown, with `undefined: undefined | No stacktrace available` being
shown in the browser. Fix this by only using `Sortable` if the user is
an admin.
Fix#10403.
In commit c293bb82c4 we changed
id_realm_invite_by_admins_only and realm_invite_required checkboxes to a
single dropdown so these lines are redundant now.
In user type custom field, field value is list of user ids. We weren't
converting list to json object in update event payload. This throws
error in frontend, cause we store stringify representation of custom
field value. Therefore, after update event is recieved field-value-
type gets updated to array from string which throws json parsing error.
Expect div-input element in every pill-container even though pills are
not editable. This is correct, because `input_pill.js` appends pills
before the div-input element.
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.
If `TEXT_EMOJISET` is currently selected emojiset then fallback to
`GOOGLE_EMOJISET` for displaying emojis in emoji picker and
composebox typeahead. We should pre-load the spritesheets in`emoji.js`
even in case of text emojiset otherwise on slow networks emoji picker
will appear empty initially.
This commit add checks in frontend to remove null values of choices
from json data. This allows user to successfully create/edit choice
custom field, even if there is blank input in choices.
This commit
- Remove `add-btn` in choices, to create new input
for choice
- Add logic which create blank input for choice at
the bottom if user start typing into above input choice.
This commit add following logic in delete-btn of choices, so
user can not delete all choices of custom field.
Show `delete-btn` in all choices, but if there exist only
choice hide `delete-btn` of that choice.
Hide `delete-btn` of first choice in create-new-custom-field and
edit-choice-type-field form, so user can not delete all choices
and have to submit at least one choice.
This commit remove this logic of choice-field-delete-btn from
both settings.
This is preparatory commit of adding new logic in `delete-btn`.
Fixes#10124.
Users in the waiting period category cannot subscribe other users to
a stream. When a user tries to mention another unsubscribed user, a
warning message appears with a subscribe button on it to subscribe
the other user.
This commit removes the subscribe button and changes the warning text
for users in the waiting period category.
Instead of displaying a fixed error message inside the yellow bar itself,
now the yellow bar disappears on error and a red compose_error is shown.
The error message is the one returned from the server.
When the icon or the text of a menu item in settings dropdown was
clicked, already open compose box was closed. Clicking on the empty
area of that menu item i.e the area where the icon or text was not
present did not close compose box. This commits check whether the
target itself is an anchor tag or of any of its parent contains the
anchor tag.
If a user is narrowed by `is:private`, `pm-with`, or `group-pm-with`,
change the `New topic` button to say `New stream message` instead for
added clarity.
Also, add to the Casper and Node tests for this behavior.
Fix#9072.
