function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
jconleyjconley 

Changes to API v1.7 Last Night?

This may not be the place to ask this but does anyone know if there were changes to the API (specifically v1.7) last night?  It would appear that custom fields we created on both the Contact Record and Case Record stated failing with "bad field names on insert/update call" as of about 10:00pm EST last night. Our code has not changed since July 3, 2003 so I am assuming something chaned on the SF side?
adamgadamg
See this thread: http://forums.sforce.com/sforce/board/message?board.id=general_development&message.id=657
jconleyjconley

We had read that thread this morning and do not see where it is relevant to our issue.  It seems to me that if there were documentation available about specifically what you changed last night we could determine the source of our issue.  It would have also helped if there were a clear - permanent location on the site that would inform us of when specific changes are going to take place and what those changes are.  In our case, a system that has worked perfectly since we last touched the code in July,  as of last night no longer works.  Our developers have read the thread also and do not see where it pertains to our problem.

We have fields (for example) in our contact record that we choose to not display on the layout.  One of them was a picklist and after changing it to a text field this morning and adding it to the layout we no longer see the error on that field and are no getting it on another field.

 

 
benjasikbenjasik
Can you post a sample request that is failing?
jconleyjconley

<methodCall><methodName>sfdc.insert</methodName><params><param><value><struct><member><name>version</name><value><string>1.7</string></value></member><member><name>type</name><value><string>case</string></value></member><member> <name>record</name> <value><struct> <member><name>email</name><value></value></member> <member><name>contactID</name><value>00330000001soph</value></member> <member><name>00N30000000LV9R</name><value>46625</value></member> <member><name>name</name><value></value></member> <member><name>subject</name><value>Spam Violation</value></member> <member><name>description</name><value></value></member> <member><name>type</name><value>Spam Violations</value></member> <member><name>status</name><value>New</value></member> <member><name>origin</name><value>web</value></member> <member><name>ownerID</name><value>00Z30000000bnwb</value></member> </struct></value></member></struct></value></param></params></methodCall>
benjasikbenjasik
Thanks, we're investigating this issue.
jconleyjconley

If it is of any assistance it appears that any custom fields we created (approx 6 months ago) can no longer be added to the case page layout - I can use your layout editor to place them on the case record but they do not appear.   I can add old exisitng custom fields to a Contact Record - just not to a Case Record

A new custom field I created today does appear.

 
benjasikbenjasik
For the older custom field, are you using field-level security? If so, what access rights does the user you are logging in as have for that field?
jconleyjconley

The particular field in question was marked 'Hidden' - I changed the security to editable for both my and the API account and was able to enter a case.

That appears to be the fix - that only leaves the question of how to avoid issues like this in the future when changes are made on the SF side?

Thanks for the effort in resolving this!

 

John

 

 
mtyszkomtyszko
We are having a similiar problem in our system: xmlRpcException: bad field names on insert/update call.

Have we determined if there was a change to the system last night and what the change was? We are still having issues and I don't believe we use hidden fields.
CovenantCovenant
Interesting thread and we've hit this problem, as well.  Our solution was to use an admin. account to do most, if not all, of the updating and creation of new objects.
 
To ensure that this works, all of the time, we create a page layout view which contains everything the "master" does.  In this way, all fields are exposed.
 
Also, we had a lot of code which was automatically returning all of the possible fields on a particular object.  The problem is that the list returned via an API call in version 2.0/2.1 and below doesn't match the page layout of the user that is running the command, it matches the "master" view.  Our solution was as follows:
 
1.  Do what I state, above, and create a page layout which exposes everything for the super-user/admin.
2.  For all of the queries I'm doing I catch the "bad" field exception and retry the request, recursively, with the offending field removed.
3.  Our code that allows non-admin users to login is limited, so we're handling those page layout issues on an issue-by-issue basis.
 
Cheers,
 
- Brendan
mtyszkomtyszko
We modified the profile this morning to give our users admin privilages as well and it stopped the error message, but this is only a temporary solution.

I would like to know what specific admin privilages we need to set. I don't like the idea of giving our users all admin privilages.
jconleyjconley

In our case we had to go into  Setup>Security Controls>Field Accessibility>View by Profile and change the security settings on the one field causing the error from 'Hidden' to 'Editable' in order for our API Code to be able to populate the field.

I am not sure why this became an issue as of last night but I am certain a change was made on the SF side as out code has been untouched for months.  I would think a better error code being returned would have helped to isolate the problem quicker. 

I have to say I love the SF product and we will continue to implement it - I would love to see a System Status Page (alerting us to outages, issues, and updates) as well as a more timely release of documentation/tech notes pertaining to updates and fixes.
Donovan KrugerDonovan Kruger
"I would love to see a System Status Page (alerting us to outages, issues, and updates) as well as a more timely release of documentation/tech notes pertaining to updates and fixes."

I completely agree. In addition to this, I would also like a test system with the proposed changes for users to test with PRIOR to their actual release to the production system. Testing in Production is a risky business.