qgil wrote on 2014-05-21 21:50:16 (UTC)

About permissions, at this point I'm quite convinced that registered users should be able to create tasks (title, project, and description only) and comment. Users willing work would need to join manually the project EditTasks (and more if we want to fine-tune permissions). Bottom line: plain users get a plain UI for reporting bugs and commenting.

What do you think? Should we discuss this here or in a specific task?

aklapper wrote on 2014-08-20 16:24:31 (UTC)

Currently this ticket doesn't feel very actionable to me.

Projects will be created by the data import scripts (e.g. T423, T63), not sure which exact "permissions" are refered to here (T95?).

Not sure about the repositories part though.

Rush wrote on 2014-08-20 18:06:18 (UTC)

@aklapper....repo's would be post day 1 anyway, I would vote we close this as covered elsewhere or move it to post day 1

qgil wrote on 2014-08-20 20:16:59 (UTC)

Description sharpened; now it's actionable.

qgil wrote on 2014-08-26 07:41:18 (UTC)

From the description:

Which permissions do plain registered users have? One idea is to have less permissions in exchange of a simplest interface, combined with a public and easy path to join a Triagers team-project where they would get additional permissions (edit priority, summary of tasks, blockers, etc).

If nobody objects to this idea, I will implement it here in fab to test it out.

qgil wrote on 2014-08-26 20:42:26 (UTC)

I have added an important point that I just realized it is not implemented in this instance:

• Anonymous users should be able to access all the public information as read-only.

Now anonymous users get a login page -- and that's it.

qgil wrote on 2014-08-26 22:17:03 (UTC)

I *think* I know why the current homepage here is not visible to anonymous users. I could access to two of the panels that builds it and the visiblity policy was set to "All Users" -- now it's "Public". I could not access to edit W3 but I suspect the situation will be the same there. If that panel i public all the rest of the homepage should be public as well. @Rush, can you edit W3 to confirm, please?

Rush wrote on 2014-08-26 22:22:41 (UTC)

@Qgil, fixed?

http://fab.wmflabs.org/

qgil wrote on 2014-08-26 22:29:23 (UTC)

Yep! Except now we know that "My Tasks" is not a suitable panel for a homepage visible to all users. Good for testing.

aklapper wrote on 2014-08-27 01:54:36 (UTC)

In T64#27, @Qgil wrote:

If nobody objects to this idea, I will implement it here in fab to test it out.

I'm late to comment here, but sure, please test.

In T64#31, @Qgil wrote:

I *think* I know why the current homepage here is not visible to anonymous users. I could access to two of the panels that builds it and the visiblity policy was set to "All Users" -- now it's "Public".

For the records, this was also kind of brought up in T397.

qgil wrote on 2014-08-27 07:06:38 (UTC)

I'm experimenting with acl*Batch-Editors as we speak. Have a look at http://fab.wmflabs.org/maniphest/task/create/ to see how simple is the interface for regular users. Then you can join acl*Batch-Editors to get the extra fields back.

Two things:

1. Currently All Users can join acl*Batch-Editors with their own feet, but according to previous discussions (EditBugs in Bugzilla) the desired scenario is that team members can invite new members. We can do this in the production site if we want, but leave it here as it is in order to bootstrap the team quicker.
2. I wonder how can we set the policy so "All Users" can't edit custom fields either. Now it's odd that they can edit "Points", a custom field that will certainly confuse most new/casual users. Then again, I think we decided not to implement any custom field in the production site by Day 1, so this might be not urgent at all.

aklapper wrote on 2014-08-27 12:30:23 (UTC)

In T64#35, @Qgil wrote:

Have a look at http://fab.wmflabs.org/maniphest/task/create/ to see how simple is the interface for regular users.

Looks lovely and clean, and would fix T415.

But I cannot edit neither priority nor status of a task anymore. I guess I'd have to join acl*Batch-Editors first. Not being able to edit the status of a report though you are the author/reporter.... not sure if I like that. :-/

(Plus wondering why e.g. T146 has a Priority value of 0 now, maybe not related.)

I wonder how can we set the policy so "All Users" can't edit custom fields either.

Now it's odd that they can edit "Points", a custom field that will certainly confuse most new/casual users.

I've removed the "Points" custom field in fab.wmflabs.org now by disabling it in maniphest.fields. As long as we miss T244 etc. we won't have a Points custom field in production.

I think we decided not to implement any custom field in the production site by Day 1, so this might be not urgent at all.

We will have an extID custom field for mapping task IDs (and redirect URLs) between BZ/RT and Phab. It would be lovely if it was read-only but last time I talked to @Rush he said that's not easily doable, IIRC.

