-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: DIA-1748: 'Generate labels with AI' button in Project, in SC #43
base: master
Are you sure you want to change the base?
Changes from 3 commits
57af2f1
6ac2164
794dc8a
1d94cac
704bbaa
b134779
34f5125
e2c6b41
8fdf8ce
45ce14b
fc5dde6
089ff9e
4f3ff96
af1cd00
c0d8e82
dd159a3
33b163b
8c0cb9a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,18 @@ | ||
paths: | ||
/api/current-user/product-tour: | ||
get: | ||
$ref: "./resources/users.yaml#/paths/~1api~1current-user~1product-tour/get" | ||
x-fern-sdk-group-name: users | ||
x-fern-sdk-method-name: get_product_tour | ||
x-fern-audiences: | ||
- internal | ||
patch: | ||
$ref: "./resources/users.yaml#/paths/~1api~1current-user~1product-tour/patch" | ||
x-fern-sdk-group-name: users | ||
x-fern-sdk-method-name: update_product_tour | ||
x-fern-audiences: | ||
- internal | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TIL about x-fern-audiences, it looks like this only defines the group and doesn't do anything unless there is logic elsewhere to tell if a user is internal or not. Is that true? Setup to do this in future? Maybe leave a comment about it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. added |
||
/api/prompts/: | ||
get: | ||
$ref: "./resources/prompts.yaml#/paths/~1api~1prompts/get" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we need to have a product discussion about baking in the assumption 1 project == 1 prompt so deeply, but it's fine for now, since we're all familiar enough with the codebase. Our data models can support many to many, and for testing at least it's very common ime to create many prompts for the same project, but if you didn't know that, it'd be easy to lose track of the extra prompts and introduce bugs that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with this more generic approach: added a support multiple
prompts
instead a singleprompt
case on the API level, and by handling special case with the first prompt only in the current UI instead.