Release Notes:
- Fixed the issue related to the project wide search being stuck when
project contains .fifo files
- Might potentially solve the following issue
https://github.com/zed-industries/zed/issues/7360
This PR makes the `github_user_id` column on the `users` table required
and replaces the index with a unique index.
I have gone through and ensured that all users have a unique
`github_user_id` in the staging and production databases.
Release Notes:
- N/A
This PR restricts usage of the LLM service to accounts older than 30
days.
We now store the GitHub user's `created_at` timestamp to check the
GitHub account age. If this is not set—which it won't be for existing
users—then we use the `created_at` timestamp in the Zed database.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
This adds the requirement for users to accept the terms of service the
first time they send a message with the Cloud provider.
Once this is out and in a nightly, we need to add the check to the
server side too, to authenticate access to the models.
Demo:
https://github.com/user-attachments/assets/0edebf74-8120-4fa2-b801-bb76f04e8a17
Release Notes:
- N/A
This PR reworks how we process Stripe events for reconciliation
purposes.
The previous approach in #15480 turns out to not be workable, on account
of the Stripe event IDs not being strictly in order. This meant that we
couldn't reliably compare two arbitrary event IDs and determine which
one was more recent.
This new approach leans on the guidance that Stripe provides for
webhooks events:
> Webhook endpoints might occasionally receive the same event more than
once. You can guard against duplicated event receipts by logging the
[event IDs](https://docs.stripe.com/api/events/object#event_object-id)
you’ve processed, and then not processing already-logged events.
>
> https://docs.stripe.com/webhooks#handle-duplicate-events
We now record processed Stripe events in the `processed_stripe_events`
table and use this to filter out events that have already been
processed, so we do not process them again.
When retrieving events from the Stripe events API we now buffer the
unprocessed events so that we can sort them by their `created` timestamp
and process them in (roughly) the order they occurred.
Release Notes:
- N/A
This PR improves our Stripe event handling by keeping track of the last
event we've seen for each record.
The `billing_customers` and `billing_subscriptions` tables both have a
new `last_stripe_event_id` column. When we apply an event to one of
these records, we store the event ID that was applied.
Then, when we are going through events we can ignore any event that has
an ID that came before the `last_stripe_event_id` (based on the
lexicographical ordering of the IDs).
Release Notes:
- N/A
This PR adds a new `billing_customers` table to hold the billing
customers.
Previously we were storing both the `stripe_customer_id` and
`stripe_subscription_id` in the `billable_subscriptions` table. However,
this creates problems when we need to correlate subscription events back
to the subscription record, as we don't know the user that the Stripe
event corresponds to.
By moving the `stripe_customer_id` to a separate table we can create the
Stripe customer earlier in the flow—before we create the Stripe Checkout
session—and associate that customer with a user. This way when we
receive events down the line we can use the Stripe customer ID to
correlate it back to the user.
We're doing some destructive actions to the `billing_subscriptions`
table, but this is fine, as we haven't started using them yet.
Release Notes:
- N/A
This PR adds a new `billing_subscriptions` table to the database, as
well as some accompanying models/queries.
In this table we store a minimal amount of data from Stripe:
- The Stripe customer ID
- The Stripe subscription ID
- The status of the Stripe subscription
This should be enough for interactions with the Stripe API (e.g., to
[create a customer portal
session](https://docs.stripe.com/api/customer_portal/sessions/create)),
as well as determine whether a subscription is active (based on the
`status`).
Release Notes:
- N/A
Co-Authored-By: Mikayla <mikayla@zed.dev>
In a fit of ill-advisedness I called these things remote projects;
forgetting that remote project is also what we call collaboratively
shared projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
* Store extensions versions' wasm API version in the database
* Share a common struct for extension API responses between collab and
client
* Add wasm API version and schema version to extension API responses
Release Notes:
- N/A
Co-authored-by: Marshall <marshall@zed.dev>
This PR provides some of the plumbing needed for a "remote" zed
instance.
The way this will work is:
* From zed on your laptop you'll be able to manage a set of dev servers,
each of which is identified by a token.
* You'll run `zed --dev-server-token XXXX` to boot a remotable dev
server.
* From the zed on your laptop you'll be able to open directories and
work on the projects on the remote server (exactly like collaboration
works today).
For now all this PR does is provide the ability for a zed instance to
sign in
using a "dev server token". The next steps will be:
* Adding support to the collaboration protocol to instruct a dev server
to "open" a directory and share it into a channel.
* Adding UI to manage these servers and tokens (manually for now)
Related #5347
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Resurrected this from some assistant work I did in Spring of 2023.
- [x] Resurrect streaming responses
- [x] Use streaming responses to enable AI via Zed's servers by default
(but preserve API key option for now)
- [x] Simplify protobuf
- [x] Proxy to OpenAI on zed.dev
- [x] Proxy to Gemini on zed.dev
- [x] Improve UX for switching between openAI and google models
- We current disallow cycling when setting a custom model, but we need a
better solution to keep OpenAI models available while testing the google
ones
- [x] Show remaining tokens correctly for Google models
- [x] Remove semantic index
- [x] Delete `ai` crate
- [x] Cloud front so we can ban abuse
- [x] Rate-limiting
- [x] Fix panic when using inline assistant
- [x] Double check the upgraded `AssistantSettings` are
backwards-compatible
- [x] Add hosted LLM interaction behind a `language-models` feature
flag.
Release Notes:
- We are temporarily removing the semantic index in order to redesign it
from scratch.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Max <max@zed.dev>
This should significantly reduce database load on redeploy.
Co-Authored-By: Max <max@zed.dev>
Co-Authored-By: Nathan <nathan@zed.dev>
Release Notes:
- Reduced likelihood of being disconnected during deploys
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Add plumbing for hosted projects. This will currently show them if they
exist
but provides no UX to create/rename/delete them.
Also changed the `ChannelId` type to not auto-cast to u64; this avoids
type
confusion if you have multiple id types.
Release Notes:
- N/A
This PR adds a REST API to the collab server for searching and
downloading extensions. Previously, we had implemented this API in
zed.dev directly, but this implementation is better, because we use the
collab database to store the download counts for extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
- Open channel notes and chat on channel click
- WIP
- Fix compile error
- Don't join live kit until requested
- Track in_call state separately from in_room
Release Notes:
- Improved channels: you can now be in a channel without joining the
audio call automatically
**or**
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Feature
- [x] Allow to click on reply to go to the real message
- [x] In chat
- [x] Show only a part of the message that you reply to
- [x] In chat
- [x] In reply preview
TODO’s
- [x] Fix migration
- [x] timestamp(in filename)
- [x] remove the reference to the reply_message_id
- [x] Fix markdown cache for reply message
- [x] Fix spacing when first message is a reply to you and you want to
reply to that message.
- [x] Fetch message that you replied to
- [x] allow fetching messages that are not inside the current view
- [x] When message is deleted, we should show a text like `message
deleted` or something
- [x] Show correct GitHub username + icon after `Replied to: `
- [x] Show correct message(now it's hard-coded)
- [x] Add icon to reply + add the onClick logic
- [x] Show message that you want to reply to
- [x] Allow to click away the message that you want to reply to
- [x] Fix hard-coded GitHub user + icon after `Reply tp:`
- [x] Add tests
<img width="242" alt="Screenshot 2024-02-06 at 20 51 40"
src="https://github.com/zed-industries/zed/assets/62463826/a7a5f3e0-dee3-4d38-95db-258b169e4498">
<img width="240" alt="Screenshot 2024-02-06 at 20 52 02"
src="https://github.com/zed-industries/zed/assets/62463826/3e136de3-4135-4c07-bd43-30089b677c0a">
Release Notes:
- Added the ability to reply to a message.
- Added highlight message when you click on mention notifications or a
reply message.
---------
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Don't allow granting guests write access in a call where the channel
or one of its ancestors requires the zed CLA, until that guest has
signed the Zed CLA.
Co-authored-by: Marshall <marshall@zed.dev>
* Use the impersonator id to prevent these tokens from counting
against the impersonated user when limiting the users' total
of access tokens.
* When connecting using an access token with an impersonator
add the impersonator as a field to the tracing span that wraps
the task for that connection.
* Disallow impersonating users via the admin API token in production,
because when using the admin API token, we aren't able to identify
the impersonator.
Co-authored-by: Marshall <marshall@zed.dev>
TheCub3