qgil wrote on 2014-08-27 14:51:43 (UTC)

In T64#39, @Aklapper wrote:

But I cannot edit neither priority nor status of a task anymore. I guess I'd have to join acl*Batch-Editors first. Not being able to edit the status of a report though you are the author/reporter.... not sure if I like that. :-/

If you are unsure-unsure then we can make Status editable to All Users as it was before.

If you are just unsure, ;) maybe @mmodell's work for the Security case can be somehow recycled here: "a user cannot edit the status of a task unless s/he is meber of acl*Batch-Editors OR AUTHOR OF THE TASK".

If you are just a little bit unsure, I'd say let's wait and listen to users. Reverting is easy.

(Plus wondering why e.g. T146 has a Priority value of 0 now, maybe not related.)

Interesting. It's an Unbreak_Now!

Rush wrote on 2014-08-27 16:45:51 (UTC)

T146 shows normal priority for me, did someone change it? When we killed the 'wishlist' priority we could have left some orphans (wishlist was numerically 0 )

Rush wrote on 2014-08-27 16:55:27 (UTC)

On thing I want to make sure to keep in mind is if someone has the abillity to edit the security of tasks they definitely should be part of the group who have NDA access to RT. It's too tricky to piecemeal this out over time while keeping in mind every group that could accidentally get access to NDA specific data. The inclusion of RT into this phab universe adds that restriction unfortunately.

aklapper wrote on 2014-08-27 19:02:07 (UTC)

@Qgil: Not being in acl*Batch-Editors and trying to create a ticket here, Chase and I get:

Access Denied: Application Maniphest
You do not have permission to edit task status.

So let's revert this for the time being as it's interrupting actual work?

qgil wrote on 2014-08-27 19:58:52 (UTC)

The problem was specifically the policy to change the status of a task, probably because of a side-effect / potential bug. Since Andre wasn't convinced about restricting this policy to acl*Batch-Editors, now it has been set back to All Users.

Editing Priority and Assigned is still restricted to acl*Batch-Editors, and the form to create/edit tasks plus the drop down menu in comments looks still very clean. Problem solved.

qgil wrote on 2014-08-29 08:53:43 (UTC)

This looks good to me. Reassigning to @Rush -- he can decide whether this task can be resolved now.

qgil wrote on 2014-09-01 17:03:02 (UTC)

