Bug 619549 - 1.2.2 alter any of the fields set when the issue was created
1.2.2 alter any of the fields set when the issue was created
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: User Interface (Show other bugs)
3.6
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
trev
: Reopened
Depends On:
Blocks: JIRABZ
  Show dependency treegraph
 
Reported: 2010-07-29 15:34 EDT by David Lawrence
Modified: 2013-06-23 21:53 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-17 16:12:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2010-07-29 15:34:55 EDT
- dkl - Fields can be updated based on permission to update the field

High - tgk 

Solution: Use “related to” Dave to update the solution he discussed. There are a number of linking solutions supported by Bugzilla. Dave can describe each “link” solution and the correct usage of each solution. (related to, duplicate of, dependency, blocks, etc). Need to allow broader editing of comment content (not just admins).
Comment 2 Simon Green 2011-02-23 09:51:55 EST
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
Comment 3 trev 2011-03-25 11:42:07 EDT
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.
Comment 4 Simon Green 2011-04-04 03:06:01 EDT
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.
Comment 5 Mike Harvey 2011-05-04 13:47:03 EDT
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.
Comment 7 trev 2011-05-11 06:58:44 EDT
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
Comment 8 Karel Piwko 2011-11-09 03:03:08 EST
Reopened as the fix is not complete.


I'm not able to edit nor description nor comment fields.
Comment 9 Karel Piwko 2011-11-09 03:07:25 EST
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.
Comment 10 Simon Green 2011-11-17 16:12:59 EST
(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

Note You need to log in before you can comment on or make changes to this bug.