Prefs Removal Proposal

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Prefs Removal Proposal

Gervase Markham
Here is a proposal for removing some prefs. Perhaps other people have
other ideas.

*Prefs to remove*

docs_urlbase: hardcode to "<urlbase>/docs" and make sure the built docs
are shipped in that location.

sslbase: hardcode to <urlbase> with s/http/https/.

proxy_url: Instead, use OS's mechanism for getting web content.

supportwatchers: hardcode to "on"

musthavemilestoneonaccept: just get rid of it; it's trivial to work around

commentonreassignbycomponent: don't see the point of this

usebugaliases: hardcode to "on"

Bug Moving: rip it all out; I bet it no longer works

mybugstemplate: the My Bugs link should be a saved search added to the
new account, and treated like one, rather than a special undeletable
link. This means it's not necessary for admins to be able to edit it.

*Other changes*

We need to move some prefs out of "Required Settings" which are
blatantly not required (and that's most of them).

We should also reorder some prefs pages (e.g. Auth) to have the prefs in
a more logical order.

Also, make some prefs only appear when necessary. E.g. the RADIUS
category should only appear when RADIUS is being used. Same for LDAP.
This would reduce complexity.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Jochen Wiedmann
On 8/29/07, Gervase Markham <[hidden email]> wrote:

> sslbase: hardcode to <urlbase> with s/http/https/.

Difficult. We've got to keep in mind, that it is very easy to have
virtual hosts for http, but not for https. I can very well imagine
that someone has different URL's.


> proxy_url: Instead, use OS's mechanism for getting web content.

What OS mechanism in the case of Linux/Unix? I have the *_proxy
environment variables set for my *personal* environment, but I prefer
if the httpd doesn't have them.

Jochen


--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Gervase Markham
Jochen Wiedmann wrote:
>> sslbase: hardcode to <urlbase> with s/http/https/.
>
> Difficult. We've got to keep in mind, that it is very easy to have
> virtual hosts for http, but not for https. I can very well imagine
> that someone has different URL's.

Let's assume that their HTTPS URL is:

https://bugzilla.foo.com/

What possible technical reason could there be for their HTTP URL _not_
to be:

http://bugzilla.foo.com/

?

>> proxy_url: Instead, use OS's mechanism for getting web content.
>
> What OS mechanism in the case of Linux/Unix? I have the *_proxy
> environment variables set for my *personal* environment, but I prefer
> if the httpd doesn't have them.

But the httpd can read Bugzilla's config file, so if you want Bugzilla
to be able to get update info, then the httpd does "have them" (in one
way or another).

"Either set up your OS to be able to access the web, or expect Bugzilla
not to be able to when running on it" seems like a reasonable position
to me.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Jochen Wiedmann
On 8/29/07, Gervase Markham <[hidden email]> wrote:

> Let's assume that their HTTPS URL is:
>
> https://bugzilla.foo.com/
>
> What possible technical reason could there be for their HTTP URL _not_
> to be:
>
> http://bugzilla.foo.com/
>
> ?

I can't think of any, so you might be right.



> "Either set up your OS to be able to access the web, or expect Bugzilla
> not to be able to when running on it" seems like a reasonable position
> to me.

Ok, you've got a point. :-) At least as long as the proxy access is
used for nothing else.


Jochen


--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Frédéric Buclin
In reply to this post by Gervase Markham
> proxy_url: Instead, use OS's mechanism for getting web content.

Many users reported problems about their proxy not being used correctly.
That's the reason we introduced it and I *really* see no reason to
remove this parameter.


> commentonreassignbycomponent: don't see the point of this

No reason to remove this one but leaving the other ones alone.


> Bug Moving: rip it all out; I bet it no longer works

It always worked correctly and still works fine.


> mybugstemplate: the My Bugs link should be a saved search added to the
> new account, and treated like one, rather than a special undeletable
> link. This means it's not necessary for admins to be able to edit it.

And how do you set the default one for new accounts without the ability
to define it in a parameter?


I remind you that this topic will be discussed at our next Bugzilla
meeting next Tuesday (Sept. 4th).

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Dave Williss
In reply to this post by Gervase Markham


Gervase Markham wrote:
> Here is a proposal for removing some prefs. Perhaps other people have
> other ideas.
>
> *Prefs to remove*
>
> musthavemilestoneonaccept: just get rid of it; it's trivial to work
> around
Trivial to work around how?

We don't want to force milestone on accept.  We *would* like to force
milestone when setting certain resolved states (FIXED and WORKSFORME but
not INVALID, NEEDINFO or WONTFIX).  Instead of using Target Milestone
for "when we want it done by" (as implied by the name *Target*
Milestone), we use it for "earliest version it was fixed in".

> commentonreassignbycomponent: don't see the point of this
My removing it, would it then force you to comment on reassign by
component or not?  I would hope not.  We do set the pref to force a
comment on normal reassign so the new assignee knows why they're getting
it, but changing the component tells them the component was changed
which should be enough explanation.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Gervase Markham
In reply to this post by Frédéric Buclin
Frédéric Buclin wrote:
>> proxy_url: Instead, use OS's mechanism for getting web content.
>
> Many users reported problems about their proxy not being used correctly.
> That's the reason we introduced it and I *really* see no reason to
> remove this parameter.

So instead of telling users to correctly configure their machines, we
provide an additional configuration mechanism?

>> commentonreassignbycomponent: don't see the point of this
>
> No reason to remove this one but leaving the other ones alone.

It seems more irrelevant than the others. I can see vague use cases for
them (although yes, of course, they are just as easy to work around).

>> Bug Moving: rip it all out; I bet it no longer works
>
> It always worked correctly and still works fine.

Really? Including classifications, for example?

Who uses this stuff these days?

>> mybugstemplate: the My Bugs link should be a saved search added to the
>> new account, and treated like one, rather than a special undeletable
>> link. This means it's not necessary for admins to be able to edit it.
>
> And how do you set the default one for new accounts without the ability
> to define it in a parameter?

We hard-code a default, which is the default we've been using for N
years now. As it's editable, people can always edit it if they don't
like it.

> I remind you that this topic will be discussed at our next Bugzilla
> meeting next Tuesday (Sept. 4th).

I must have missed that. Thanks :-)

