Previoulsy, test_openapi_arguments had assumed that an endpoint
not using rest_dispatch used the GET method for the request. This
was not the case for the "/fetch_api_key" and "/dev_fetch_api_key"
endpoints, which is why those endpoints were marked as pending
even though they were documented in `zerver/openapi/zulip.yaml`.
Updates test_openapi_arguments to check a set of endpoints that
are documented and don't use the GET method so that these endpoints
can be tested and removed from the pending_endpoints set.
We should just accept `subscribed` and `previously_subscribed` fields as
arguments to this function to avoid adding them on the `attrs` object
itself to simplify the type for `ApiGenericStreamSubscription`.
We should always return `boolean` type instead of `boolean | undefined`
type for functions `is_subscribed_by_name`, `is_subscribed`,
`is_web_public` to stay consistent with other similar functions which
have the type of `boolean` like `is_invite_only_by_stream_name` and
`is_web_public_by_stream_name`.
After commit e52a3bc662, `BinaryDict`
class currently only deals with numeric stream ids so there is no
benefit to use case-insensitive `FoldDict` here anymore.
We need to include this "transform-optional-chaining" for babel presets
to prevent an error related to optional chaining syntax when we convert
this module to typescript. This error is a bug which is present in the
unmaintained `babel-plugin-rewire-ts` plugin.
I refined types for Subscription objects and Stream objects which were
already present `sub_store`. I took reference for the types from the
`zerver/lib/types.py` file.
This commit refactors the `sub` object we were creating in
`create_sub_from_server_data` function, there were some fields which
didn't need to have a default set like `name`, `description` etc. so we
can remove those fields from here.
Also I set the color field in the object field itself to avoid making an
incomplete type object with not having `color` propertie initially.
We should make a new object called `attrs` instead of adding new fields
directly to `sub` in `populate_subscriptions` method because these
additional properties which are being added does not staisfy the type
definition for the data we are getting from the server.
Because of this when we will type this function we will get type errors
saying that these additional field does not exist. So we should make a
seperate object with the correct types.
Add type annotations. Create custom types for Bot and Service.
Add zod data validation for incoming bot data from server.
Based on `zerver/openapi/zulip.yaml` description, `add` operation
(`op`) carries data that follows `Bot` structure. So taking
reference from `bot` structure, I create `ServerAddBotData` zod
schema and infer its type. Similarly, `update` operation carries
data that follows `BasicBot`, so I create `ServerUpdateBotData`.
Note that `Bot` inherits from `BasicBot`.
`zerver/openapi/zulip.yaml` describes that `services` in `BasicBot`
can be one of two objects, one with `{base_url, token, interface}`,
another with `{service_name, config_data}`. Therefore, I create
two corresponding schema and infer their types.
Fix two test cases `bot_data.test.js` and `settings_bots.test.js`
whose synthetic objects should have had followed the schema.
Added type annotations for function parameters and return values.
Added non-null assertions or type narrowing to some variables to
enforce type safety.
In `global.d.ts`, I added a namespace `JQueryValidation` which is
neccessary for type annotations inovolved in `jquery-validation`
plugin.
Previous line written in that way assumes `email_form` will appear
in the `document`. A modernly standard way is to use `querySelector`
selecting by id. Another advantage is easy for enforcing typecheck.
The commit related to this line of change is linked below:
9cb682cada
`signup.js` uses `jquery-validation` plugin, which is a javascript
package shipped without type definitions. Installing its corresponding
types help with TypeScript migration by allowing types annotations
involving the plugin methods and obejcts.
Throughout the codebase there is currently one usage of `autofocus`
excepts in test files. The only one usage is in `signup.js` and was
supposed to pass a `JQuery` selector to `autofocus` rather than a
string. Passing a selector is more convenient in this case: The
selector accessed in `signup.js` is ready to `trigger` the `focus`
function, while getting a attirubte string from the selector and then
passing to `autofocus` and then accessing the selector by attribute
cost extra layers of work. Therefore writing this commit to simplify
the type for easy usage.
Fixes the test case(s) accordingly.
This adds API support to reorder linkifiers and makes sure that the
returned lists of linkifiers from `GET /events`, `POST /register`, and
`GET /realm/linkifiers` are always sorted with the order that they
should processed when rendering linkifiers.
We set the new `order` field to the ID with the migration. This
preserves the order of the existing linkifiers.
New linkifiers added will always be ordered the last. When reordering,
the `order` field of all linkifiers in the same realm is updated, in
a manner similar to how we implement ordering for
`custom_profile_fields`.
The curl examples of reordering linkifiers require there to be some
linkifiers in the database to be reordered. This adjusts some test cases
so they do not assume that there is no linkifier in the test db.
Select the linkifier with `:nth-child` assuming the possibility of other
linkifiers in the realm. This prepares for a later change that requires
us to populate the test database with linkifiers.
Each unittest subTest can fail without interrupting the other subTests.
By wrapping the test for each view function, we can get all validation
errors at once, which can be useful if multiple endpoints are updated.
More importantly, if the test fails anywhere inside test_openapi but
before the formatted output is printed, we will not lose the information
of which view function fails the validation. Because we attach the name
of the function to the subTest:
```
FAIL: test_openapi_arguments (zerver.tests.test_openapi.OpenAPIArgumentsTest) [zerver.views.alert_words.add_alert_words]
```
The number of affected objects may be quite high, and they are
selected by `id IN (...)` query, and updated with a giant `CASE`.
This turns out to be quadratic, and can cause large queries to take
hours, in a state where they cannot be terminated, when PostgreSQL >11
tries to JIT the query.
Set a batch_size as a stopgap performance fix before moving to
`.update()` as a real fix.
Organization owners can make streams private even if they're not
subscribed to them, but cannot access private streams they're not
subscribed to. This means they're able to lock themself out of streams.
This change warns users of this and give them a chance to subscribe.
Fixes#26437.
In commit 5edc8fc, abstract classes were added to the
drafts overlay, but the classes that were already there
were not removed. This resulted in the same styles being
applied twice.
Removes the "dropdown-list-body" class and references as it is no
longer used in the new DropdownWidget. The previous uses of the
class were removed in commit 875d564f2d.
We should have a clear reference in the "Writing messages" sidebar
section on linking to other conversations below "Mention a user
or group" to clarify mentioning users vs linking to conversations.
This adds a link to the "Link to a message or conversation" article
with a different heading.
We have historically cached two types of values
on a per-request basis inside of memory:
* linkifiers
* display recipients
Both of these caches were hand-written, and they
both actually cache values that are also in memcached,
so the per-request cache essentially only saves us
from a few memcached hits.
I think the linkifier per-request cache is a necessary
evil. It's an important part of message rendering, and
it's not super easy to structure the code to just get
a single value up front and pass it down the stack.
I'm not so sure we even need the display recipient
per-request cache any more, as we are generally pretty
smart now about hydrating recipient data in terms of
how the code is organized. But I haven't done thorough
research on that hypotheseis.
Fortunately, it's not rocket science to just write
a glorified memoize decorator and tie it into key
places in the code:
* middleware
* tests (e.g. asserting db counts)
* queue processors
That's what I did in this commit.
This commit definitely reduces the amount of code
to maintain. I think it also gets us closer to
possibly phasing out this whole technique, but that
effort is beyond the scope of this PR. We could
add some instrumentation to the decorator to see
how often we get a non-trivial number of saved
round trips to memcached.
Note that when we flush linkifiers, we just use
a big hammer and flush the entire per-request
cache for linkifiers, since there is only ever
one realm in the cache.
Lalit Kumar Singh
David Rosa
Lauryn Menard
Daniil Fadeev
Lalit Singh
Junyao Chen
Alex Vandiver
Zixuan James Li
Satyam Bansal
evykassirer
Julia Bichler
Steve Howell