We will use this later to display which user group was mentioned
in push and email notifications.
`mentioned_user_group_ids` is kept as a List (not Set) to ensure proper
test coverage of the function, since it depends on the order of iteration,
and we cannot change the order of iteration for a set (which we'll need
to do for proper testing).
Part of #13080.
Commit 81d7dd1fda broke this nearly
eight years ago, so probably nobody cares except the ever-watchful eye
of mypy.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Mypy can’t follow absolute imports based on directories other than the
root. This was hiding some type errors due to ignore_missing_imports.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The absence of __init__.py was preventing mypy from following any of
the zerver.openapi imports. These errors were being silenced by
ignore_missing_imports.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit adds a new trigger for compose.start that is
"new private message". It will clear the message recipients
whenever compose.start is called with this trigger.
This solves the bug, when a person is in a PM narrow and
clicks the new private message button, it opens the
composebox with the recipients filled out with whoever
you're narrowed to, rather than opening a new, blank PM.
CZO link for the issue
https://chat.zulip.org/#narrow/stream/9-issues/topic/.22New.20private.20message.22.20isn't/near/1222712
This shortcut now renarrows to an empty topic, rather than to the
stream, as long as the topic input is nonempty.
This was debated in the original implementation of this feature:
https://github.com/zulip/zulip/pull/9511#discussion_r190323319
Having seen the experience in practice, the current behavior is
surprising and we should migrate to the other option originally
considered. In particular, the argument that "narrowing to the stream
would still tell you the topic is empty" turns out to be inaccurate,
since the history within the stream may not be in the most recent
messages in the stream.
Fixes#19122.
I also remove a conditional here that's not necessary. For
anything that's obviously a template in static/templates,
we now create a stub implementation that behaves according
to whether we're stubbed or being included as a partial.
d779a1c tweaked `get_full_datetime` to return a string instead
of a {date, time} object. This function is used for recent topics
too but wasn't fixed to use the string.
This resulted in showing 'undefined undefined' in tooltip.
Add two questions to the billing FAQ:
- What is the difference between automatic and manual billing?
- How will I be charged for temporary users (e.g. limited-time
clients)?
An organization with at most 5 users that is behind on payments isn't
worth spending time on investigating the situation.
For larger organizations, we likely want somewhat different logic that
at least does not void invoices.
stripe.Invoice.list by default would only get 10 invoices at a
time. So a function like this would be really handy if we have
to go through a lot of invoices.
This also means void_all_open_invoices used to void only the last
10 invoices. The main reason we implemented this function was to
void the invoices generated by realms on free trial so I don't
think there were cases where we had to void realms with more than
10 invoices.
This also fixes a bug in void_all_open_invoices function. If a realm
with a local Customer object but without an associated stripe.Customer
is passed to void_all_open_invoices, then the function will end up
voiding the last 10 invoices created by billing system instead of voiding
no invoices at all. This is because stripe.Invoice.list(customer=None)
return last 10 invoices across all customers.
But this bug won't cauuse any issue in production since
void_all_open_invoices can be only invoked from /support page. And we
show the option to void invoices in support page only if the realm
has a paid plan. And it's not really possible for a realm to have
a paid plan without having an associated stripe_customer_id. Plus I
went through the void events in stripe stream since the PR to add
void invoices was merged and there does not seems to be any suspicious
events.
Previously, we showed a `Copied!` alert on copying link to a message
irrespective of the fact that the link was copied or not.
Hence add an event listener that shows the `Copied!` tooltip only
if the action was successful.
Fixes#19019.
Previously, we showed a `Copied!` alert on copying a message
irrespective of the fact that the message was copied or not.
Hence add an event listener that shows the `Copied!` tooltip only
if the action was successful.
Fixes#19019.
get_public_upload_root_url and construct_public_upload_url_base were
both doing basically the same thing in the same. We deduplicate this,
making them share the same code, using the approach from
get_public_upload_root_url of using urljoin.
Using a format string is not a great idea, as it doesn't handle the case
of the URL already having parts that will be interpreted as format
string metacharacters. On the downside, this approach negatively affects
performance:
```
...: s = time.time()
...: for i in range(0, 250):
...: r = u.get_public_upload_url("foo")
...: print(time.time()-s)
0.020366191864013672
```
up from 0.001 before this change.
If highlight_toggle is called before activate_section_or_default,
then 3 hash change event take place for single hash change.
For example if hash is changed from "#settings/profile" in the
browser to "#organization/organization-permissions", then the
cycle is-
"#settings/profile" -> "#organization/organization-profile" ->
"#organization/organization-permissions".
This is because "highlight_toggle" also leads to call of
"activate_section_or_default" with section as default section
(i.e. organization-profile) then the correct section is opened
again as activate_section_or_default is called in hashchange.js
after highlight_toggle.
The middle hash of the above example depends on the last open
section in organization area or is the default section which is
"organization-profile" when overlay is opened first time after
reload.
This is also consistent with the code for opening overlay from
gear menu where "highlight_toggle" is called later.
Reproducer:
* Open the settings overlay from gear menu, the profile (user profile
not organization profile) is opened.
* Note the current hash in browser is "#settings/profile".
* Now directly change the hash to be "#organization/organization-permissions".
You will notice that the content is fine, but there is problem in left
sidebar and the hash. The left sidebar content is still of user
settings and not organization settings and the hash in the browser is
"#settings/organization-permissions".
Now the bug was due to normal_settings.activate_section_or_default
call instead of org_settings.activate_section_or_default.
Calling from normal_settings leads to hash_prefix being "#settings"
which changes the hash in the browser and also toggles the left
sidebar to display settings part instead of organization. The right
section content is of organization-permissions only because it
depends only on section and not prefix.
So, this commit adds a if-else condition deciding what to call based
on the hash.
The issue was text label has `display: inline-block`
property which caused it to go to a new line in smaller
width screens.
This commit fixes it by changing its display property to `inline`.
Fixes#19075.
This is consistent with how we handle JsonableError and friends; it
doesn't make sense for translators to spend time on strings only
visible in a development environment.
Previously, there were cases where the table contents started to
overlap with the table heading when scrolled down the table.
This was mostly visible in `Custom Emoji` organization UI,
where the images and action table column contents started to
overlap with the table headers.
Rectified the bug by adding a CSS `z-index` property to
`table-sticky-headers` class which takes care of all
such overlapping issues.
Fixes#18906.
As we have changed the tab selector above from "Settings" to "Personal
settings", we can simply change "Your bots" to "Bots" as "Bots" is
clear enough given the personal settings context.
We also need to update the API documentation for bots accordingly.
Previously the header of settings overlay
was 'SETTINGS / {name_of_section}'.
This commit changes it to be one of the two
mentioned below according to the opened
section-
1. 'PERSONAL SETTINGS / {name_of_section}'
2. 'ORGANIZATION SETTINGS / {name_of_section}'
Note - Have kept the header as original in
case of mobile as the above text will be
too long.
Abhijeet Prasad Bodas
Anders Kaseorg
Priyam Seth
PIG208
Tim Abbott
Gaurav Pandey
Steve Howell
Wesley Aptekar-Cassels
Dinesh
Alya Abbott
m-e-l-u-h-a-n
Vishnu KS
Priyank Patel
Priyansh Garg
Mateusz Mandera
sahil839
Riken Shah
akshatdalton
aryanshridhar