Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Oct 15, 2025

Problem

When using the Studio sync provider with read-only access, several UI elements remained incorrectly enabled, allowing users to attempt write operations that would fail. This created a poor user experience where users could interact with controls that shouldn't be accessible.

Specifically, the following elements were not properly checking the editProhibited flag:

  • Token sets: Rename and Delete buttons remained active
  • Token sets: Duplicate button ignored read-only status
  • Themes: "New Theme" button was always enabled
  • Themes: Edit, Delete, and Save buttons in the theme modal were active
  • Theme groups: Rename button remained clickable
  • Footer: Pull button tooltip didn't indicate read-only status

Solution

Added comprehensive editProhibited checks across all relevant UI components to ensure proper read-only enforcement:

Token Sets

  • Fixed incorrect logic in TokenSetListItemContent.tsx where canDelete was using OR (||) instead of AND (&&)
  • Added editProhibited check to canDuplicate prop

Theme Management

  • Disabled "New Theme", "Delete Theme", and "Save Theme" buttons in ManageThemesModal.tsx
  • Disabled "Edit theme" button in SingleThemeEntry.tsx
  • Disabled "Rename group" button in ThemeListGroupHeader.tsx

User Feedback

  • Updated Footer pull button tooltip to show "Read only" when editProhibited is true
  • Added "readOnly" translation key to all 6 supported languages (en, es, fr, hi, nl, zh)

Storage Layer

  • Added canWrite() method to TokensStudioTokenStorage for consistency with other storage providers (GitHub, GitLab, etc.)

Testing

  • ✅ All linting checks pass
  • ✅ Build succeeds with no compilation errors
  • ✅ Existing tests continue to pass
  • ✅ Changeset created as required

Notes

The Tokens Studio GraphQL API doesn't currently expose permission information upfront (unlike GitHub/GitLab). The canWrite() method returns true optimistically, with write operations failing gracefully when permissions are insufficient. This implementation ensures the UI properly respects the editProhibited flag whenever it's set, regardless of how that state is determined.

Fixes #[issue-number]

Original prompt

for the Studio sync provider we dont seem to set everything to editProhibited that we should if i just have read access. for example, the token groups itself get the disabled state due to read only, but then the token categories (one level above, sizing, dimension, still show up as active. or the Rename / Delete on token sets stays active (cant duplicate though). Edit token remains active too. I can also create new themes. I think the only thing that correctly set editProhibited is the new button on a token group and the duplicate on a set. Maybe also the button in the footer "Pull" can be adjusted so it clearly shows "read only" in the tooltip


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

@changeset-bot
Copy link

changeset-bot bot commented Oct 15, 2025

🦋 Changeset detected

Latest commit: 00a360c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@tokens-studio/figma-plugin Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Co-authored-by: six7 <4548309+six7@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix edit prohibited states for read-only access in Studio sync provider Fix read-only access UI controls for Studio sync provider Oct 15, 2025
Copilot AI requested a review from six7 October 15, 2025 07:46
Copilot finished work on behalf of six7 October 15, 2025 07:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants