Developer Thought Stream

Here are the specific steps for adding a case record type. Some steps may vary by organization but the process should be pretty similar to what is shown here. 1) Create a new page layout 2) Add any new case statuses to picklist 3) Edit case statuses that should indicate case is "closed" 4) Add any new case types to picklist 5) Add any new case reasons to picklist 6) Add any new case origins to picklist 7) Add any new fields to case object 8) Under Record Types, ensure the picklists have the correct values (i.e. - Reason/Type/Origin) 9) Within the Type field, edit "Reason" field dependencies matrix and add new reason(s) to types 10) Create a new support process (if not reusing an existing one) 11) Create the new record type (enable for all profiles) 12) Finalize the page layout (if needed) and check "Default" in Case Assignment checkbox under Layout Properties 13) Create approval queues (if needed) 14) Set up approv

Working with code within the constraints of Salesforce's workflow can be a challenge.  First , you have the restriction on changing anything in production.  Second , you have the requirement for 75% or greater unit test coverage.  Third , you have the fact that certain metadata cannot be pushed to production through a changeset (which means the only way to sync record IDs is by re-deploying the development environment from production). Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI .  The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production.  And (here's the kicker)...sometimes it doesn't work because...reasons. So let's start with the workflow of a f

I'm departing from WebDev for a minute to blog about technology. I'm as guilty of over-indulging in technology as anyone, especially given that my career demands a technology overload. Today at noon is the solar eclipse and that prompted me to think about the past and the future. I started to think about where the world stands and a song came up on my playlist that seemed perfect for my mood. 27 years ago, Bad Religion wrote a song about the current generation of kids. It would be prophetic if it weren't for the fact that the trend had already begun back then. In any event, it seems now is a good time to look back at the lyrics: 'Cause I'm a twenty-first century digital boy I don't know how to live but I got a lot of toys My daddy's a lazy middle-class intellectual My mommy's on Valium, so ineffectual What child these days does not have multiple devices to play with? Gaming systems, television, computers and tablets are in nearly every home. Kid

I was reviewing some blade view code recently and decided it was too verbose. There were some long output statements that were duplicated throughout the view and that always signals a need to refactor or come up with a better method. So I wanted to share (or at least document) what I came up with here. First, the issue: fields stored as boolean "0/1" in the database must be output in "Yes/No" format. Plus, if the field is blank (or null), that must be reflected as well. Add to that the uncertainty of whether the production Microsoft Azure database will return a string or integer value for 1 or 0. This problem necessitates a blade statement like: {{ $object->property === null || $object->property === "" ? "" : $object->property == 1 ? 'Yes' : 'No' }} Like I said...verbose! One solution might be to create a Laravel accessor for the boolean field in the model. But that would mean that if I want the actual boolean

While perhaps not as powerful as the Twig template engine, Laravel's Blade template engine does pretty much everything you're likely to need done in your view templates and it does it with more intuitive syntax. So I wanted to give it some props here that it very much deserves. To boil Blade down to its very basics, there are three essential construct types you need to know: {{ $var }} - output a variable {!! $html !!} - output some HTML (previously sanitized, we hope) @something - the equivalent of the if/else/foreach statements in PHP Basically, any PHP statement you need to use will work within the body of these three constructs. So here are some control flow statements in Blade: @foreach ($companies as $i => $company) @endforeach @if ($something === null) @endif And here are three versions of an echo statement that all work the same: {{ $name === null ? 'Unknown Name' : $name }} {{ $name or 'Unknown Name' }} {{ $name

As an industry, could we please stop parsing people's names into parts? The only place that is useful is on government websites - and I'd even question it then. What happens when someone is simply named "Cher/Bono/Peter Jenkins Jr. II" or whatever? Why should a website dictate how many parts a name should have? Splitting names into pieces causes all kinds of difficulty when interfacing with other websites. There is no point to it. A person is identified by ALL of their name, not a part of it. Let's just drop the name splitting and start identifying users by their WHOLE name. It will be a lot easier for everyone and make for one less column in the database.