Bug 498735

(In reply to comment #0)
>
> It would be easier to remember to add the futurefeature keyword if there was a
> place to enter it when initially submitting a bug.

Isn't this possible, now?

When I enter a bug, I do see a Keywords field present (I haven't tried to submit a bug just to see if futurefeature can be used but I don't see what could you from doing so).

I don't see it on the initial screen. It's there after I submit the bug. I tested with javascript on (normally I have it off). This is with redhat's bugzilla (https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora) and might not be the normal case for random bugzillas. (In which case it's really an infrastructure problem.)
Maybe I am missing an entry box somewhere, but I had done a search in firefox for the string key on the page and that didn't find anything.

Created attachment 342224 [details]
Segment of the bug entry page that should contain the keywords field

(In reply to comment #2)
> I don't see it on the initial screen. It's there after I submit the bug. I
> tested with javascript on (normally I have it off). This is with redhat's
> bugzilla (https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora)

That's what I thought from the 'futurefeature' keyword.

> and might not be the normal case for random bugzillas.

There are three possibilities here:

a) the Bugzilla instance has been modified to remove the keywords fields during bug entry.
b) the reporter does not have the editbugs right for the product he is entering a bug against
c) no keywords have been defined

> Maybe I am missing an entry box somewhere, but I had done a search in firefox
> for the string key on the page and that didn't find anything.  

Screenshot attached.

Created attachment 342237 [details]
Saved html from the page

I have attached the html page I get. I searched it for keyw and only found a hit for a perl application. I didn't attach some of the dependent css and js files as I don't think they are likly to be an issue.
I was detected as being logged in.

(In reply to comment #4)
> 
> I have attached the html page I get.

You don't have editbugs capabilities.

At this point, I feel more comfortable filing the bug against the Bugzilla product. I suspect RH's Bugzilla team will be better able to explain why you don't have this right.

I don't know enough about bugzilla to say if this is a configuration issue or a bugzilla itself issue. So assigning it the RH bugzilla team seems reasonable.

But there is still something odd about the design (at least as configured). If I can edit my bugs, I should be able to "edit" a bug I am about to create.

It is by design at least by the upstream developers. The Keywords field (along with blocks/dependson) is hidden to those who are not in the editbugs group for a particular product. In this case you need to be in the fedora_contrib permission group in order to edit the keywords field on bug creation. That would explain why some see it and some do not. Again this is not something Red Hat added in and is there from the upstream code. Please file the bug there at http://bugzilla.mozilla.org this is not satisfactory.

Dave

(In reply to comment #7)
>
> Please file the bug there at http://bugzilla.mozilla.org if
> this is not satisfactory.

Please don't. The default in upstream bugzilla is to have everyone given editbugs privileges (the "User RegExp" field is set to ".*"). Bruno does not have this right because Red Hat changed the upstream defaults to something else.

I have filed the enhancement request upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=491316

Even if redhat has changed the default config, there still seems to be an issue in that when creating bugs you should be treated as the owner (unless there is some config where you can report a bug and not start out as the owner) and should have the same privileges as the owner of the bug.
So I think this is really an upstream issue. They might still refuse to change things. However it seems that Redhat isn't interested in making a customization to allow this (given there is an annoying, but simple work around, and probably not a lot of demand).

(In reply to comment #9)
>
> I have filed the enhancement request upstream:

RESOLVED WORKSFORME.

(In reply to comment #10)
>
> Even if redhat has changed the default config, there still seems to be an issue
> in that when creating bugs you should be treated as the owner (unless there is
> some config where you can report a bug and not start out as the owner) and
> should have the same privileges as the owner of the bug.

The reporter never stop being the owner (actually, one of the owners) of a bug. These fields (and others) are conditional simply so that bug entry can be simplified for beginner reporters.

> So I think this is really an upstream issue. They might still refuse to change
> things. However it seems that Redhat isn't interested in making a customization
> to allow this (given there is an annoying, but simple work around, and probably
> not a lot of demand).

There is no customization required. All it takes is for someone from the admin group to access your account and give you the editbugs right manually instead of waiting for you to inherit it via group membership.

However giving me editbugs has security implications. It may well be that it is reasonable for someone to grant me that access.
It seems wrong that this feature is being used to simplify forms as well as control elevated access. Those should really be controlled by two separate knobs. The one that controls simplified forms should be settable by the user on their own.

I did reopen the ticket upstream, but my guess is they will close it WONTFIX.