Add do_not_blur func to not save changes when blur event's origin
is one of name/description/pill input from the current user group.
Changes in any of name/desc/members are saved together on blur from
any of the input field given do_not_blur is false.
This restructures the organization-settings-admin template into
different subsections. With this, we can easily limit the scope of
event handlers and selectors within their subsection to which
are applied.
There will be no change in UI because of this.
To populate data for requests limited to only selected input elements,
we have to extend `populate_data_for_request` for objects other
than `property_types`, e.g. now we can collect data only for user identity
by passing org_permissions.user_identity as changing_property_types.
This splits property types according to sections in
"Organization settings" viz. Organization settings, Organization
permissions, and Organization profile. Where org. settings and
org. permissions are further categorized according to the
subsections.
These changes are made to save changes for each subsection independently.
This extends `do_settings_change` function for parameters like
`success` and `error` functions which will replace the default ones,
for functions that need to be excuted in success callbacks and for
desired success message.
All these parameters are optional.
Many declarations were previously annotated with
Callable[..., HttpResponse]; this is equivalent to ViewFuncT, so here we
switch to it.
To enable this migration, the WrappedViewFuncT alias is removed; this is
equivalent to the simple & legible Callable[[ViewFuncT], ViewFuncT], so
for relatively no space change, a clearer return type is possible.
Originally was going to centralize this in zerver/lib/request.pyi, but this
file is not visible at run-time, being only a stub. The matching request.py
file seemed inappropriate, as it doesn't actually use ViewFuncT.
This prevents accidental multiple click requests due to which we get
some errors like "This field cannot be blank" (though we have successfully
added the desired filter).
Fixes: #8699.
Namely, annotate as best as possible, and add notes to indicate preference,
if QuerySet develops generic typing.
Note that the return values of functions with annotations changed in this
commit are used elsewhere as QuerySets, so the Sequence[T] approach used
for some functions in models.py is not applicable.
Other functions took the form of returning Sequence[T] when the QuerySet
functionality is unused beyond the function, with T being the objects
filtered for in the function body; this commit follows that practice for the
one remaining python2 comment-annotated function, completing the transition
of models.py to py3.5 function annotations.
A note is also added to another function regarding a need to return a
QuerySet, and ideally a QuerySet[T] in line with the other functions, as and
when QuerySet becomes annotated as a generic.
We now consistently set our query limits so that we get at
least `num_after` rows such that id > anchor. (Obviously, the
caveat is that if there aren't enough rows that fulfill the
query, we'll return the full set of rows, but that may be less
than `num_after`.) Likewise for `num_before`.
Before this change, we would sometimes return one too few rows
for narrow queries.
Now, we're still a bit broken, but in a more consistent way. If
we have a query that does not match the anchor row (which could
be true even for a non-narrow query), but which does match lots
of rows after the anchor, we'll return `num_after + 1` rows
on the right hand side, whether or not the query has narrow
parameters.
The off-by-one semantics here have probably been moot all along,
since our windows are approximate to begin with. If we set
num_after to 100, its just a rough performance optimization to
begin with, so it doesn't matter whether we return 99 or 101 rows,
as long as we set the anchor correctly on the subsequent query.
We will make the results more rigorous in a follow up commit.
We do not update user_group_name_dict when name or description is edited,
which may lead to errors if get_user_group_from_name is called, so to fix
that we update user_group_name_dict also.
Note that the "Save" button has no text in the Taiga webhook
setup UI. There is a small floppy disk symbol for saving which
is visible right beside the form fields. So I simply said,
"Save the form".
We start to force downloads for the attachment files. We do this
for all files except images or pdf's. We would like images or pdf's
to open up in browser itself.
Tweaked by tabbott for comment clarity and correctness.
This makes it convenient to mention a stream you're not subscribed to,
which can be useful for communicating about where a topic is
discussed, for example.
Fixes: #5757.
This commit switches our emoji infrastructure to use 256 color indexed
64px spritesheets. Earlier we were using non-indexed 32px spritesheets
which were blurry on high dpi displays. These indexed spritesheets not
only provide a crispier display but are also smaller in size.
This commit also removes the `emoji-datasource` package as a dependency
as all the data is now sourced from individual datasource packages.
Fixes: #7862.
The edited group iswas going to the bottom, it is not staying at its
position, so to fix this we sort by ids of the groups to maintain
proper relative order.
(Original commit also fixed another issue, but Tim replaced that with
the previous commit for a better solution).
Fixes#8692.
This fixes the user groups UI to follow the Zulip standard mechanisms
(using the appropriate server_events system to update all browsers
properly). It also, as a side effect, fixes#8692, since it
eliminates the weird behavior of trying to re-insert a user group
after reformatting it in the frontend.
Thanks to Tarun Kumar for preliminary work on this.
Even if realm admin can access unsubscribed private stream subscribers,
admin can't add subscriber to stream. Hide the option to add subs to
stream in UI.
I noticed that our nice feature to show JavaScript errors collected by
blueslip in view of users was hidden in the background if you had one
of our settings screens open.
Further investigation determined the same was true for our other
panels.js alerts (e.g. the one for get_events failing, etc.). This is
easily fixed by just raising the z-index of the alerts panels; I
tested and a variety of our possible alerts look good on top of stream
settings, so no need to do anything special here.
Fixes#8576.