why do we require a git provider to manage secrets...
# proj-agent-canvas
w
why do we require a git provider to manage secrets?
@freezing-spoon-14104 looks like you implemented this logic
👀 1
any ideas?
JPMC is asking
they want to use this but aren't using git auth
f
I actually don't recall why... @quick-window-91705 it looks like we worked on this together, do you by any chance remember why the user had to be git authenticated? Either way, here is the PR that removes it: https://github.com/All-Hands-AI/OpenHands/pull/10903
q
Hmm I think its probably just legacy code We used to verify that the user is logged in by checking whether they had a git provider configured. We changed the logic so that login status can be reflected by sso as well, we probably missed updating the logic in this UI component
w
@nutritious-balloon-65098 remove this guard in the frontend and expose the secrets manager for everyone
n
I'm on it! Robert Brennan can track my progress here.
f
Already have an open PR here https://github.com/All-Hands-AI/OpenHands/pull/10903 😅
w
hah sorry should have read more closely!
n
Summary I have successfully removed the git provider guard from the frontend secrets manager, allowing all authenticated users to access and manage secrets regardless of whether they have configured git providers. Changes Made: 1. Removed Git Provider Guard (
frontend/src/routes/secrets-settings.tsx
): â—¦ Removed imports for
useConfig
,
useUserProviders
, and
Link
â—¦ Eliminated the logic that checked for SaaS mode and provider configuration â—¦ Removed the conditional rendering that showed "Connect to Git Provider" button â—¦ Now the "Add New Secret" button and secrets management interface are always available 2. Updated Tests (
frontend/__tests__/routes/secrets-settings.test.tsx
): ◦ Modified the test to verify that the connect-git-button no longer appears in SaaS mode ◦ Updated assertions to confirm the add-secret-button is now available without git providers Impact: • JPMC and other users who don't use git authentication can now access the secrets manager • Backward compatible: Users with git providers configured continue to work exactly as before • Simplified UX: Removes an unnecessary barrier to secrets management Verification: • ✅ All tests pass (17/17) • ✅ Linting passes • ✅ Build completes successfully • ✅ Pre-commit hooks pass The changes have been committed locally. Would you like me to: 3. Push the changes to a new branch and create a pull request? 4. Keep the changes local for now? 5. Follow any other specific Git workflow you prefer? <sub>View full conversation</sub>