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.
Before this change, the cursor left the DM recipient box after
selecting a pill from the typeahead. This was only the case with
mouse clicks and not with keyboard selection.
This change ensures we always return focus to the input field
after selection.
I move the helper user_ids_to_users to the only
place that it's used, and then I simplify it to
do a direct database query.
These endpoints aren't hit often enough to justify
caching complexity, and for really large user groups,
hitting the cache can actually be counterproductive.
Particularly when you add new users to an existing
group, the bulk of the cost is sending out
notification messages to users.
The only change to the test is that I added an
assertion on the query count.
The most expensive thing for adding user groups is sending
all the notification messages, but we at least want to make
sure that the basic stuff runs in constant time.
The cross-realm bots rarely change, and there are only
a few of them, so we just query them all at once and
put them in the cache.
Also, we put the dictionaries in the cache, instead of
the user objects, since there is nothing time-sensitive
about the dictionaries, and they are small. This saves
us a little time computing the avatar url and things
like that, not to mention marshalling costs.
This commit also fixes a theoretical bug where we would
have stale cache entries if somebody somehow modified
the cross-realm bots without bumping KEY_PREFIX.
Internally we no longer pre-fetch the realm objects for
the bots, but we don't get overly precise about picking
individual fields from UserProfile, since we rarely hit
the database and since we don't store raw ORM objects
in the cache.
The test diffs make it look like we are hitting the
cache an extra time, but the tests weren't counting
bulk fetches. Now we only use a single key for all
bots rather a key per bot.
The bulk_get_users() function was only being used to
get cross-realm bots.
It appears that it was introduced in
f02e5b90f6 for that
specific use case.
Now we make the function more specific and test it more
accurately.
We also eliminate a lot of janky code and comments,
including some code that never had test coverage.
Incidentally, it appears that we did not have any code
to invalidate the cache keys here, and that is still
the case. In practice I assume people rarely
re-configure their cross-realm bots unless they are
upgrading the server, and then KEY_PREFIX comes into
play. 25fd4c5508 seems
to have caused that hopefully harmless regression.
A further step will be to make this cache more coarse,
since there are only a few cross-realm bots. The next
commit will hopefully simplify the code and address the
validation pitfall.
Earlier the API endpoints related to user_group accepts and returns a
field `can_mention_group_id` which represents the ID
of user_group whose members can mention the group.
This commit renames this field to `can_mention_group`.
Sahil Batra
evykassirer
Aman Agrawal
Prakhar Pratyush
Tim Abbott
Ujjawal Modi
Alex Vandiver
Karl Stolley
Anders Kaseorg
Junyao Chen
Lalit Singh
evykassirer
Steve Howell