Autocomplete for Custom Object not working

[Sergey Trusov]

MyCustomObject has myFiledName field, but in following code I see No suggestions message:

MyCustomObject myObj = new MyCustomObject();
myObj.myF 

I would like to see myFiledName in autocomplete popup.

[Scott Wells]

Is that field in the stub Apex class in the OST? If not, can you check field-level visibility in the dev org? I've seen this happen when fields on custom objects aren't visible for the authenticated user and therefore aren't returned in the API calls used to build the OST. Adding authorization for the configured user and regenerating the SObjects in the OST resolves it.

[Sergey Trusov]

OST don't generated for this Custom Object. I logged as Sys. Admin and have rights for this object and all it fields.

[Scott Wells]

So it's not just the field but the entire object that's absent from the OST? And as odd as this may sound, what I'm seeing is that even when logged in as sys admin (I mostly do that as well), there are times that a field may not be returned in the API response. To resolve this you have to ensure that the field is accessible for the profile, in this case System Administrator. You can see whether it is or not by going into the field itself in the Setup menu and clicking View Field Accessibility. If in the resulting screen you see Hidden for your authenticated user's profile, the field won't be returned in the API. I'm still trying to see if there's some way I can circumvent this when generating the OST as it's a serious nuisance for the user to have to authorize these!

UPDATE: Or maybe it's under Set Field-Level Security where this needs to be configured. Either way it's cumbersome and I'd really like to convince the API call that I should have access to all the fields without requiring this!

[Sergey Trusov]

So it's not just the field but the entire object that's absent from the OST?

Yes.

As I wrote above I have full access to that field and object.

[Scott Wells]

Okay. Are there any other notable omissions in the OST? If so, are there any obvious patterns to those omissions? Do you see any errors or stack traces in idea.log when generating the OST?

[Scott Wells]

Sergey, if you happen to have any other Force.com development tools installed/available, e.g., the Force.com IDE, are you able to see these custom objects/fields from those tools? Here's why I ask...as I mentioned above, even though I'm logged in as sys admin, there are some fields that are not returned by the Partner API's describeSObjects() call because of field-level security.

I just verified that this is the case not just in Illuminated Cloud but also in Force.com IDE's Schema Explorer and in SublimeText/MavensMate completion. Adjusting the FLS for these fields resolves the issue in all client tools. Here's another thread on the topic:

http://stackoverflow.com/questions/20475619/how-to-get-custom-fields-list-with-describesobject-on-salesforce

It sounds like you're also not getting back the entire object, though, so this could certainly be a different issue. If that's the case I'll need additional diagnostic info from idea.log while the OST is generating. One easy way to isolate that single object is to make a nominal change to the .object file from within Illuminated Cloud and save it. After successful deployment to the org, IC will automatically regenerate the OST entry for that object in the background.

Let me know!

[Sergey Trusov]

I check one again and let you know about the results.

[Scott Wells]

Resolving due to inactivity. If this is still occurring please reopen with additional details.

[Gustavo Tandeciarz]

Where there changes made to the IDE plugin that modify the FLS for fields when generating the OST? I don't think the IDE should be making any changes to an org automatically without notifying the user.

[Scott Wells]

This behavior has been in place for quite a while. For orgs denoted as Development, by default it tries to ensure that the configured user's profile has access to all SObject fields...otherwise they won't be returned in the API calls and therefore end up in the OST. For Production orgs, this of course defaults to off. In either case it can be disabled explicitly on a connection-by-connection basis.

[Gustavo Tandeciarz]

Yup, makes sense now that I saw the setting. Thanks!