Display Inaccessible Objects to (Salesforce) Portal Users

This post was rescued from the cache for posterity.

Display Inaccessible Objects to (Salesforce) Portal Users

by Clint Lee on June 28th, 2011

It’s quite late, and I can’t think of anything particularly clever to say, so I’ll just get straight to the point.
If you’ve ever built a custom portal using Salesforce Sites then you’ve most likely had to navigate your way through the various portal licenses at some point. Let’s see, there’s a Customer Portal, a High Volume Customer Portal, an Authenticated Sites, and perhaps another one. Oh yeah, then there’s the Public Site profile.  Each license has its own nuances – object access, CRUD permissions, cost.  Inevitably you’ll need to decide on the license type that best fits what you’re trying to do, knowing that you might have to concede something down the road as you hit a gotcha! or two.
I came across a particular situation where I needed to display information from the Account object to the user.  The Site being built utilized the Authenticated Sites portal license (which provides user authentication but requires a lot of development since it requires only Visualforce pages).  Unfortunately, the Authenticated Sites license doesn’t provide the user with access to the Account object.  When I say no access I mean they can’t even read it.  So, a workaround ensued…
The following solution is not particularly mind-blowing, or really even that sophisticated, but it works for displaying data in what could be termed as “inaccessible” objects.  These are objects that Authenticated Sites licensees can’t read like Accounts, Opportunities, and Cases.  Enter….(drumroll, please)…the Wrapper Class.  Yes, folks, the Wrapper Class.  To most, this was probably obvious from the start but for me it took some noodling around.  Therefore, I decided to share in an effort to prevent others like me from noodling for too long.
Go ahead and create a wrapper class for your object, like so. Name it whatever you like. I call mine AccountToString b/c it sounds fancy.

public class AccountToString {
    private Account acct;

    public AccountToString(Account acct) {
           this.acct = acct;
    }

    public String getName() {
           return acct.Name;
    }

    public String getAddress() {
           return acct.BillingAddress;
    }

    public String getCity() {
           return acct.BillingCity;
    }

    public String getState() {
           return acct.BillingState;
    }

    public String getZip() {
           return acct.BillingPostalCode;
    }

}

Write a controller method to turn your accounts into AccountToStrings. I needed a table with Account data so I populated a class variable with a list of AccountToStrings. Here’s an example.

// This method could run in the controller's constructor.
public void findAccounts() {
           List accts = [select Id, Name, BillingAddress, BillingCity, BillingState, BillingPostalCode from Account];
           for(Account a : accts) {
                 AccountToString aString = new AccountToString( Name = a.Name, BillingAddress = a.BillingAddress, BillingCity = a.BillingCity, BillingState = a.BillingState, BillingPostalCode = a.BillingPostalCode);
                 aStringList.add(aString); // aStringList is a public class variable
           }

Finally, in your Visualforce page, this is one way that you could access your list of AccountToStrings.

    
        
             
                  Account Name
                  
             
             
                  Address
                  
             
             
                  City
                  
             
             
                  State
                  
             
             
                  Zip
                  
             
          
     

I hope this makes sense and perhaps saves you some time. As always, I look forward to any comments or feedback.