Hide Forgot
Hello, I'd like to ask you to do following modification in Bugzilla: Decouple "Doc Type" & "Doc Text" fields. - current status: if you need to change the "Doc Type" to a different value, you must also adjust "Doc Text" field. Without "Doc Text" adjustment your changes in "Doc type" will not be saved. - "decoupling" means to not require changes in "Doc Text" to save changes in "Doc Type" This change was approved by ECS & RHEL development team Please let me know if more details are needed. Can you please let me know what is expected time frame when this can be implemented in live bugzilla? thank you! Libor
Tested on QA environment(bzperfweb01.app.qa) with version(4.4.11050-5, DB: pgsql) Result: Fail 1. Create a bug, then select 'Known Issue' for Doc_type, save ==>The user 'Red Hat Bugzilla' will change doc_type back to the default 'If docs needed, set a value' Rony Gong 2016-04-18 14:34:08 CST Doc Type: If docs needed, set a value → Known Issue Red Hat Bugzilla 2016-04-18 14:34:08 CST Doc Type: Known Issue → If docs needed, set a value
What's happening here is that the text in the 'Doc Text' field has not been changed from the default text. Therefore bugzilla is changing the Doc Type back. For Example: Doc Type: If docs needed, set a value. Doc Text: If this bug requires documentation, please select an appropriate Doc Type value. If you now change the Doc Type to Enhancement and do not change the Doc Text, bugzilla will reset the Doc Type back to 'If docs needed, set a value'. Example 2 Doc Type: Bug Fix Doc Text: Hello World. If you then change the Doc Type to Enhancement, the Doc Type change will work, because the Doc Text is not the default, even though the Doc Text has not changed. I think it makes sense to leave this behaviour as is, otherwise we will have the situation where someone can accidentally misclick and set: Doc Type: Enhancement Doc Text: If this bug requires documentation, please select an appropriate Doc Type value. Which IMO doesn't make sense. Libor, Is this behaviour OK with you and your team?
Hi Matt, (In reply to Matt Tyson from comment #2) > What's happening here is that the text in the 'Doc Text' field has not been > changed from the default text. Therefore bugzilla is changing the Doc Type > back. > > For Example: > > Doc Type: If docs needed, set a value. > Doc Text: If this bug requires documentation, please select an appropriate > Doc Type value. > > If you now change the Doc Type to Enhancement and do not change the Doc > Text, bugzilla will reset the Doc Type back to 'If docs needed, set a value'. > The docs team need also example 1 to retain the changed Doc Type. The actual text does not matter, the requires_doc_text flag will be set to "?" anyway, so writers know the change is not final and will follow up. Typical use case: Engineers indicate candidates for Release Notes by setting the "Release Note" Doc Type but are not ready to provide details in Doc Text. Writers will follow up and no information is lost. > Example 2 > > Doc Type: Bug Fix > Doc Text: Hello World. > > If you then change the Doc Type to Enhancement, the Doc Type change will > work, because the Doc Text is not the default, even though the Doc Text has > not changed. Has this change been implemented recently? I can remember many cases when we had to change an already edited text just because of changing the Doc Type. And then had to restore the original text. > > I think it makes sense to leave this behaviour as is, otherwise we will have > the situation where someone can accidentally misclick and set: > > Doc Type: Enhancement > Doc Text: If this bug requires documentation, please select an appropriate > Doc Type value. > > Which IMO doesn't make sense. > To sum it up, please don't let BZ change the Doc Type back in any case.
(In reply to Lenka Spackova from comment #3) > Has this change been implemented recently? I can remember many cases when we > had to change an already edited text just because of changing the Doc Type. > And then had to restore the original text. No, this code dates back to 2012. > To sum it up, please don't let BZ change the Doc Type back in any case. Easy enough.
The Doc Text value always set as 'undefined', no matter which doc_type you chose. Check https://bzperfweb01.app.qa.eng.nay.redhat.com/show_bug.cgi?id=1277666
(In reply to Matt Tyson from comment #4) > (In reply to Lenka Spackova from comment #3) > > Has this change been implemented recently? I can remember many cases when we > > had to change an already edited text just because of changing the Doc Type. > > And then had to restore the original text. > > No, this code dates back to 2012. I'm afraid it doesn't work as you think. See Bug 1246539 I tested right now: Existing text is correct, trying to set the Doc Type to "Release Note". This is displayed below the Doc Type: "Doc Text must also be changed to save" And after saving: Lenka Spackova 2016-04-20 06:00:00 EDT Doc Type: Bug Fix → Release Note Red Hat Bugzilla 2016-04-20 06:00:00 EDT Doc Type: Release Note → Bug Fix Please adjust this behavior so that BZ does not revert the change.
(In reply to Rony Gong from comment #5) > The Doc Text value always set as 'undefined', no matter which doc_type you > chose. > > Check https://bzperfweb01.app.qa.eng.nay.redhat.com/show_bug.cgi?id=1277666 This is not what we wanted. We want the original texts to be displayed (with a guidance of what type of information we need). At least for the first time, ideally always - as long as the default text does not overwrite any human-provided text. Another live example - Bug 1325145 Doc Type set to the current default: Bug Fix, showing the default text: Cause, Consequence, Fix, Result. Trying to change the Doc Type to "Release Note", doc text is changed to "A Release Note should describe...", which is what we want. But again, I get this message below the Doc Type: "Doc Text must also be changed to save" And again: Lenka Spackova 2016-04-20 06:13:33 EDT Doc Type: Bug Fix → Release Note Red Hat Bugzilla 2016-04-20 06:13:33 EDT Doc Type: Release Note → Bug Fix We are losing information by this behavior. If you can preserve the default doc texts tied to individual doc types, that would be great and very helpful. There is no need to decouple the default pre-filled texts. To sum it up: 1. Don't let BZ ever to revert any change in Doc Type 2. Don't let BZ change or force change in any human-provided text 3. Keep the original pre-filled texts according to the Doc Type (bug fix: Cause-Consequence-Fix-Result, enhancement: Feature-Reason-Result...) I hope it is clear now. Thanks to everybody involved!
(In reply to Lenka Spackova from comment #6) > I'm afraid it doesn't work as you think. See Bug 1246539 I tested right now: > > Existing text is correct, trying to set the Doc Type to "Release Note". This > is displayed below the Doc Type: > "Doc Text must also be changed to save" > > And after saving: > Lenka Spackova 2016-04-20 06:00:00 EDT > Doc Type: Bug Fix → Release Note > Red Hat Bugzilla 2016-04-20 06:00:00 EDT > Doc Type: Release Note → Bug Fix > > Please adjust this behavior so that BZ does not revert the change. I was talking about a partially modified behaviour on my dev machine. I was not describing the current production environment. (In reply to Rony Gong from comment #5) > The Doc Text value always set as 'undefined', no matter which doc_type you > chose. > > Check https://bzperfweb01.app.qa.eng.nay.redhat.com/show_bug.cgi?id=1277666 This is happening because you don't have the latest version of config.yaml.
Tested on QA environment(bzperfweb01.app.qa) with version(4.4.11050-7, DB: pgsql) Result: Pass Steps: 1.Create a bug, then select doc type to other, save ==>The doc type could save well and no change back ==>The doc text value associate changed with the doc type 2.Then only update doc text, save ==>doc text save well ==>no change to doc type 3.Then select doc type to other ==>doc text no change 4. Save this bug ==>doc type could change to new value ==>doc text no change since no update to doc text.
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.