Applies the logic to allow community members to edit topics
of others' messages if this setting is True. Otherwise,
only administrators can update the topic of others' messages.
This logic includes a 24-hour time limit for community topic editing.
This commit asserts that parse_user_agent never returns None. The
RegEx will match any string, so that `match` is never None. This
brings test coverage of lib/user_agent.py to 100%. Changes were also
made in test/test_decorators.py and views/compatibility.py to reflect
that parse_user_agent cannot return None.
Improves: #7089.
Fixes: #8779.
In this refactor property values are handled more carefully i.e.
we first check whether property_name refers to a property values
which we can't get from the input elements like we do have in org
permissions section for properties like realm_add_emoji_by_admins_only.
Small refactor in property_value_element_refers is to prevent many
return statements on further addition of property names.
This changes failed status element to use class
`.admin-realm-failed-change-status` rather than id so that we can use
the same code in `save_organization_settings()` in future to refer to
failed-status element of that section.
To keep click handler for "save" button clean, we extracted the
the `if` statements where we complete request data for certain fields
which aren't mentioned in `property_types`.
We restructured template to make org-permissions-template have more
separated subsections and so that we can easily apply event handlers
and selectors to their corresponding subsections (there will
be no change in UI).
(This is similar to 8b54b08)
This is nicer than the "For manual testing ..." comment. :-)
Also as a proper setting we can have it control some logging I
added locally while testing my recent changes to pika logging.
Details in comment. Together with a few previous commits, this should
completely eliminate sending error mail to admins when the RabbitMQ
server is simply restarted and comes back up normally.
There were two instances of `ensure_stream` being called and assigned to
a variable with the variable not being used elsewhere. pyflakes picked
up on this (where it didn't in the previous version likely due to tuple
unpacking), so the the variable assignment has been replaced with a call
to `ensure_stream`.
Issue #2088 asked for a wrapper to be created for
`create_stream_if_needed` (called `ensure_stream`) for the 25 times that
`create_stream_if_needed` is called and ignores whether the stream was
created. This commit replaces relevant occurences of
`create_stream_if_needed` with `ensure_stream`, including imports.
The changes weren't significant enough to add any tests or do any
additional manual testing.
The refactoring intended to make the API easier to use in most cases.
The majority of uses of `create_stream_if_needed` ignored the second
parameter.
Fixes: #2088.
To ensure that we have some basic data for custom profile settings,
in the `populate_db` data set, remove `options['test_suite']` check
for adding intial custom profile data.
This change mostly de-duplicates code, but it also prevents
some unnecessary backfills if you're in the home view and
happen to scroll back while the idle loop is right in the middle
of a backfill fetch, or if the idle loop has taken you back
to the oldest message already. This is a consequence of
do_backfill() calling msg_list.fetch_status functions.
Everything else should work pretty much the same, since
do_backfill() computes anchor essentially the same way we
originally doing it in the onIdle() function.
This slightly changes the order of operations of what we do in
the `cont` callback, so that we update fetch status earlier.
The order is somewhat arbitrary here, but we generally want to
update data structures first.
The "all" list and "home" list are basically kept in sync, and
the former is a superset of the latter.
Whenever we are backfilling, we want to backfill "all", so we use
it as the anchor, even though home_msg_list is the message list
we are actually rendering.
It's possible that this won't work with some versions of the
third-party backend, but tabbott has tested carefully that it does
work correctly with the Apache basic auth backend in our test
environment.
In this commit we start to support redirects to urls supplied as a
'next' param for the following two backends:
* GoogleOAuth2 based backend.
* GitHubAuthBackend.