Add a repository scope setting for organization repositories - #6
Merged
Conversation
The repository list is built from ownerAffiliations:OWNER, so it only ever contains repositories you personally own. Anyone whose day-to-day work lives in an organization cannot find those repositories through the panel's search, filters, or sort, even though the sections above already surface notifications, review requests and pull requests from them. The scope is an enum rather than a boolean because it describes what the list contains rather than toggling a behaviour, and it leaves room for a narrower or wider value later. It defaults to owned, so an existing install is unchanged. The heading reads REPOSITORIES instead of OWNED REPOSITORIES when the wider scope is in effect. It follows the scope reported by the payload rather than the setting, so it cannot claim to list organization repositories before the refresh that fetches them has landed.
Rename the payload echo to fetchedRepositoryScope and the derived getter to repositoryMode, mirroring actionScanBehavior and actionMode. The property and the setting key shared a name with different vocabularies, so a reader could reasonably take the heading for setting-driven and 'simplify' it back into the bug the design avoids. Match the setting against its known options instead of testing for the substring 'organization'. A later option such as 'Organizations only' would have matched and silently widened the scope, giving back exactly the room the enum was chosen to leave. Cover the QML half in the source suites: the setting mapping, the helper argument, and the scope-aware heading. Both regressions were verified to fail their new assertion. Drop the stale 'owned' wording from the Actions scan description, the plugin description, the repository dashboard section, and the empty state, which would otherwise have contradicted the heading above it.
Owner
|
Thanks @tmn73 for another thoughtful contribution. The repository-scope design is a useful improvement, and the PR did an excellent job calling out the Actions-scan tradeoffs and preserving the narrow default. I added clearer configuration and API-cost documentation, exact fail-closed Actions-mode handling, and scope-sensitive coverage. CI is green, so I’m merging this now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sorry for the PR spam, this should be the last one 😄.
I just really like this plugin and I want to be able to use it for everything, so I keep hitting small things that stop me from doing that.
The repository list is built from
ownerAffiliations:OWNER, so it only contains repositories I personally own. All my actual work is in an org, so searchingfrontendin that section finds nothing, even though the sections above already show me notifications, review requests and pull requests from those same repos.So: a
Repository scopesetting,OwnedorOwned and organizations. Defaults toOwned, so nothing changes for an existing install.An enum and not a boolean because it says what the list contains rather than toggling something, and it leaves room for another value later if you ever want one.
The heading becomes
REPOSITORIESinstead ofOWNED REPOSITORIESon the wider scope. It reads the scope back from the helper payload and not from the setting, so it can't sayREPOSITORIESwhile the list is still the owned-only one from the previous refresh.One thing worth knowing before you take it: the Actions scan picks the 15 most recently updated repos out of this list. On the wider scope those 15 tend to become org repos, since that's where the activity is, so personal repos quietly drop out of the two Actions sections. It's the right trade for someone turning the setting on imo, but it is a real side effect and it's not visible anywhere in the UI. Happy to leave it, or to keep the scan on owned repos only if you'd rather.
Same idea for cost: on
All repositoriesthe scan is 6 paginated calls per repo, so the wider scope raises the ceiling by however many org repos you can see. Default scan mode is stillRecent repositoriesso it stays at 15 either way, but someone in a big org who turns both up will hit the rate limit faster than before. I updated that setting's description, it said "every owned repository".On my account: 108 repos on
Owned, 118 onOwned and organizations, and the org repo I actually work in finally shows up in the search.tests/helper-test.sh,tests/panel-source-test.shandtests/service-source-test.shall pass, plusomarchy plugin validate .. New cases check that each scope reaches the query with the right affiliation, that the payload reports back what it fetched, and on the QML side that the setting maps correctly, that the flag is actually passed, and that the heading follows the fetched scope. I checked those last two fail if you break them.