Nick Likane is a hobby junky and Salesforce Developer.
This page offers a little of both.
So I wrote a piece of code that should by all accounts not work (but it's kinda cool, it returns the top level account ids via hierarchy for any accounts passed to save on queries in does this 4 levels at a time):
On code review by our own Chuck Lidell, he pointed out, there is a potential of a null error being thrown if a parent is null when line "targetedAccount.Parent.Parent.Parent.ParentID != null" is hit. Sure I wrote the code without my coffee, but it passed testing... so we dug deeper. This got more interesting
this doesn't throw any errors, even though the depth is not physically possible in a query.
Change the query to:
and you hit "System.SObjectException: SObject row was retrieved via SOQL without querying the requested field: Account.Parent
AnonymousBlock: line 16, column 1"
Amend query to:
And again no errors are thrown on the whole debug block.
Works for other references too
No errors thrown
Conclusion, past a depth of 2, as long as the schema is valid, there is no check for presence of field in query.
So I spent April in Morocco participating in Marathon Des Sables. Considered one of the hardest races in the world. A write up of the run itself can be found here.
We were also fortunate enough to be featured in a web series segment by MDS. A play list to our segments can be found here.
Around the 50km mark , when the usual questions started circling my head "What sort of person spends Easter running in a desert?" the answer was obvious "the exact sort of person who works as a SF dev for almost a decade." As I pondered this and what it meant over the next 50, this article wrote itself. Without further ado, here's why being a SF Dev and an ultra-runner is exactly the same.
1. Nobody Will Understand What You DoSF: Are you a config specialist? How do you connect to the database? Where are the servers? Regular developers do not understand your trials and tribulations. They don't understand how you work with the environment. You'll be called everything from …
This article is based on a presentation I did at a local Salesforce Dev User Group meetup.
So this client paid me money to work for them for 6 months, which means, listen to requirements and do your best to implement. In this case, 30 objects assigned to accounts need to be shared to external users via a complicated security hierarchy based on the accounts in the hierarchy. The specific level of access should be able to be modified going forward and at least 6 levels of hierarchy schould be catered for... no problem right?
So optimal solution would allow an internal administrator user to control what a account contact user (I'll refer to these as external user) sees. For certain records, example 'rules and regulations' the external users BELOW the one in the hierarchy, should be able to have visibility access. For others, e.g. high sensitivity cases, the lower account should have complete access to enter/manage a case, but the higher accounts should not have any vi…