Apex Code Development You need to sign in to do that
Don't have an account?
sprak Can only select fields using 2.5 API that are available in the UI?
Greetings; I came across an interesting problem while working with the 2.5 API. I was attempting to select the "DoNotCall" field for a Lead via a query call and was receiving the error message "INVALID_FIELD: Bad field name 'donotcall' in select list of query call". The field is defined as a standard SalesForce field in my Enterprise WSDL, so this was a very curious error message.
While staring at a Lead in the web UI, I noticed that the "DoNotCall" field was not being displayed. Checking our Lead page layout confirmed that the field was not being included in the page layout. It was the only clue I had at the time, so I searched the forums and ended up finding this post. It seems to confirm that if the field is not in the UI (is page layout a synonym for UI?) then you cannot access it via the API.
This seems like a "bad thing"(TM); if an administrator innocently removes a field from the UI, any applications using the API to access that field will suddenly break. Is there a way for the API call to force SalesForce to select all fields regardless of their inclusion in the UI?
Barring that, is there a way to add a field to the UI and keep it from being displayed? It seems possible as our Lead layout includes the "CurrencyIsoCode" field but does not display it to the user unless they edit the record. However, I have yet to find the option to do this when I edit the page layout itself.
Regards.
---
Luis A. Cruz
lcruz[at]astaro[dot]com
While staring at a Lead in the web UI, I noticed that the "DoNotCall" field was not being displayed. Checking our Lead page layout confirmed that the field was not being included in the page layout. It was the only clue I had at the time, so I searched the forums and ended up finding this post. It seems to confirm that if the field is not in the UI (is page layout a synonym for UI?) then you cannot access it via the API.
This seems like a "bad thing"(TM); if an administrator innocently removes a field from the UI, any applications using the API to access that field will suddenly break. Is there a way for the API call to force SalesForce to select all fields regardless of their inclusion in the UI?
Barring that, is there a way to add a field to the UI and keep it from being displayed? It seems possible as our Lead layout includes the "CurrencyIsoCode" field but does not display it to the user unless they edit the record. However, I have yet to find the option to do this when I edit the page layout itself.
Regards.
---
Luis A. Cruz
lcruz[at]astaro[dot]com
Your ability to query for the field should be a function of the field level security properties for that field, and not a function of that field's relationship to a layout.
If simply removing the field from the layout causes that problem, then that is a bug (and we'll fix it) - can you confirm that when the field layout was changed the the field level security for that was not changed as well?
Does that make sense?
When I check the field level accessibility for "DoNotCall", it is set to "hidden"; using the "set field-level security" button shows that nothing is checked for the "DoNotCall" field. "CurrencyIsoCode" is set to "Required" when checking field level accessibility; setting the security level shows that I really cannot edit anything though the field is visible to every group.
Does "hidden" mean "hidden from everyone including the API"? I am fairly new to SalesForce, so I admit that I'll apologize in advance if I am overlooking something simple.
--
Luis A. Cruz
lcruz[at]astaro[dot]com
The classes are designed to be extensible allowing one to create a child class that adds custom fields, etc. What would be the best way to submit my work to the SalesForce Sourceforge project? I could zip the files up and host them on a different web server for initial discussion if that is preferred.
*** EDIT: I should also note that I have made a small change to the PHP SalesForce client as well; I think the change might be beneficial to the community and would like to submit that as well.
Regards.
--
Luis A. Cruz
lcruz[at]astaro[dot]com
Message Edited by sprak on 03-15-2004 11:10 AM
Hi sprak,
Hidden does mean that it is not available via the API. The api attempts to mirror the application behavior.
Interesting; this still seems like a "Bad Thing"(tm). One person making a "simple change" to the web UI can break any API applications that depend on a field to not be "hidden".
Are there any future plans to indicate if a field is "hidden" in the WSDL file? Either by excluding any hidden fields from the generated WSDL or by an attribute specifying that it is a hidden field? Or better yet, have a way to force a call by a sysadmin user to retrieve/manipulate hidden fields.
--
Luis A. Cruz
lcruz[at]astaro[dot]com
Message Edited by sprak on 03-18-2004 01:13 PM
Hi sprak,
The wsdl provides a full view of the available objects and fields and methods. It is up to the developer to code the integration/extension to handle the various differences in access to data. This is done by using the describeSObject call. The describe will show the object as it appears to the user based on the login name. It is tempting to ignore the describe call when using the enterprise wsdl. Don't. A good practice is to do a describe for the objects that you are using, either when login occurs or just prior to first using an object. You should cache the result of the describe call for the duration of the session. You can then validate specific user access to the various objects.
It is not possible to indicate in the wsdl the hidden property of fields or objects, as it can be different for different users.