When selecting a product at this URL: https://bugzilla.mozilla.org/enter_bug.cgi Like: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core I am getting the following message. This message prevents a User to file a bug report. "undef error - Can't call method "_changes_everconfirmed" on unblessed reference at /data/www/bugzilla.mozilla.org/Bugzilla/Bug.pm line 3580." Jesse changed/added my permission to "editbugs" from "canconfirm" only. This has helped.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: unspecified → other
We think this happens for anyone who has "canconfirm" but not "editbugs".
Getting more and more complaints to bugzilla-admin@ about this. Need to get it fixed.
Priority: -- → P1
Sorry, I know you CCed me, but I can't fix this for at least ten days. Gerv
What is bug 582283?
Created attachment 461720 [details] [diff] [review] patch v1 OK, here's a stab at fixing this. The reason it broke is because in 3.6 the check_can_change_field routine started acting more like an object method and attempts to call other Bugzilla::Bug object methods to find out more information about the object it was passed. The way we hacked it before, the hash being passed wasn't an object, we just faked the method call so it would work. So the minute it started calling $self->anything() it died. My new hack, instead of faking a pointer to the method call where the template can find it, creates a new Bugzilla::FakeBug object, and stubs in passthrough methods to the specific method calls from Bugzilla::Bug which get used over the course of running check_can_change_field and its callees. This seems a far more sane solution than the previous one, although it's not very forward compatible (if check_can_change_field or any of it's callee methods ever add a call to an additional method, the new method will also have to be stubbed in). Since this is a hack for our templates on b.m.o anyway we can probably live with that.
Assignee: nobody → justdave
This is already live on bugzilla-stage-tip, btw, if anyone wants to test it there. It's behind ldap auth at the moment. If you have an LDAP ID and it doesn't work there and you want to test this, find me on IRC in #bmo.
Seems to work good from my own testing... to prevent ongoing issues with people trying to file bugs, I've gone ahead and committed this and deployed it to production.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.