Gerv

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Gervase Markham
In reply to this post by Dave Williss
Dave Williss wrote:
> Gervase Markham wrote:
>> Here is a proposal for removing some prefs. Perhaps other people have
>> other ideas.
>>
>> *Prefs to remove*
>>
>> musthavemilestoneonaccept: just get rid of it; it's trivial to work
>> around
> Trivial to work around how?

The usual method on b.m.o. is to put a single dot in the comment box.

>> commentonreassignbycomponent: don't see the point of this
> My removing it, would it then force you to comment on reassign by
> component or not?  I would hope not.

Not.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Frédéric Buclin
In reply to this post by Gervase Markham

> So instead of telling users to correctly configure their machines, we
> provide an additional configuration mechanism?

We provide something which works for all users who had problems with
their proxy. That's enough for me to keep it.


> It seems more irrelevant than the others. I can see vague use cases for
> them (although yes, of course, they are just as easy to work around).

Your workaround (adding a dot in a comment) is irritating. Better to
turn off the parameters in this case.


> Really? Including classifications, for example?

Irrelevant as the product automatically defines the classification the
bug belongs to.


> Who uses this stuff these days?

Probably not you. Not a reason to remove it, though. And e.g. Novell
uses it a lot, from what I heard.


> We hard-code a default, which is the default we've been using for N
> years now. As it's editable, people can always edit it if they don't
> like it.

And you still need a mechanism for this "special" saved search. Not very
helpful.


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Gervase Markham
Frédéric Buclin wrote:
>> It seems more irrelevant than the others. I can see vague use cases for
>> them (although yes, of course, they are just as easy to work around).
>
> Your workaround (adding a dot in a comment) is irritating. Better to
> turn off the parameters in this case.

You've missed my point. In installations where they _want_ this feature,
people who can't be bothered to provide the information can work around
the setting by putting a dot in the comment box. So why bother having
the setting anyway?

>> We hard-code a default, which is the default we've been using for N
>> years now. As it's editable, people can always edit it if they don't
>> like it.
>
> And you still need a mechanism for this "special" saved search. Not very
> helpful.

I don't understand your point here. My entire idea is that this saved
search is not "special" in any way. It's just another saved search. It
just happens to have been created automatically when you create the
account (i.e. one line of SQL in the account creation script) rather
than created by you. After that, it's managed the same way as any others
the user might create.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Dave Miller
Gervase Markham wrote on 8/29/07 2:31 PM:

