Page MenuHomePhabricator

Configure applications with public permissions (and user profiles) to not require users to login
Closed, ResolvedPublic

Description

When I try to click one of the countless buttons in the left sidebar of the main page, most of the stuff is private (requires login). Everything must be public by default unless there is a reason (and separate decision) for it to be private.

Update: Since we created this task, upstream has fixed basically all our reported problems with information not visible to anonymous users... except user profiles, and they seem to have a strong opinion about it.

Details

Reference
fl115

Event Timeline

flimport raised the priority of this task from to Medium.Sep 12 2014, 1:25 AM
flimport set Reference to fl115.

qgil wrote on 2014-04-17 22:31:48 (UTC)

"Most of the stuff" is not accurate. I found only Calendar, LegalPad, People, Owners. Hopefully this is configurable by admins when installing the "apps".

qgil wrote on 2014-04-18 16:57:06 (UTC)

Nemo, not all those apps are installed in our Phabricator, and in the final instance we will only install / show those that we intend to use. Here we have more options just because this is a test instance. Do you mind editing your comment and remove the noise?

I have gone through the applications offered in our current install and I have filed a bug upstream for the apps that are configured as Public but require login.

Applications with Public permissions requiring users to login
https://secure.phabricator.com/T4830

Nemo_bis wrote on 2014-04-18 19:27:09 (UTC)

It was definitely the majority of what I clicked. Not going to try again, they are too many: http://fab.wmflabs.org/settings/panel/home/

mattflaschen wrote on 2014-04-30 00:14:27 (UTC)

This is critical for the RFC in my opinion. Another important example is Differential (the code review); that also currently requires login to view.

mattflaschen wrote on 2014-04-30 00:16:50 (UTC)

Sorry, didn't mean to lower priority.

qgil wrote on 2014-04-30 05:03:15 (UTC)

The reason to move it to "Not critical for the RfC" is that there is nothing to discuss here. All services must be public, and upstream agrees.

This task is blocking T43: Decide how to organize projects directly, there is no way to forget about it. Moving it back.

qgil wrote on 2014-05-13 18:34:27 (UTC)

As far as I can see, the only blocker for Day 1 is the possibility for anonymous users to see user profiles. The rest of problems are related with applications that are out of scope for Day 1.

qgil wrote on 2014-05-18 19:37:52 (UTC)

You are welcome to follow the discussion upstream about public user profiles and how convenient/appropriate this idea is.

If user profiles would be accessible only to registered users, would this block Day 1? In my opinion this alone would not be a blocker, and therefore we could remove this task from the Day 1 project.

aklapper wrote on 2014-05-23 07:19:31 (UTC)

If user profiles would be accessible only to registered users, would this block Day 1?

Comparing to current Wikimedia Bugzilla which does not offer any user profiles at all I don't see any regression left here which should block Day 1.
Gerrit allows you querying for the activity of a person, but we don't plan to switch Code Review for Day 1 (board: http://fab.wmflabs.org/project/board/29/ ).

I do not know whether accessing user profiles without being logged in is possible in Trello and Mingle and considered critical (if you think so, reasons are welcome).

I propose to remove this ticket from Day 1 as anonymously accessing the other applications has been fixed upstream.

qgil wrote on 2014-05-30 00:35:02 (UTC)

+1

Qgil lowered the priority of this task from Medium to Lowest.Nov 7 2014, 9:44 AM
In T57#17177, @Qgil wrote:

... and it was quickly resolved upstream.

Since we created this task, upstream has fixed basically all our reported problems with information not visible to anonymous users... except user profiles, and they seem to have a strong opinion about it.

Honestly, I don't think this is a too big deal. Phabricator is a collaboration tool open for anybody with a Wikimedia account, so this is how big the barrier is. I don't feel like picking a fight with upstream or this, and I think we have many other local priorities before tackling this one.

Qgil set Security to None.

Proposing to close this task as Resolved, knowing that the user profiles remain visible to All Users, and knowing as well that if we find another corner nor Public to everyoine it will be probably fixed quickly upstream.

Aklapper claimed this task.

Thanks for the heads-up. Indeed, closing for now. Separate things found in darker corners can become new tasks.