When I click on the gear to open the settings page [https://circleci.com/gh/organizations//settings], I just get a spinner. Clicking on any of the subnav items do the same.
When I look in the inspector, I see a 404 for URL: https://circleci.com/api/v1.1/organization/github//plan. The old settings page still works.
That is odd.
Clicking the gear on a project name leads you to Project Settings. That url structure for a GitHub project is
https://circleci.com/gh/$orgname/$projectname/edit
It appears we’re not pulling your organization name into $orgname - does that seem to match your experience?
Ah, that actually was some kind of markdown error involving < and >.
The two URLs I mention are:
https://circleci.com/gh/organizations/$orgname/settings
https://circleci.com/api/v1.1/organization/github/$orgname/plan
So if I click the gear icon in the menu on the left from the builds page, it sends me to the URL you noted there and works fine. When I click the gear in the upper right corner from the same page, then I’m sent to https://circleci.com/gh/organizations/$orgname/settings and it just spins.
Ah, ok so the gear also works works from within the project context, so it appears that the org settings page is the one that is broken and I was also confused about how to get to the settings page for the project only because it looked the same.
Facing the same issue here, the only difference is that I’m using Bitbucket.
404 on https://circleci.com/api/v1.1/organization/bitbucket/$orgname/plan
and infinite spinner on settings page
I am seeing this too. See screenshots:
@levlaz I have also emailed you directly about this issue.
@jammons
I believe this is fixed now.
The (understandable) confusion from the original complaint to this was
- I initially discussed Project Settings
- You were asking about Organization Settings
The underlying issue is you need to be an GH/BB admin to see the Org’s settings. We check that before displaying the page.
Our most recent fix was to make the experience a bit less unnerving but it was just a quick patch and doesn’t change the underlying concerns.
We have a team working on custom permissions such that we can start unravel ling the direct correlation to your code permissions.