> Frédéric Buclin wrote:
>>> It seems more irrelevant than the others. I can see vague use cases for
>>> them (although yes, of course, they are just as easy to work around).
>>
>> Your workaround (adding a dot in a comment) is irritating. Better to
>> turn off the parameters in this case.
>
> You've missed my point. In installations where they _want_ this feature,
> people who can't be bothered to provide the information can work around
> the setting by putting a dot in the comment box. So why bother having
> the setting anyway?

Someone who puts a . in the comment is obviously trying to get around
it, and can be socially engineered if people care about it.  For
installations that want it, the message you get with it completely blank
is a reminder for people who are forgetful, not an attempt at outright
enforcement.

>>> We hard-code a default, which is the default we've been using for N
>>> years now. As it's editable, people can always edit it if they don't
>>> like it.
>>
>> And you still need a mechanism for this "special" saved search. Not very
>> helpful.
>
> I don't understand your point here. My entire idea is that this saved
> search is not "special" in any way. It's just another saved search. It
> just happens to have been created automatically when you create the
> account (i.e. one line of SQL in the account creation script) rather
> than created by you. After that, it's managed the same way as any others
> the user might create.

You need a way for an admin to edit the query that gets created by
default on new accounts.  Once the account is created, it's all on the
user, but new account defaults should all be settable by the admin of
course.

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Max Kanat-Alexander
In reply to this post by Gervase Markham
On Wed, 29 Aug 2007 17:09:12 +0100 Gervase Markham <[hidden email]>
wrote:

> docs_urlbase: hardcode to "<urlbase>/docs" and make sure the built
> docs are shipped in that location.
>
> sslbase: hardcode to <urlbase> with s/http/https/.
>
> proxy_url: Instead, use OS's mechanism for getting web content.
>
> supportwatchers: hardcode to "on"
>
> musthavemilestoneonaccept: just get rid of it; it's trivial to work
> around
>
> commentonreassignbycomponent: don't see the point of this
>
> usebugaliases: hardcode to "on"

        Agreed, with all of these. (I have yet to read the thread below
this, I will soon.)

> Bug Moving: rip it all out; I bet it no longer works

        It does work, but I don't think it's used. I think importxml.pl
is used for other reasons.

> mybugstemplate: the My Bugs link should be a saved search added to
> the new account, and treated like one, rather than a special
> undeletable link. This means it's not necessary for admins to be able
> to edit it.

        That also makes sense.

        Also, "usermatchmode" should be set to "search" by default, and
we then only need to keep "confirmuniqueusermatch".

> Also, make some prefs only appear when necessary. E.g. the RADIUS
> category should only appear when RADIUS is being used. Same for LDAP.
> This would reduce complexity.

        The RADIUS and LDAP settings have to be set before they're
turned on, so that wouldn't work, currently.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Max Kanat-Alexander
In reply to this post by Dave Miller
On Wed, 29 Aug 2007 14:47:04 -0400 David Miller <[hidden email]>
wrote:
> You need a way for an admin to edit the query that gets created by
> default on new accounts.  Once the account is created, it's all on the
> user, but new account defaults should all be settable by the admin of
> course.

        That would be fairly easy to do with the User Preferences and
the Default Preferences.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Gervase Markham
In reply to this post by Max Kanat-Alexander
Max Kanat-Alexander wrote:
> The RADIUS and LDAP settings have to be set before they're
> turned on, so that wouldn't work, currently.

To be clear: what I mean was that, when RADIUS or LDAP are raised above
the "active" bar in user_verify_class, then the relevant links should
appear in the sidebar. (And a little message should appear telling you
to configure them.)

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Dave Miller
In reply to this post by Max Kanat-Alexander
Max Kanat-Alexander wrote on 8/29/07 3:21 PM:
> On Wed, 29 Aug 2007 14:47:04 -0400 David Miller <[hidden email]>
> wrote:
>> You need a way for an admin to edit the query that gets created by
>> default on new accounts.  Once the account is created, it's all on the
>> user, but new account defaults should all be settable by the admin of
>> course.
>
> That would be fairly easy to do with the User Preferences and
> the Default Preferences.

