Can someone please provide me some more information about the change requested here?

On second thoughts, is this bug really a dependency of 583097? If it is, I'll need more information so I know what to change. If not, we can remove the dependency.

  -- simon

Jira allows the maintainer for that section to update fields after the bug has been created without having to get a jira admin to do anything. Eg to change an affects version, change a fixed in version, update any links to other bugzillas, re-assign it, change components etc.

If any field in say a SOA bugzilla requires someone outside of the SOA team to make changes then this issue is not resolved.

Bugzilla is a much more relaxed about who can update bugs.. Anyone with the editbugs group flag[1] (which is given as part of the internal 'Red Hat' group) can edit any aspect of bugs.

I'm therefore going to mark this bug as ON_QA for you to confirm that you have enough permission to make the changes as required.

If you do, please mark this bug as VERIFIED. If you don't, please let me know what bug you were trying to edit, who you logged in as, and what you could not change.

  -- simon


[1] providing that they also have enough permissions to view the specific bug in the first place.

In my testing to test alter any of the fields already set when the issues was created working with https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=666028
I found the updates of data on previously set fields to be working.

On a side note, and maybe a completely separate bug, both Trevor and I find it disturbing that one can enter garbage in the "Fixed In Version" field and there is no data validation.  Middleware uses the "Fixed In Version" pretty religiously.

<mharvey> Do you use "Fixed In Version" in bugzilla?
<jkt> Sometimes.  We have been trying to drive use of that field but are having a tough time with adoption.
<mharvey> The current implementation seems a little scary..
<mharvey> Do you have a problem with the fact that "Fixed In Version" is a free form field and performs  no data validation to make sure the version entered is valid version?
<mharvey> Maybe not since adoption is not good..
<jkt> Indeed that has been part of the problem.  Some team are using the field to indicate which build a fix is present in, some use it to specific the exact package version, etc.
<jkt> I'm hoping that once we get the messaging systems hooked up, that field can inherit some data validation and be used to trigger all sorts of stuff down the line.

The editing works so I'll mark it as resolved. As for the related issue, fixed in fields are core to the way we use jira. Having garbage in there will probably have a severe impact and cause lots of problems

Reopened as the fix is not complete.


I'm not able to edit nor description nor comment fields.

According to requirement 1.2.2 description from https://engineering.redhat.com/trac/bugzilla/wiki/JiraMigrationRequirements, this was not met.

Use case for how editing of the descriptions and comments is necessary:

I have a bug with description and 46 comments. I have to go through 46 comments to have complete description, #1 say something is this way, where #14 says that something will be that way. Comment #36 says it will be the other way and comment #44 say all the ways were wrong, it should be a different way. Same for typos, deprecated links, etc.

(In reply to comment #9)
> Use case for how editing of the descriptions and comments is necessary:

This is not going to happen. The Red Hat development team have survived without being able to edit comments for many years. While I understand your use case, this isn't a reason to allow a free-for-all editing of existing comments and descriptions.

Only the Red Hat Bugzilla admins have the permissions to edit comments. This is only done in the most extreme circumstances (I've done it only once this year).

  -- simon