Description of problem:
our HwCert catalog has a flaw :
For example ,let's say machineA is certified against x86_64 arch
only, certified against RHEL5, the cert ID is 111111, and we have
already posted it to public. But some days later, the vendor wants to
certify this machineA against i386 arch and also against RHEL5 as well,
and they just rudely upload the i386 result rpms to the posted
cert#111111 and ask us to check the i386 results . In this case, our
HwCert catalog will accept the i386 result rpms and automatically add
"i386" into the "Platforms" area, meanwhile, the cert#111111 remains
closed and is visible to public. Which means we have not check the new
i386 results yet, but if someone query cert#111111 at this time, he will
see machineA is certified against both i386 and x86_64. This is not correct.
and here is an example -->
AFAIK, if vendors want to expand their certifications, they need to
create new cert requests against the same machine and leave the posted
certs un-touched. But some vendors don't know this process. So my
concern is : can we make the HwCert catalog refuse to accept new result
rpms once the cert is closed ?(at least , treat the result rpms as
normal attachments, do not read the result details)
Created attachment 305500 [details]
Created attachment 305922 [details]
1. Forbid the vendor to reopen a cert.
2. Add the text guide info as Rob's said to the vendor who want to reopen the
Looks pretty good but the statement says the bug is closed and public; but the
'[% IF' doesn't seem to check if the bug is public?
Created attachment 306039 [details]
1. narrow and add the condition: "public" cert. (If bug is closed && user is
not hwcert_edit && bug is public, then forbid the reopen action and give the
text guide info.)
2. have test it well.
wrap the [% IF %] around the whole tr, and otherwise the patch looks good to me;
if it's tested to work go ahead and check it in.
Created attachment 306073 [details]
1.warp the <tr> with [% IF %]
2. test well.
Patch has checked into cvs