Doesn't really make sense to have it there actually.  Once the user has
it, it's in their save searches to edit.  There's no reason to make any
preference related to it visible to users, even if it is locked down
(it'll affect the creation of their account, once it's created, it's no
longer needed by their account).

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Dave Miller
In reply to this post by Max Kanat-Alexander
Max Kanat-Alexander wrote on 8/29/07 3:17 PM:
> On Wed, 29 Aug 2007 17:09:12 +0100 Gervase Markham <[hidden email]>
> wrote:
>> Also, make some prefs only appear when necessary. E.g. the RADIUS
>> category should only appear when RADIUS is being used. Same for LDAP.
>> This would reduce complexity.
>
> The RADIUS and LDAP settings have to be set before they're
> turned on, so that wouldn't work, currently.

Yeah, Max is right, here, unfortunately...  Maybe we need three-state
selectors for the auth methods... instead of just on and off, have on,
staging, and off, or somethign.  Off doesn't show the prefs, staging
shows the prefs but doesn't actually use them, and on actually uses them?

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Max Kanat-Alexander
In reply to this post by Dave Miller
On Wed, 29 Aug 2007 17:49:31 -0400 David Miller <[hidden email]>
wrote:
> > That would be fairly easy to do with the User Preferences
> > and the Default Preferences.
>
> Doesn't really make sense to have it there actually.  Once the user
> has it, it's in their save searches to edit.  There's no reason to
> make any preference related to it visible to users, even if it is
> locked down (it'll affect the creation of their account, once it's
> created, it's no longer needed by their account).

        Yeah, good point. We could just make it a Constant. The admin
can still edit that.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Dave Miller
Max Kanat-Alexander wrote on 8/29/07 7:43 PM:

> On Wed, 29 Aug 2007 17:49:31 -0400 David Miller <[hidden email]>
> wrote:
>>> That would be fairly easy to do with the User Preferences
>>> and the Default Preferences.
>> Doesn't really make sense to have it there actually.  Once the user
>> has it, it's in their save searches to edit.  There's no reason to
>> make any preference related to it visible to users, even if it is
>> locked down (it'll affect the creation of their account, once it's
>> created, it's no longer needed by their account).
>
> Yeah, good point. We could just make it a Constant. The admin
> can still edit that.

I like that idea.

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

John Beranek
In reply to this post by Gervase Markham
Gervase Markham wrote:

> Jochen Wiedmann wrote:
>>> sslbase: hardcode to <urlbase> with s/http/https/.
>>
>> Difficult. We've got to keep in mind, that it is very easy to have
>> virtual hosts for http, but not for https. I can very well imagine
>> that someone has different URL's.
>
> Let's assume that their HTTPS URL is:
>
> https://bugzilla.foo.com/
>
> What possible technical reason could there be for their HTTP URL _not_
> to be:
>
> http://bugzilla.foo.com/

Let's reverse that. Let's say that the site's SSL server is

https://secure.foo.com/

and they only have an SSL certificate for secure.foo.com

they wouldn't want to have to have Bugzilla live at
http://secure.foo.com/ but rather have, say,

https://secure.foo.com/bugzilla/

and

http://bugzilla.foo.com/

John.

--
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Prefs Removal Proposal

Joel Peshkin
John Beranek wrote:

> Let's reverse that. Let's say that the site's SSL server is
>
> https://secure.foo.com/
>
> and they only have an SSL certificate for secure.foo.com
>
> they wouldn't want to have to have Bugzilla live at
> http://secure.foo.com/ but rather have, say,
>
> https://secure.foo.com/bugzilla/
>
> and
>
> http://bugzilla.foo.com/
>
> John.
>
>  

The other way to deal with some of these uncommon prefs would be to
combine them.

For example, if URLBASE is "http://bugzilla.foo.com/" and SSL is
enabled, then SSLBASE is "https://bugzilla.foo.com/"

If, on the other hand URLBASE is set to "http://bugzilla.foo.com/ 
https://secure.foo.com/bugzilla/", (a list), then URLBASE and SSL BASE
differ by more than just the protocol field.

This would prevent adding extra fields for rare configurations at the
expense of making it a bit trickier for the few who need the less common
configuration.

I suspect that some fo the shadowdb parameters could be combined into a
one-liner as well.

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
12