Standard field accessiblity inconsistent : feature or simply strange?

Question

UPDATE:

Thanks to @ca_peterson I could clarify the issue below and it all drills down to FLS. But even having identified FLS as the reason, the behavior is still odd and I have addressed it in this new question:

FLS behaviour different between API and GUI/Apex

ORIGINAL:

It looks like Salesforce is changing the database schema affecting some standard fields. As an unfortunate even with an versioned API it seems to cause trouble. I'm sure there are more fields affected, but let's pick out two:

Contact.DoNotCall
Opportunity.ContractId 

I have an Org created early 2014, now running on eu0 (emea). Saleforce Version is Winter'15 (v32.0).

There I'm facing the following scenario:

• both fields are visible in the setup
• both fields are reported by describe calls in Apex classes (having <apiVersion>32.0</apiVersion> it's xml)
• both fields are saveable as static SOQL Queries in Apex classes like Contact[] cs = [ select name, DoNotCall from contact ]; (again v32 in xml)
• both fields are usable without error in Apex code (v32) as well as in static and dynamic SOQL queries.

however as a matter of fact

• both fields are not visible in eclipse schema.xml (plugin v31)
• both fields are not accessible in Developer Console (Query Editor Tab, it uses v32 soap api under the hood)
• switching to tooling api (v32) in Developer Console ends up the same
• and last but not least both fields lead to an error if used in apexString via sforce.apex.executeAnonymous( apexString ) having included /soap/ajax/32.0/connection.js and /soap/ajax/32.0/apex.js
• same goes for executeAnonymous invoked via toolingApi (v32)

It boils down to something like: The UI and apex have these fields - but the API doesn't. Why?

As to my understanding all the versioning effort with the metadata should bring developers an consistent set of standard fields within the same API version. Right? But obviously it doesn't.

So my question: bug or a feature?

Now just about curiosity it checked an other org on eu5 instance, which is already version Spring'15 (v33.0). There in the UI Opportunity.ContractId is not present, however Contact.DoNotCall is present. The other tests form above I haven't processed yet. What is going on?

Is there any documentation about Standard Field changes? How will it affect older orgs? Will they keep the old fields? Do we have different sets of standard fields depending on the creation date of Orgs?

I had a similar issue some time ago when the standard address fields had been changed in the API but not in the UI/Apex. There was a Compound Field like ShippingAddress introduced for API only, but was reported by describe-calls. This was confirmed as an error. The current issue feel a bit like a deja vu.

Now without premier support I can't even report it... :-(

Answer 1

Can you check field level security? The platform's behavior when no profiles have access to a field seems to be inconsistent and quite odd in some cases. I've seen SysAdmin profiles that didn't have access to fields via anonymous apex because of this, as well as cases where the field didn't show up in the apex describe info because no profiles had access.

The other possibility is that there's a deprecated feature in your org. Most major functionality seems to be implemented as a default-on option in support's black tab. Things like the CRM Content system that are always enabled for new orgs are disabled for a small subset of old orgs. It's very possible the inverse has happened here - you have some contract feature enabled that isn't on by default in new orgs.

You can trying asking regular (non-developer) support for a feature activation of content and see what happens, I've had some luck asking vaguely for features and having them correct me on the name and what it does.