While I agree with the idea that Administrators need NDA and be a very selective club (that wouldn't accept someone like me as a member), I think it is good that content related tasks like defining the homepage are handled by a wider or just a bit more relaxed group. One option would be to assign these permissions to the Phabricator team, and remove #phabricator-project-request.

Rush wrote on 2014-09-02 16:31:50 (UTC)

In T64#53, @Qgil wrote:

While I agree with the idea that Administrators need NDA and be a very selective club (that wouldn't accept someone like me as a member), I think it is good that content related tasks like defining the homepage are handled by a wider or just a bit more relaxed group. One option would be to assign these permissions to the Phabricator team, and remove #phabricator-project-request.

yep makes sense, there are really two generic kinds of rights. Teh right to 'grant rights' which needs to very limited and subject to audit, and the right to say, change status on a task which is still auditable but has less potential to lead to an issue. Janitorial stuff I'm totally down with being a self determination kind of deal, and have no real wisdom for, other than to say that it needs to be looked at from a security perspective on how it may overlap and cause issues for the security work.

btw, your nda'd up like a boss dude. you can't go back now.

qgil wrote on 2014-09-07 08:28:26 (UTC)

In T64#39, @Aklapper wrote:

I've removed the "Points" custom field in fab.wmflabs.org now by disabling it in maniphest.fields.

I just created T646: Set up project filters because at least one team seems to miss it.

Can I has admin permissions only to recreate the ones we had in fab for Triagers, dashboards, and etc? I will bring them back once I'm done, probably in a couple of days.

In T39#31, @Qgil wrote:

Can I has admin permissions only to recreate the ones we had in fab for Triagers, dashboards, and etc? I will bring them back once I'm done, probably in a couple of days.

I am done with permissions and dashboards. Being member of phabricator.wikimedia.org should be enough to do what I need to do. You can remove the admin role. Thanks!

Questions / comments before documenting.

There is an apparent mismatch between the description of this task and the current implementation. This is not urgent, and I will tie this task to the RT and Bugzilla migration projects, because the current situation is fine for the production instance.

security-bug: 'Security or Sensitive Bug'
Anyone in the Security group in Bugzilla

ok

ops-access-request: 'Operations Access Request'
Anyone in Ops for WMF

ok

ops-procurement: 'Operations Procurement'
Anyone in Ops for WMF

Is this "Operations Sensitive"? Many users with a sensitive issue in hand will have a difficulty discerning between "Sensitive Bug" and "Operations Sensitive". Can we keep "Operations Procurement", which is a lot clearer?

sensitive: 'Another Private Issue'

What is this and who can access it? It sounds like a second catch-all after "Security or Sensitive Bug"

Operations-NDA:

(humans) - ops-access-request visible only(?)
anyone who has signed an NDA and can see RT stuff now.
We may leave out the ops stuff at the outset to not confuse as RT will still be in place.

I guess this piece of the description is not implemented yet? Or is this the 'Another Private Issue'?

For now only two matter:

None -- will make no settings
Private Issue -- sets things to only 'security group'

The rest won't come into play until more external systems are integrated.

Should the 'security group' aligned with the membership of the Security project?

Pretty much my intention, I just don't know if everyone in that group in bugzilla has an NDA...if not we may need to do two groups (1 for security bugzilla, 1 for security rt). It really comes down to _who_ the actual members are and if it's all overlap. I haven't gotten a chance to compare notes on that. But yes, essentially.

In T39#8403, @chasemp wrote:

Pretty much my intention, I just don't know if everyone in that group in bugzilla has an NDA...

Yes, I made sure earlier this year that everybody who is a member of the Security group in Bugzilla has either an NDA signed (being not a WMF employee) or is a WMF employee (and at least my contract with WMF has a section called "Confidential Information" if that counts as something NDA'ish).

do you want me to attach a private P with a list of all members of the BZ security group?

In T39#14113, @Dzahn wrote:

do you want me to attach a private P with a list of all members of the BZ security group?

I think I already did so in a private email to Chase, but if needed again I could also provide that. Whatever's needed.

Does this task need to wait for the migration? It looks like it could be completed before.

This task has changed somewhat in scope as time as gone on, which probably makes it hard to follow.

For RT we have simplified our use-case and have gone the route of WMF-NDA . Any one who has the right NDA / sensitive information privs we say can view RT tickets. They are going to be given that trust, etc.

It seems like the most straight forward approach would be to make this same group able to view Security tickets from BZ if @Aklapper and @csteipp think it is reasonable. It seems like this would simplify things overall, not reveal anything to anyone who isn't already capable of viewing equivalent information, and be more true to our overall philosophy.

thoughts?

This would simplify things indeed. For the records, everybody in Bugzilla's Security group has an NDA (and two members are not staff). Happy to go that route if @csteipp is fine with that definition/scope of access to Security reports in our issue tracker.

In T39#21656, @chasemp wrote:

It seems like the most straight forward approach would be to make this same group able to view Security tickets from BZ if @Aklapper and @csteipp think it is reasonable. It seems like this would simplify things overall, not reveal anything to anyone who isn't already capable of viewing equivalent information, and be more true to our overall philosophy.

This goes against the security principle of Least Privilege [https://en.wikipedia.org/wiki/Principle_of_least_privilege], and I think is going to make our lives harder in the future. It either means we're going to have contractors with less-than-desirable security practices have access to our security / ops bugs, or someone is going to have to make a judgement call each time a user is added to this group whether we trust them to have access to everything. That's going to make it harder for me to give out access to volunteers, and I'd likewise want to vet anyone ops is giving their access too as well. We really need compartmentalization.

If the issue is just keeping the security bugs group up to date, I'm happy to take that on. If there are larger technical issues, can someone summarize exactly what they are?

Nope, no technical limits that I know of. For awhile the conversation of whether to merge the group of people who have signed NDA's for access to operations tickets and the group of people who can view security bugs has been popping up. So per this I will say -- Security is a group who's members are distinct from WMF-NDA . This is totally cool with me. I have made Security a group who's members are managed by @csteipp and administrators (though that's mainly for bus factor and none of us are going to do so in the course of regular business). Security-* tickets from BZ will be assigned to Security/Security in Phab and from there I leave it to you knowing BZ peoples (@Aklapper and @csteipp) to do your thing.

thoughts?

In T39#24388, @Aklapper wrote:

@csteipp and/or admins can add currently-still-missing members to the group after account verification.

I added several people based off their commits (I think those are based on their confirmed email addresses matching the gerrit owner). I'll ping the rest.

@csteipp: Thanks, but note that I've also already sent direct emails to those people asking them to verify their accounts after Chad told me that not everybody is on the sec@ mailing list.
Just saying, don't want to bomb people too much :)