686184 - Adding "Planning" Component in Mozilla Reps Product

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[Pierros Papadeas [:pierros]]

We are trying to use bugzilla more and more for our planning and deploying purposes. Would be lovely to have a component named "Planning" in Mozilla Reps product so we can keep track of what is happening as we move forward.

Default assignee should be me.

Thanks!

Comment 1

[David Lawrence [:dkl]]

Let me have a brief description for the component and I will get it set up.

dkl

Comment 2

[Pierros Papadeas [:pierros]]

Bugs related to the deployment of Mozilla Reps infrastructure. More info: https://wiki.mozilla.org/ReMo/Planning

Comment 3

[David Lawrence [:dkl]]

done

Comment 4

[Majken Connor [:Kensie]]

Hi all, it seems this component isn't accessible to anyone outside ReMo admins. Users in the mozilla-reps group can't see them even with the box checked. IMO this component should be completely public, but I'll defer to pierros.

Comment 5

[David Lawrence [:dkl]]

(In reply to Majken "Lucy" Connor from comment #4)
> Hi all, it seems this component isn't accessible to anyone outside ReMo
> admins. Users in the mozilla-reps group can't see them even with the box
> checked. IMO this component should be completely public, but I'll defer to
> pierros.

Not sure where you are getting the access issue. The product Mozilla Reps is configured to be publicly submittable but that the mozilla-reps groups is mandatory to be checked so the resulting bug is not public. Are you saying that bugs already filed under the Planning component are not visible to you even though you are in the mozilla-reps groups?

dkl
dkl

Comment 6

[Majken Connor [:Kensie]]

They are visible to me as I'm in the extra special group. I tried sharing some bugs with some people who are in the Mozilla-reps user group and they could not see the bug whether the box was checked or not checked.

I understand the budget/swag/applications components are set up so that only certain people can submit them (applications being submittable by all) and then they're set up so that only certain people can view them. I think the planning component should be entirely public, though at the very least people in the mozilla-reps group should be able to view them.

Comment 7

[David Lawrence [:dkl]]

(In reply to Majken "Lucy" Connor from comment #6)
> They are visible to me as I'm in the extra special group. I tried sharing
> some bugs with some people who are in the Mozilla-reps user group and they
> could not see the bug whether the box was checked or not checked.
> 
> I understand the budget/swag/applications components are set up so that only
> certain people can submit them (applications being submittable by all) and
> then they're set up so that only certain people can view them. I think the
> planning component should be entirely public, though at the very least
> people in the mozilla-reps group should be able to view them.

Ah I see what is happening now. Currently the groups are configured as so:

Group                 Member/Non-Member
infra:                Shown/NA
mozilla-reps:         Default/Mandatory
mozilla-reps-admins:  Mandatory/Mandatory 

So in this case both mozilla-reps and mozilla-reps-admins is enabled for any bugs under the Mozilla Reps product by default. BMO policy currently is that a person must be a member of all groups checked to see a bug so if both m-r and m-r-a are checked you must be in both. So
in this case someone only in m-r cannot see it. We should probably rethink this if this is becoming an issue for a lot of people. This was how it was originally configured when the new product was created. In the meantime you can work around this by adding the person you want to see the bug to the cc list which will allow them to see.

Pierre, thoughts?
dkl

Comment 8

[Pierros Papadeas [:pierros]]

The Swag, Budget and Mentorship components should stay as-is.

The planning bug should become publicly accessible, totally open. Is this possible?
If yes, then please go ahead and implement this. Thanks!

Comment 9

[David Lawrence [:dkl]]

(In reply to Pierros Papadeas from comment #8)
> The Swag, Budget and Mentorship components should stay as-is.
> 
> The planning bug should become publicly accessible, totally open. Is this
> possible?
> If yes, then please go ahead and implement this. Thanks!

Dont think that is possible as Bugzilla performs permissions based on the product and not individual components. So we would need to think of a scheme that works for the product as a whole.

dkl

Comment 10

[Pierros Papadeas [:pierros]]

(In reply to David Lawrence [:dkl] from comment #9)
> (In reply to Pierros Papadeas from comment #8)
> > The Swag, Budget and Mentorship components should stay as-is.
> > 
> > The planning bug should become publicly accessible, totally open. Is this
> > possible?
> > If yes, then please go ahead and implement this. Thanks!
> 
> Dont think that is possible as Bugzilla performs permissions based on the
> product and not individual components. So we would need to think of a scheme
> that works for the product as a whole.
> 
> dkl

This would be kinda tricky I guess, right? How about creating a new product? Far stretched?

Comment 11

[Majken Connor [:Kensie]]

Can we have the product open, and have the submission forms (https://bugzilla.mozilla.org/form.reps.budget) set to check the groups off so that it gets filed as closed?

Comment 12

[David Lawrence [:dkl]]

(In reply to Majken "Lucy" Connor from comment #11)
> Can we have the product open, and have the submission forms
> (https://bugzilla.mozilla.org/form.reps.budget) set to check the groups off
> so that it gets filed as closed?

That can be done yes. We do that now in other custom entry forms. We would need to remove the mandatory restrictions on the current groups which means that they could be removed later by someone unintentionally (someone in the group) where mandatory means it cannot be removed at all.

We can also set the form up where people not in any of the groups can always file a bug into the group such as mozilla-reps without being mandatory. We do this in the code as we need it for security bugs for most products. Non-members will still be able to see the report they themselves filed even with the group checked since they are the reporter. Just not other reports they did not.

dkl

Comment 13

[Majken Connor [:Kensie]]

I don't think we need to worry about people accidentally unchecking the boxes obviously it's more ideal that they can't be unchecked, but I think people in the approved groups will understand why the boxes are checked. I'm not sure how the boxes work though. Can anyone who is cc'ed change them, or do you have to be in one of the special groups?

For the applications bugs, we do have people who aren't in the special groups able to fill out the form of course, cuz they're not in the group until they've been accepted. For the budget and swag requests we want it to be only people in the mozreps group who can file those, since only approved reps are allowed to have these.

Comment 14

[Dave Lawrence]

Sorry for the delay. Hopefully I can see this through now.

Here is my proposal:

1. Remove the mandatory requirements for the Mozilla Reps product for the groups currently set to Mandatory. So it would be:

Group                 Member/Non-Member
infra:                Shown/NA
mozilla-reps:         Default/NA
mozilla-reps-admins:  Default/NA

2. Change the Swag/Budget/Mentorship forms required the mozilla-reps group to view the form and also have the groups automatically checked by default when the new bug is created.

3. To enter a Planning bug they would just go to the normal bug entry page where they can enter a bug without needing to be in any of the above groups. They would just choose the Planning component from the list. 

One issue is that they could in turn choose the other components from the standard entry page as they will not be hidden away. Only the custom forms will be protected by the group perms. But this has been the case already for the other components up until now so nothing is different there.

The alternate proposal follows:

1. Make the current Mozilla Reps product completely private to the mozilla-reps group which would be required to enter a bug for the standard form or the custom forms. 

2. Create a new Mozilla Reps Planning product which has no restrictions and anyone can enter a bug to it. Have a single component initially called General.

Downside would be that two products would need to be watched and having both could cause confusion on which to use for a new user.

Thoughts
dkl

dkl

Comment 15

[Majken Connor [:Kensie]]

Those do seem like the options! Not to pile on, but there'll also be a dev component which should also be public, if that makes a difference either way. It does help justify a separate open component, but also justifies even more needing to open up the current component if we don't split it.

I think we're already following based on the separate components anyway (I certainly don't check all the requests coming through, only the ones I'm cced on!) so I don't think that's extra pain there. It also allows us to actually restrict the forms, so it seems separate components is the "best" of the two current possibilities in terms of controls. Especially since you have to be in the groups to see the current component anyway.

If there aren't organizational issues with having 2 components on your end, then I guess that's my vote!

Comment 16

[David Lawrence [:dkl]]

(In reply to Majken "Lucy" Connor from comment #15)
> Those do seem like the options! Not to pile on, but there'll also be a dev
> component which should also be public, if that makes a difference either
> way. It does help justify a separate open component, but also justifies even
> more needing to open up the current component if we don't split it.

So the new public product should have a more general name then and have "Planning" 
and "Development" components under it, I would think. You wouldn't want to create
a new product for each new component. So we can just have two products, public
and private, aptly named.

Pierros, objections?

dkl

Comment 17

[Pierros Papadeas [:pierros]]

We should not break down the products :(

I would suggest to go with the first proposal and we can deal with any misdirected bugs (not being filled through the forms)

dkl can you proceed on this?

Thanks!

Comment 18

[David Lawrence [:dkl]]

I have checked in minor changes to the form templates to support this request that will be in the next code push. Hopefully in the next day or so. Once the changes are live I can 
remove the mandatory bits from the mozilla-reps and mozilla-reps-admins groups for the Mozilla Reps product. Then we can close this out I think.

dkl

Comment 19

[:glob ✱]

these changes are now live.

Comment 20

[David Lawrence [:dkl]]

I have updated the permissions to 

infra: Shown/NA
mozilla-reps: Default/NA
mozilla-reps-admins: Default/NA 

The specialized forms will put the new bugs into the mozilla-reps and mozilla-reps-admins groups upon submit similar to before. For the standard bug entry form, the 'Default' setting will also put the new bugs into the groups by default unless the user manually unchecks them.

So I think this request can be closed out now.

dkl

Comment 21

[Pierros Papadeas [:pierros]]

Thanks a lot :) Let's hope that this setup will serve us all best.