Description of problem: I can't find the check box "Attach as result" in "Create Another Attachment to Certification #xxxxxx" when I try to upload the second one. It should be there.
Created attachment 313935 [details] Patch Fix: template/en/default/attachment/create.html.tmpl : 1. Add permission control for this template,same as the "/bug/upload_packages.html.tmpl" (@@ -19,6 +19,7 @@ [% IF canedit && !isduplicate && bug.bug_status!='CLOSED' %] ) 2. Add the two checkboxes "attachasresult" && "md5sumoverride", same as the "/bug/upload_packages.html.tmpl". 3. Add rhr retire warning clearbox and related javascript, same as the "/bug/upload_packages.html.tmpl". 4.Remove the javascript setContentTypeDisabledState(), because it is not useful in our catalog, it was used in bz, for judging the attachment's content type,if the "is patch" checkbox checked.then disabled the content type: "auto-detect/select from list/enter manually". 5.@@ -61,7 +61,7 @@ change the attachment action from "edit" to "view". because "edit" was used by bz,it does not work in catalog, for example: https://hardware.redhat.com/attachment.cgi?bugid=457433&action=enter. If we click the link "313119: Add -ldl to linker options" , it will throw an error "Unknown action edit!". this is cause by catalog didn't use this feature and missing the related template. so change the action from "edit" to "view". pls reveiw and take a look at http://bugdev.devel.redhat.com/hwcert-xisun2/attachment.cgi?bugid=246680&action=enter Thanks a lot :) Best Regards! Nicho
perhaps it would be cleaner/less duplicate code to simply process the upload_packages.html.tmpl?
question, why is the attachment.cgi change needed? I wouldn't think we'd suddenly need all of the bug data? Obviously there's some form of recursion going on I presume from show.cgi we had some data that was needed which gets lost on the 2nd call to attachment.cgi?
[% canedit = bug.canedit || UserInGroup('hwcert_edit') ? 1 : 0 %] [% isduplicate = bug.bug_status == 'CLOSED' && bug.resolution == 'DUPLICATE' %] Above need the bug data for permission control. The bug data was lost when call attachment.cgi. If we don't have permission control, then vendor can upload the package via the link: https://hardware.redhat.com/attachment.cgi?bugid=457433&action=enter. Best Regards! Nicho
(In reply to comment #5) > [% canedit = bug.canedit || UserInGroup('hwcert_edit') ? 1 : 0 %] > [% isduplicate = bug.bug_status == 'CLOSED' && bug.resolution == 'DUPLICATE' %] > > Above need the bug data for permission control. > The bug data was lost when call attachment.cgi. > If we don't have permission control, then vendor can upload the package via the > link: https://hardware.redhat.com/attachment.cgi?bugid=457433&action=enter. > > Best Regards! > Nicho Adding the attachment.cgi's change is only for the blew case: Without that changes, if a cert was closed or a cert is duplicate cert (This case is not allow vendor upload packages.). When a vendor directly type the link:"https://hardware.redhat.com/attachment.cgi?bugid=457433&action=enter". Then the vendor can upload the package in that page. because: [% IF canedit && !isduplicate && bug.bug_status!='CLOSED' %] The bug data will lost because vendor directly call attachment.cgi. isduplicate will be '' and bug.bug_staus will be ''. Then the "upload_packages.html.tmpl" will be shown. Best Regards! Nicho
(In reply to comment #4) > question, why is the attachment.cgi change needed? I wouldn't think we'd > suddenly need all of the bug data? Obviously there's some form of recursion > going on I presume from show.cgi we had some data that was needed which gets > lost on the 2nd call to attachment.cgi? yep. from show.cgi we had some data that was needed which gets lost on the 2nd call to attachment.cgi.
ok, looks good to me, please check it in after testing has been successful.
Tested well. checked into cvs.