October 26, 2015

By Sergey P. – (Softensity)

Some time ago I had an issue figuring out how to update a standard object from the Force.com site. To describe the problem more precisely, there appears to be a restriction when attempting to update a standard object under the typical Guest User privileges.

Having identified the problem, I was curious about a potential fix so I set out to find a workaround to help update a standard object.

I searched the Internet for more information about how to fix this problem, and discovered a helpful post in salesforce.stackexchange.com

With all due respect to Peter Knolle (Force.com MVP), the Salesforce solution has a weakness that I would like to eliminate, which are that sharing rules are not supported.
 

The following chronologically steps through the process that I used to fix this problem.

 
So the issue in practice is: when we try to use <apex:inputField /> with the Contact property { get; set; } then we receive fields that are uneditable. This results from the fact that the update operation is forbidden by the Guest User profile for standard objects. See image 2.

See image 1 below:

Salesforce-Development-1

Salesforce-Development-2
 

My first idea was a bit outside of the box, which was to create a custom object with a trigger and complete the update via trigger on that object. However, that was the moment I started to think about metadata in Force.com. My main intention was to create a clone for current record and afterwards be able to use the cloned record as a status indicator.

The indicator will show whether or not the record was changed during the update. In other words, we go in and check the values of the fields when the page loads, and compare to the field values at the moment of the update. If there is any difference in status between the moments, then we proceed to save new values to the cloned object.

In order to make the fields editable you need to produce some specific code (as seen in the sample below):
 
Salesforce-Development-3
 
Salesforce-Development-4
 
If you use contact property without implementing the method targetContact.clone (false,false), you’ll end up getting a result similar to what is shown on image 1, which are non-editable fields.

But if the Clone is used you’ll get your desired result, as is seen in image 3.
 
Salesforce-Development-5
 
Next, we will implement a method for comparing the values of the sourceContact function:
 
Salesforce-Development-6
 
Important Note: This section allows us to continue the processing cycle in case of a known exception. I believe that we can avoid the “try and catch” section if we use a JSON parser for the object and then do validation on fields from a SOQL query. However, this could be a subject for an additional article in the future.

The variable FieldMap (see below) stores the metadata of all fields of the Contact object that was used in the method above.
 
Salesforce-Development-7
 
The last thing we need to do is to complete the update of the record:
 
Salesforce-Development-8
 
At this point, we have completed our task of successfully updating the record in database.

As an aside, I also played around with the Sharing rules a bit and came to the following conclusion. If sharing rules are private then we receive an error message on page load. If sharing rules are ‘Read Only’ then we get an error at moment of execution of the updated operation.

Also we can use additional IDs to update the records from the targetContact instead of the updateRecords() method. In this situation, we simply made an additional SOQL query in the DataBase.
 
Salesforce-Development-9
 
Salesforce-Development-10
 
I hope that this article can prove to be useful for anyone who is facing a similar problem with SalesForce.

BACK TO MAIN PAGE

Previous blogs

Navigating the Future of Education in the Age of GenAI: A Guide for Parents

March 27, 2024
Read more

Navigating the AI Investment Crossroads: Build or Buy?

March 25, 2024
Read more

Let’s Talk