Fixes the URLRedirects for "help/about-streams-and-topics" and
"help/streams-and-topics" to go to "/help/introduction-to-topics"
since "help/channels-and-topics" has been redirected to that URL.
Earlier when compose box was opened or narrowed to pm, the recipient
pills were sorted according to user email strings instead of their
full names which was inconsistent with compose box placeholder text,
recipient row and message header.
This commit fixes the behaviour by introducing a `sort_email`
function to sort emails according to their full names and display
sorted pills.
Fixes: zulip#27375.
Co-authored-by: richardshaju <richardshaju66@gmail.com>
Earlier in drafts overlay, the order of pm recipients for the draft
was sorted differently to that of the pm group title.
This commit fixes the behaviour by sorting the drafts pm recipients
using `make_strcmp`.
Fixes part of zulip#27375.
Co-authored-by: richardshaju <richardshaju66@gmail.com>
Earlier in left sidebar, the recipient names were not sorted
consistently with the message header of the pm.
This commit fixes the behaviour by sorting the recipient names in
left sidebar with `make_strcmp`.
Fixes part of zulip#27375.
Co-authored-by: richardshaju <richardshaju66@gmail.com>
Earlier, in group direct message, the full names of group pm recipients
were sorted incorrectly which is used for tooltip on hovering over
recipient row and text placeholder of collapsed compose box. That
resulted in different order of recipient names.
This commit fixes the behaviour by using the `make_strcmp` to sort
the names to show in the tooltip and collapsed compose box.
Fixes part of zulip#27375.
Co-authored-by: richardshaju <richardshaju66@gmail.com>
Earlier, when narrowed to a group direct message, the header title
was sorted with respect to its email instead of their names. This
would result in message header and recipient row having different
order of recipients.
This commit fixes the behaviour by changing the order of the names
passed for the group message header using `make_strcmp`.
Fixes part of zulip#27375.
Earlier, the order of recipients in recipient row of group direct
message weren't in the same sorting pattern as that of message
title which would result in inconsistent order of recipient names.
This commit fixes the behaviour in `private_message_header` in
recipient row to sort the names using `strcmp`.
Fixes part of zulip#27375.
Co-authored-by: richardshaju <richardshaju66@gmail.com>
This also moves the 2px of reduced lefthand padding to the overall
width of the left sidebar, which will keep the left sidebar at its
same width (in other words, the message area will not shift any
further to the left, either).
Fixes#27565
Adds non-form section to Zulip Cloud support view with some basic
realm information: organization type, plan type, non-guest user
count and guest user count.
Uses a shared template for the basic realm data and adds a shared
support context dict for variables that are used in both remote
and Zulip Cloud support views.
Gives a baseline of current database queries for these single realm
or remote realm support views, so that as we add features to these
views, we can better manage how those changes impact the performance
of our support views in general.
There are a few places where we want to set the max invites for a
realm to the default for a realm's plan type, so this creates a
helper function that can be used consistently to get that default
value.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
Where "pure function" means that the group's value isn't changed
in this function.
This commit also modifies the function to just take a message.
This is part of a bigger refactor to calculate message list group
attributes and creating the group all at once instead of piecewise.
This is necessary to convert this module to typescript, since a
partially formed group is hard to type.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
We're going to need to be able to build the message list view
in pieces and put it all together in the end, instead of assigning
values directly to a half-formed object (which is hard to type).
This is part of the work towards that.
When we convert this module to typescript, the type of `rendered_date`
will need to be a valid input to `$element.html`. Elsewhere in this
file, the date is a string. Here it's a JQuery object, which isn't
a valid input, but HTMLElement is, so this commit converts it to that.
I tested this manually and it still renders correctly.
Django lazy-loads much of its modules, including the application's.
This defers the time to during the first request it serves. When
doing rolling-restarts, this means that the worker is marked "ready"
despite having multiple seconds more work to do. With small numbers
of workers, this causes a significant capacity drop, since effectively
more than one worker can be still reloading at a time. It also
results in poor user experience for the requests which are unlucky
enough to be served first.
Use the technique detailed in the uwsgi documentation[^1] to fake a
request during initial application load, which forces the application
to be loaded.
[^1]: https://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#dealing-with-ultra-lazy-apps-like-django
This has the impact of making rebuilding the database in a Zulip
development environment, or initializing a new production database,
dramatically faster.
This was generated by merging the output of `manage.py makemigrations`
with an empty migration.
Tested using `tools/rebuild-test-database` before and after this
change, and comparing the output of `pg_dump -d zulip_test` using
Git's diff comparison algorithm. Differences in that SQL dump include:
- The actual generated table contents, due to timestamps and the like;
this is expected and unrelated to schema.
- Orders of fields within tables, which is not significant in SQL.
- IDs assigned to tables in the ContentType table, which is expected
and not a problem with how that Django table is designed.
- Names of generated indexes and constraints; modern Django seems to
abbreviate long names differently for these, and it's not obviously
possible to configure those used by the `db_index` property. If
necessarily, likely this can be converged via a migration filled
with `IF EXISTS` rename operations like the one done in
zerver/migrations/0246_message_date_sent_finalize_part2.py.
- Names of the ~3 sequences related to renamed tables:
usertopic/mutedtopic, botconfigdata/botuserconfigdata,
realmdomain/realmalias. Probably there's no action required here,
but we could do rename operations if desired.
Generated using manage.py squashmigrations, with minimal manual
surgery to replace the original migration.
This should in theory produce the exact same database state as
previously.
This has no functional changes, but it helps the squashmigrations tool
realize some squashing opportunities to not have models declared
before other models that they will gain a foreign key to.
Generated using manage.py squashmigrations, with some work:
- Used my patch to support squashing AddConstraint/RemoveConstraint
operations.
- Manually removed the add/deletion of cloud_xor_self_hosted, since it
didn't squash properly.
- Temporarily removed a couple operations from their migration files,
and added them back manually both to the original file and the
squash file, to allow later operations to squash
properly. Specifically, these are the two unsquashed operations
documented with comments at the end of the squash migration file.
Created using manage.py squashmigrations, with my patch to the Django
migration optimizer to correctly collapse
AddConstraints/RemoveConstraints operations.
Lauryn Menard
sujal shah
Pratik Chanda
opmkumar
Karl Stolley
Alex Vandiver
Anders Kaseorg
Kenneth Rodrigues
Aman Agrawal
evykassirer
Tim Abbott