Page MenuHomePhabricator

Accessing sprint project URLs requires being logged in
Closed, ResolvedPublic3 Estimated Story Points

Description

Accessing sprint project URLs like https://phabricator.wikimedia.org/sprint/view/935/ and https://phabricator.wikimedia.org/sprint/board/935/query/all/ requires being logged in.

Is this intended (or fixable)? That sprint project is already set to "Visible To: Public (No Login Required)" and "Editable By: All Users".

Event Timeline

Aklapper raised the priority of this task from to Lowest.
Aklapper updated the task description. (Show Details)
Aklapper changed Security from none to None.
Aklapper subscribed.
kevinator added a subscriber: Qgil.
kevinator subscribed.

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.

Christopher raised the priority of this task from Lowest to Medium.
Christopher edited a custom field.

@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.

@Christopher you should only assign a task to you when you can resolve it. Changing the Can Use policy to Public for Sprint in this instance can only be done by an admin (i.e. not me neither).

@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..

Aklapper claimed this task.

I have set "Can Use Application" from "All Users" to "Public" for the "Sprint" application under https://phabricator.wikimedia.org/applications/edit/SprintApplication/ - I'm sorry for any potential confusion I might have created here.
I can access https://phabricator.wikimedia.org/sprint/view/935/ and https://phabricator.wikimedia.org/sprint/board/935/query/all/ now without being logged in.

So I guess we're fine.