Currently, it handles two hook types: 'pre-create' (to verify that the
user is authenticated and the file size is within the limit) and
'pre-finish' (which creates an attachment row).
No secret is shared between Django and tusd for authentication of the
hooks endpoints, because none is necessary -- tusd forwards the
end-user's credentials, and the hook checks them like it would any
end-user request. An end-user gaining access to the endpoint would be
able to do no more harm than via tusd or the normal file upload API.
Regardless, the previous commit has restricted access to the endpoint
at the nginx layer.
Co-authored-by: Brijmohan Siyag <brijsiyag@gmail.com>
This provides significant size savings:
| Emoji set | png size | webp size | webp/png percent |
| ----------- | -------- | --------- | ---------------- |
| google-blob | 1968954 | 1373350 | 69.75% |
| twitter | 2972820 | 2149672 | 72.31% |
| google | 3455270 | 2327834 | 67.37% |
Since these are the largest assets that we ship to clients, it is
worth shaving off every byte we can.
Shows a stream info popover whenever a channel pill is clicked (such
as in the pill widgets for adding subscribers to a channel or
invitations). The stream info popover contains channel icon and name,
channel description and a link to channel settings.
Fixes#30567.
We start caching MessageListData objects for the narrows which
user has visited. We restore the cached objects if the filters
match. Also, the cached objects are updated based on events. One
major piece is update path the is pending implementation is the
message move code path.
currently, after a user edits a message and removes an reference to the
uploaded file, the uploaded file stays on the storage taking up space.
We want to ask the user to possibly delete the removed attachments if
they are no longer needed. These changes applies a modal that will appear
prompting the user to delete the attachments.
Fixes: #25525.
Co-authored-by: brijsiyag
Co-authored-by: wandrew0
All endpoints have been migrated to the typed_endpoint decorator,
therefore the has_request_variables decorator and the REQ function are
no longer needed and have been removed.
We previously used the file extension to determine if we should
attempt to inline an image. After b42863be4b, we rely on the
existence of ImageAttachment rows to determine if something is an
image which can be viewed inline. This means that messages
containing files uploaded before that commit, when (re-)rendered, will
be judged as not having inline'able images.
Backfill all of the ImageAttachment rows for image-like file
extensions. We are careful to only download the bytes that we need in
the image headers, to minimize bandwidth from S3 in the event that the
S3 backend is in use. We do _not_ produce thumbnails for the images
during this migration; see the subsequent commit.
Because this migration will be backported to 9.x, it is marked as only
depending on the last migration in `9.x`, with a subsequent merge
migration into the tip of `main`.
Adds a link to the plan ledger view in the current plan information
shown in the support views. Link is not shown if the plan is 100%
sponsored, e.g., the Community plan.
Adds a formatted header area to the activity table template so
that it's easy to add useful information to these activity views.
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.
Fixes#30451.
In a case that both `--help-center` and `--help-center-dev-server`
flags are passed to `run-dev`, `--help-center` flag will take
precedence without throwing any error.
We also add a script called `build-help-center` that is required
to build the starlight documentation. If the `help-beta/dist` dir
is not present, `run-dev` will show an error message but will not
fail.
This is the tool that we will consistently use for our project to
migrate our help center to use starlight.
We're only doing string manipulation in this tool for now, we will
start to use existing markdown preprocessors whenever appropriate
as we start to add support for different components.
Running the tool again will overwrite the existing files.
The more neutral folded_hands is the official name and should make
folks more confortable with using this for thank_you, which is
certainly a more common use in work contexts than pray.
If the email subject is something like `Fwd:`, it gets stripped to an
empty string, activating the "(no topic)" override. This however leads
to failure if the organization enables the setting forcing every message
to have a topic. Such emails should still go through, so we should just
change the topic value used.
Earlier, on sending a new message in a search view it didn't
appear in that view for the sender.
This was because the message event received by the sender
was processed by 'msg_list.view.rerender_messages' which
effectively did nothing because the message is not
rendered in the first place during local echo in that
message list view.
We can't determine locally if the message should be added
to the search narrow. So, we use maybe_add_narrowed_messages
when narrowed to such views.
This fixes the bug and the message appears in the search view.
The commit creates a `server_message.ts` module which
will home our `zod` schema for the messages received
from server. We can then import the schema to parse
the data in needed modules at the API boundaries.
This will also help us write better tests.
As part of the popover menu redesign, this commit redesigns the user
card popover using the new "popover-menu" tippy theme and improves
accessibility by using appropriate ARIA attributes.
This supports adding users to DM pills by simply typing
a user's name in the text input directly after a complete
dm pill. It only works for DM pills at the end of search
input.
Clicking the X button removes a user from its user pill
container, and if that user was the last user left in the
container, then the whole container is also removed.
This commit renames the "Huddle" Django model class to
"DirectMessageGroup", while maintaining the same table --
"zerver_huddle".
Fixes part of #28640.
Adds a linter rule for markdown files so that new cases of "e.g."
without a comma wont be introduced to user-facing documentation.
Fixes the remaining cases of "e.g." in markdown files that are not
followed by a comma.
This commit updates screenshots for the "for/business" and
"for/open-source" pages, and adds the script for generating
their screenshots at "screenshots/companies.json."
Fixes part of #30128
This commit extends the script used to generate thread
screenshots to be able to create invite_only streams,
add starred messages, create user groups, add edited
notice to messages, and send messages from notification
bots.
The window width is updated, and background for the
screenshots is changed to white.
It is also updated so that user-avatars mapping
occurs within the script itself.
This is a prep commit to #30128
Creates a new "realm_deactivated" email that can be sent to realm
owners as part of `do_deactivate_realm`, via a boolean flag,
`email_owners`.
This flag is set to `False` when `do_deactivate_realm` is used for
realm exports or changing a realm's subdomain, so that the active
organization owners are not emailed in those cases.
This flag is optional for the `deactivate_realm` management command,
but as there is no active user passed in that case, then the email
is sent without referencing who deactivated the realm.
It is passed as `True` for the support analytics view, but the email
that is generated does not include information about the support
admin user who completed the request for organization deactivation.
When an active organization owner deactivates the organization, then
the flag is `True` and an email is sent to them as well as any other
active organization owners, with a slight variation in the email text
for those two cases.
Adds specific tests for when `email_owners` is passed as `True`. All
existing tests for other functionality of `do_deactivate_user` pass
the flag as `False`.
Adds `localize` from django.util.formats as a jinja env filter so
that the dates in these emails are internationlized for the owner's
default language setting in the "realm_deactivated" email templates.
Fixes#24685.