While writing a new bug report¹⁾ and adding a patch immediately (by pressing the button labelled “Add an attachment”) one can not mark its Content Type as “patch”, whereas if adding a patch file after the initial post one sees “Content Type: If the attachment is a patch, check the box below.” among other options for marking the Content Type. I think, that check box should exist in the case of an initial post too (for sure for the type “patch”). Thank you, Kalten ¹⁾ https://bugs.freebsd.org/bugzilla/enter_bug.cgi
If you enable the "Show advanced fields" option at the top of the form, you can select patch type for the attachment.
Created attachment 146277 [details] Greasmonkey script (hack) activating advanced fields (In reply to Marcus von Appen from comment #1) > If you enable the "Show advanced fields" option at the top of the form, you > can select patch type for the attachment. Ah! Thank you! But non the less: it is not good to not show this option to set the Content Type of an attachment by default when writing the initial message in a thread but to show it when attaching a file in a reply. You should show that option at the initial posting too (or hardly anybody will load a patch up marked as such—and we lack the possibility to change the Content Type in a later step to correct it if I am not mistaken) BTW: As a very bad workaround to activate “Show advanced fields” on default one could use a Greasemonkey¹⁾ script like the attached one. (I hope it is not wrong to attache it here) ru, Kalten ¹⁾ https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
Ah! Splendid! While changing the css to a far more BSD like version, someone has set “Show advanced fields” as default now—by that, the problem happens to be solved. I take the liberty to colse this PR (as the one changing the interface seems not to have done it) ;-) ru, Kalten
There was no change in the interface. The "Show advanced fields" knob is still active for you, I think.
(In reply to Marcus von Appen from comment #4) > There was no change in the interface. The "Show advanced fields" knob is > still active for you, I think. Ah! In the html source there is a passage: ---8<--- TUI_alternates['expert_fields'] = 'Show Advanced Fields'; // Hide the Advanced Fields by default, unless the user has a cookie // that specifies otherwise. TUI_hide_default('expert_fields'); // Also hide the "Paste text as attachment" textarea by default. TUI_hide_default('attachment_text_field'); --->8--- and some sqlite3 cookies.sqlite .dump | grep "bugs.freebsd.org"|grep expert_fields in my profile dirctory of Mozilla shows INSERT INTO "moz_cookies" VALUES([…],'freebsd.org',0,0,'TUI','history_query=0&people_query=1&information_query=0&custom_search_query=1&custom_search_advanced=1&expert_fields=1&attachment_text_field=0&attachment_data=1','bugs.freebsd.org','/bugzilla/', […] when “Hide Advanced Fields” is shown (expert_fields=1) and changes more or less just expert_fields to =0 when “Show Advanced Fields” is shown. But I think, it did not remember such settings in a cookie when I started this PR ;-) (I am pretty sure I had tried to reload the page but it had changed back?) Well: I still think, it would be a good idea to enable the advanced fields by default. That it remembers my settings is nice. ru, Kalten
-1 on changing system wide default options at this early stage. This is exactly the purpose of user-preferences (which are nice, I agree) and unless a case can be made for a substantial benefit for the majority of stakeholders (users), then I'd prefer we limit adhoc, individual changes to our tracker settings and configuration until we have some specific goals/criteria defined to guide them.
Closing as 'overcome by events': 1) patches attached in enter_bug.cgi now recognized as patch by default, which I believe solves original problem 2) there is a configuration options that enables requested behavior and I second Kubilay's opinion that we should keep our fork as close to upstream as possible