Since this is based off of the id now and doesn't try
to get a stream from a name (because stream is now
selected by a dropdown and not a free-form input field),
we can also remove the error handling for when the
stream name doesn't correspond to any streams.
Adds a test for when a value for a user's custom profile field is
removed and not set to a new value. The omission of this event in
the tests was noted as a possibility in #22103, which updated the
API documentation for these events having `null` for the field
value.
When adding the test discovered that the events logic was not
deleting the field from the user object and instead setting it to
`None`, so fixes that logic as well. There was a similar bug fixed
in commit 96c61a1a41 for when custom profile fields are removed
from a realm.
When applying realm_user update events, some of the event fields
for the person object were being updated to the same value in a
loop. Unnests those calls from the loop over the existing fields
so that they are only updated once.
The original nesting was introduced in commit 649fccde6b and
was expanded in other additions to the logic for these events.
- Adds a link to the "Recent conversations" article whenever we use the
term "conversation" as a technical term referring to topic or
DM thread. This can help clarify meaning when the term is used in this
specific way.
This commit explicitly sets the following user settings:
* 'enable_followed_topic_email_notifications'
* 'enable_followed_topic_push_notifications'
to True.
Collectively, this improves the readability of the test and
the following two tests.
Recent Topics is hidden when we switch to a narrow view
or the All Messages view, so this call is not needed.
It will also become actively unhelpful when we build
a stream-specific recent topics page, because then it
will be possible to have a hash change that shouldn't
close the recent topics view.
In 'test_copy_default_settings_from_another_user', we verify that
'cordelia' and 'iago' have the same values for their user settings,
but 'hamlet' has the defaults.
Earlier, we explicitly set the 'color_scheme' setting for 'hamlet' as
'UserProfile.COLOR_SCHEME_NIGHT', which is not needed.
As we verify, 'hamlet' should have the defaults.
So just verifying if the 'color_scheme' setting for 'hamlet' is
'UserProfile.COLOR_SCHEME_AUTOMATIC' (default) fulfils our purpose.
The extra line of code was introduced in b10f156.
We change the custom profile fields table to have same header as
of other table and as a result this also makes the page look
better if an organization has zero custom profile fields.
This commit re-adds bootstrap CSS rules defined using "table"
class to the specific CSS files where CSS for different tables
is present.
This is a prep commit for removing table related bootstrap CSS
from bootstrap.css.
We have already re-added the bootstrap CSS rules defined using
"table-bordered" class in the specific files where required and
thus this commit removes them from bootstrap.css.
Previously, two borders were applied on the heading of tables
in informational_overlay. Top of the heading element had one
border from "table" and one from "th" element. Bottom of the
heading had one border from "th" element and one from "td"
element.
This commit fixes it by changing the CSS for borders on
"th" element to be applied only on striped tables without
borders (i.e. tables having "table-striped" class but not
"table-bordered" class) as bordered tables already have
top borders defined on td and table element while on
striped tables without borders, only bottom border is
applied on "td" elements along with the top and bottom
borders on "th".
This commit re-adds bootstrap CSS rules with "table-bordered" class
to app_components.css so that tables used in the app can use this
css and we can remove the CSS from bootstrap.css.
This commit re-adds required bootstrap CSS rules defined with
"table-bordered" class to the specific files.
This is a prep commit to remove bootstrap CSS for tables.
We do not use classes like "success", "warning", "info"
and "error" for "tr" elements used in tables and thus
we can remove the related CSS from bootstrap.css.
We also do not have selectors of the form ".table .table"
and so we can remove that CSS from bootstrap.css as well.
ALso, the CSS defined using ".table tbody + tbody" to
set the border is not required as we already set borders
on th and td elements.
The browser defaults for font-weight for `th` elements
is "bold" so we can remove the CSS to set font-weight
from bootstrap.css.
The html for tables used by us has a following structure-
<table>
<thead>
<tr>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>
So, as per the above structure, we do not have th elements
inside tbody and td elements inside thead and thus we can
remove the bootstrap CSS rules for these cases. Also, we
always have a thead before tbody, so tbody:first-child CSS
can also be removed.
We use "tfoot" element only in realm_domains_modal.hbs
template and this table does not have table-bordered class.
The bootstrap CSS rules for "tfoot" elements are only for
the "tfoot" elements inside a table with "table-bordereds"
class so we can safely remove the bootstrap CSS.
This commit adds code to pass stream traffic data using
the "stream_weekly_traffic" field in stream objects.
We already include the traffic data in Subscription objects,
but the traffic data does not depend on the user to stream
relationship and is stream-only information, so it's better
to include it in Stream objects. We may remove the traffic
data and other stream information fields for Subscription
objects in future.
This will help clients to correctly display the stream
traffic data in case where client receives a stream
creation event and no subscription event, for an already
existing stream which the user did not have access to before.
This commit improves the description for stream_weekly_traffic
field in API documentation to make it clear to the readers about
how to interpret the value.
This commit changes the code to not use get_client_data
function and instead use `stream_to_dict` function to
get the stream data in a dictionary form. This is a
prep commit add stream traffic data to Stream objects.
This commit adds stream_to_dict method which is same as
Stream.to_dict method as of now. This is a prep commit
to include stream traffic data in stream objects.
The save-discard was not being hidden properly in the below case-
- The "Default language for code blocks" setting was disabled
initially (i.e. the "Disable" option was selected in the dropdown),
meaning there was not default language set.
- The setting is then udpated to "javascript" and the save-discard
widget is shown as expected.
- The setting is then again change to "Disable" option.
The save-discard widget should have been hidden after the last
step, but it does not.
This was because while comparing the old and new value, the new
value (obtained using get_dropdown_list_widget_setting_value) was
computed as "null" while the old value (obtained from page_params)
was an empty string "". This commit fixes the bug by changing
get_dropdown_list_widget_setting_value to return empty string "",
instead of null, when the "Disable" option is selected in the
dropdown.
The "get_dropdown_list_widget_setting_value" function was returning
null previously, as we supported both null and empty string "" to
represent the state of no language selected, with null being the
initial value and empty string being used if user changed the
setting to some language and then disabled it again.
This was changed in #26275 and the state of not setting any default
language for code blocks is now represented using empty string in
all cases.
The save-discard widget was not showing and hiding correctly
for the "Automated messages and emails" section in organization
settings panel. This was because the "proposed_val" was always
being returned as "undefined" for language setting as
"data-language-code", which is used to check the proposed value
of setting, was not set after changes in 36475daba7.
This commit fixes it by passing language_code value to
language_selection_widget and thus setting "data-language-code"
attribute correctly.
The changes in 36475daba7 removed language_code parameter from
language_selection_widget as it was not passed in the template
from "Display settings" section. So, this commit also passes
the language_code parameter to language_selection_widget from
"Display settings" section.
This change sets the "data-language-code" attribute even when
it is not being used there, to make sure there is no reference
to undefined fields in language_selection_widget.
Note that the above bug was reproducible only if you have not
changed the language even once and are trying to change the
other settings, as the data-language-code attribute was set
after selecting a language from the modal, but it was not
set initially after rendering the page.
It is possible that the current value of a dropdown widget is
valid but not present in options since the current user doesn't
have access it. So, we show [disabled] as value in that case.
This can be reproduced by setting a private stream for
notifications in org settings and then opening org settings
as a user which doesn't have access to the private stream.
Earlier while changing group level group based settings
there was no check if the new value for setting is same as
the current value.
This commit adds this check now a setting value will be only
changed when it is not equal to present value.
Previously, this code:
```python3
old_archived_attachments = ArchivedAttachment.objects.annotate(
has_other_messages=Exists(
Attachment.objects.filter(id=OuterRef("id"))
.exclude(messages=None)
.exclude(scheduled_messages=None)
)
).filter(messages=None, create_time__lt=delta_weeks_ago, has_other_messages=False)
```
...protected from removal any ArchivedAttachment objects where there
was an Attachment which had _both_ a message _and_ a scheduled
message, instead of _either_ a message _or_ a scheduled message.
Since files are removed from disk when the ArchivedAttachment rows are
deleted, this meant that if an upload was referenced in two messages,
and one was deleted, the file was permanently deleted when the
ArchivedMessage and ArchivedAttachment were cleaned up, despite being
still referenced in live Messages and Attachments.
Switch from `.exclude(messages=None).exclude(scheduled_messages=None)`
to `.exclude(messages=None, scheduled_messages=None)` which "OR"s
those conditions appropriately.
Pull the relevant test into its own file, and expand it significantly
to cover this, and other, corner cases.
evykassirer
evykassirer
Anders Kaseorg
David Rosa
Lauryn Menard
Alya Abbott
Prakhar Pratyush
Sahil Batra
Aman Agrawal
Tim Abbott
Ujjawal Modi
Alex Vandiver
Karl Stolley