added @Qgil and Phabricator as a project to push up this new issue found in the Burndown extension.

Public access works on phab08. https://phab08.wmflabs.org/sprint/view/15/

The policy implementation on production must have overridden the default methods. I will look into it as part of T819.

https://phabricator.wikimedia.org/applications/view/SprintApplication/ says

Can Use Application All Users

Must be Public.

@Christopher: why wouldn't that commit be in production? We pulled from upstream just a few days ago, that commit is 25 days old.

I cannot know what upstream commit is being pulled into production unless it is tagged in puppet. What tag or commit was used to pull into production? phab08 is using T77082. In order to do CI, we should keep a testing instance in sync with production.

I see from the T77082 task that production has been updated to https://secure.phabricator.com/D10951. Please create a new tag that matches the commit for this as I suggested in T1322.

Hey Christopher. I don't know that I understand fully your proposal for using upstream differential DXXX's as local deploy tags (I think that was the suggestion). If that is the case I don't think we are going to do that. There is an arc patch branch currently in our local phab repo but it is really a special case of waiting on the mediawiki oauth provider to be integrated upstream. So far we have tried a few approaches to our own release tracking but always the https://gerrit.wikimedia.org/r/#/c/178840/2/manifests/role/phabricator.pp

Puppet configuration is canonical. It should even reflect the labs role tracking production, but I know that some of the labs instances may currently be lacking a primary caretaker and so are stale.

As Quim indicated, this access problem can be fixed if the Can Use Application setting is changed to "Public (No Login Required)" for Sprint. Currently it is only set to "All Users". I created a new task T78751 for this puppet discussion.

@Qgil it was not clear what the solution was when I claimed it. Within the main application controllers there are methods that enable the public policy. If one of these methods was missing or set to false, public access would not work. This is what I checked first. I assumed that everything was ok with the application settings because this question was explicitly addressed in the deployment task.

I have been looking at how capabilities work today and the truth is that none of the settings for Sprint other than the first one "Can Use Application" are valid. The capabilities need to be present in the Sprint application for it to use certain methods from Projects and Maniphest, but the settings for those apps cannot easily be overridden..