-
Notifications
You must be signed in to change notification settings - Fork 327
Redesign the OAUTH callback page #13127
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
base: develop
Are you sure you want to change the base?
Conversation
3a2d343
to
e24c457
Compare
app/gui/src/beforeMain.ts
Outdated
import * as detect from 'enso-common/src/detect' | ||
import './config' |
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 think config is run in script
HTML tag, so should not be needed anywhere?
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, I initially added it because for some reason I had $config is not defined
error. But it seems like it's gone
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.
@farmaazon on the second thought removing isn't a good option either 🤔 https://github.com/enso-org/enso/actions/runs/15136617435/job/42549797182?pr=13127#step:12:299
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.
So I always assumed that the separate <script> tag is needed for bazel. Calling @Frizi in to confirm.
As an alternative (if indeed needed), we could just add import as first in the test file.
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.
subscribing to this thread because i also need a hacky workaround for this in one of my PRs:
enso/app/gui/src/ReactRoot.tsx
Lines 55 to 60 in dd2a8d3
const setFeatureFlag = useSetFeatureFlag() | |
useMount(() => { | |
if (typeof window !== 'undefined' && window.overrideFeatureFlags === undefined) { | |
setFeatureFlag('enableLocalBackend', $config.CLOUD_BUILD !== 'true') | |
} | |
}) |
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.
So I always assumed that the separate <script> tag is needed for bazel. Calling @Frizi in to confirm.
It's correct, I'm voting for including the config in setups for tests/storybook. @farmaazon @Frizi @somebody1234 WDYT?
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.
The split of config into a separate script is intentional for future work, though right now it is NOT being used in the build process. The intention is to eventually do a post-build config value replacing to guarantee that testing and production builds are exact same, and config is literally the only difference between them. We have a script that does it (envReplacer.mjs
), but it is currently disabled to keep our build process simple while we still have legacy rust pipeline going. I would however like to keep the config script a separate chunk. All typing issues should be fixed purely on typescript level, since the variable is supposed to be treated as a global $config
exposed on window before any other application code runs.
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.
So as I understand, there is no problem in importing them for tests and storybooks, as those won't have any config replaced as a build step.
@@ -13,7 +13,7 @@ import * as lazyMemo from '#/hooks/useLazyMemoHooks' | |||
import * as safeJsonParse from '#/utilities/safeJsonParse' | |||
import { useRouterInReact } from '$/providers/react' | |||
import { type RouteLocationOptions } from 'vue-router' | |||
import { ZodSchema, type z } from 'zod' | |||
import { type z } from 'zod' |
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.
import { type }
-> import type {}
? same with the import from vue-router
above
@@ -78,6 +80,16 @@ export function DriveBarToolbar(props: DriveBarToolbarProps) { | |||
const { isOffline } = useOffline() | |||
const canDownload = useCanDownload() | |||
|
|||
const [credentialsModalOpen, setCredentialsModalOpen] = useSearchParamsState( | |||
'credentialsModal_open', |
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.
stylistic nit: maybe consider credentialsModal.open
as key if that is valid
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.
CR ✅
b685ff2
to
0741de7
Compare
✨ GUI Checks ResultsSummary
See individual check results for more details. ℹ️ Chromatic Tests SkippedChromatic visual regression tests were skipped for this PR. To run the tests and deploy Storybook, add the Note: We skip tests by default to optimize CI costs. Only run them when your UI changes are ready for review. 🎭 Playwright Test ResultsSummary
👮 Lint GUI ResultsCheck Results
ESLint15 Error(s):
|
4d9eb82
to
c324a02
Compare
f82d93a
to
c099e39
Compare
@PabloBuchu re: retry authentication, i guess we should leave it for another PR @radeusgd would probably be the most appropriate to answer which steps it would involve specifically (i can handle implementation, just not familiar enough with the credential stuff to know how difficult it will be to allow for that) |
Even for successful authentication we wanted to have a refresh button to refresh expired credentials, so yeah that would be useful. I think it depends on how we want to do this. If we are fine with reading the secret data on client side (which feels a bit unsafe but tbh nothing stopping us from calling the If we are not okay with reading the metadata stored in secret payload for refreshing the credential in the client, we'd probably need to move the logic for generating the URL onto the backend and modify both the create and refresh/retry endpoints to relate on that. Please let me know if this clarifies or some further clarifications are needed. |
Pull Request Description
Closes: https://github.com/enso-org/cloud-v2/issues/1874
This PR is based on the https://github.com/enso-org/cloud-v2/pull/1969 and shall be merged (and tested) in sync
Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
or the Snowflake database integration, a run of the Extra Tests has been scheduled.