Apex Code Development You need to sign in to do that
Don't have an account?
pastusobrown Silent change to backward compatibility
So, I have an Apex class that uses version 10.0 of the API (Summer '07) and it references a standard SF field called UserPermissionsAvantgoUser. I can't find reference to this anywhere else but here.
Yesterday (19th May) I started receiving Apex exceptions that stated that the field does not exist, which appears to be true if you look at the meta-data for the user object.
Simple, you might think; just remove the field from the class definition in a sandbox and deploy to production through eclipse. Unfortunately, SF won't let me overwrite the class, because, according to the validation error, the original class in production is referencing a non-existant field. Catch 22...
Apart from breaking a critical web app that we've built around this class, it is also disrupting normal operation of SF because we have triggers firing on contact edits which get stuck in the invalid code, even though the triggers only apply to a subset of contacts. I'm not a happy bunny.
I've raised a support case and hope to hear back ASAP, but was wondering if anyone else has been hit by this silent change to the backwards compatibility of the API? Any workarounds for when you are denied a class overwrite due to invalid code in production?
The error is occurring in production and doesn't seem to be replicable in any of our sandboxes (full or production). The case number is 02667823. Thanks for picking this up.
I've just got off the phone with support (over an hour long on an international call...ouch) and it seems that we aren't the only ones. It's being escalated, so we'll hopefully get a result soon. The only resolution I can see is the following:
I'm guessing that where things have gone wrong is that people who used eclipse to write code back in the old days may have been using the office toolkit, which does reference the field and is based on API 7.0. Maybe somebody decided to kill the field and didn't check against the really old APIs (the furthest back I can find on the web is API 8.0).
Did anybody receive an end-of-life message for UserPermissionsAvantgoUser?
"API End-of-Life
Salesforce.com is committed to supporting each API version for a minimum of three years from the date of first release. In order to improve the quality and performance of the API, versions that are more than three years old may cease to be supported.
When an API version is scheduled to be unsupported, an advance end-of-life notice will be given at least one year before support for the API version is ended. Salesforce.com will directly notify customers using API versions scheduled for end of life."
Just as a side note, here's the debug log from my attempted deployment of the corrected class from sandbox to live, via eclipse. Note the problem message, which is where the catch 22 lies.
WARN [2009-05-20 12:12:55,915] (DeploymentController.java:deployWork:964) - Deployment FAILED. Got the following deploy messages [2]:
(1) (F) filename = classes/SystemUser.cls, result = FAILED, affect = none, problem = Dependent class is invalid and needs recompilation:
systemuser: line 8, column 66: No such column 'UserPermissionsAvantgoUser' on entity 'User'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names., line# = null, column# = null, id = null, fullname = SystemUser
(2) filename = package.xml, result = SUCCESS, affect = changed, id = null, fullname = package.xml
We are experiencing the same problem, our API sync has failed due to the UserPermissionsAvantgoUser field now missing.
We also did not receive any 'end of life' message from SF or any other API related alert.
Any help on this would be much appreciated as it has also shut down many of our other downstream processes.
Thanks,
Nathan Ziv
nziv@adconion.com
I've spent a long time on the phone trying to get this escalated as rapidly as possible, as its resolution requires either a backdoor into live Apex, or reinstatement of the deleted field, both things that I assume would be beyond conventional support, even at tier 3.
Any platform engineers around to please help us out?
Thanks for the update. The case number is 02667823.
It appears that UserPermissionsAvantgoUser has been reinstated. I received an email from tier 2 support asking for steps to reproduce the issue and decided to double check it was still a problem and, voila, the field is back! Triple-checked witha data loader export of users and it's definitely back.
Thanks for reinstating the field and can we please have an end of life message next time?