Overlapping this is another 8-hour window for NA0 (SSL) starting two hours earlier.

Also starting at 7pm PST, EU0 (EMEA) will be down for 2.5 hours.

All other instances will be down for 30 minutes, from 9pm PST.

As the email from salesforce.com explains:

Dear Salesforce Administrator, At salesforce.com, customer success through system availability and reliability is our top priority. As part of our ongoing plan to deliver high availability and reliability, we are enhancing our service infrastructure on our NA1 instance. Please be aware that salesforce.com will be performing scheduled maintenance that will extend beyond standard system maintenance windows. The current scheduled window is: Saturday, March 20th, 2010 from 7:00pm PST to Sunday, March 21st at 3:00am PST During this time, the salesforce.com NA1 service will be unavailable. Users attempting to access the service during this time will be presented with a scheduled maintenance notification page. We appreciate your patience during this maintenance window. Best regards, -salesforce.com Support

Copyright 2000-2010 salesforce.com - All rights reserved - Various trademarks held by their respective owners Salesforce.com, One Market Street, Suite 300, San Francisco, CA 94105

NA0 (SSL) March 20, 5:00 pm PDT - March 21, 1:00 am PDT The NA0 instance will have maintenance performed at this time. The instance will be unavailable for the duration of the maintenance. EU0 (EMEA) March 20, 7:00 pm PDT - March 20, 9:30 pm PDT The EU0 instance will have maintenance performed at this time. The instance will be unavailable for the duration of the maintenance. NA1 March 20, 7:00 pm PDT - March 21, 3:00 am PDT The NA1 instance will have maintenance performed at this time. The instance will be unavailable for the duration of the maintenance. All instances March 20, 9:00 pm PDT - March 20, 9:30 pm PDT The Salesforce.com Technology will be performing maintenance at this time. During this time all instances will be unavailable for the duration of the maintenance.

Firstly, you’ll need to contact salesforce.com to get this feature enabled.

Then be patient. It takes a minute or two for the update to propagate. Clearly, something was churning in the Force.com platform background!

Now we’ll navigate NOT to the Setup | Customize | User Interface screen (where this should be enabled). Instead, we’ll go to the Opportunity Page Layout screen.

Follow the cool prompts. They make it so easy, a … well, you know what I mean.

Step 1: Enable the Highlights Panel

Opportunity Layout Setup

Step 2: Edit the Page Layout

Choose Fields to Display

Note: You can only show fields in the Highlights Panel if they are in the page layout. (I have a feeling this has to do with Professional Edition or printable layouts, but I’m just guessing.)

Once you’ve done this for each page layout, click on the big button.

Confirmation - You are (mostly) done!

At this point, each user can enable the bar. I have no idea why the admin can’t just force this on all users – or maybe I missed something – but it seems to be an opt-in feature.

Step 3: Enable User Opt-In

Here’s the link to enable the feature. Of course, you may wish to watch a video as well!

The link to enable this setting

And here it is!

The new layout!

Return to top from the bottom of the page

It’s interesting that if you have this enabled, certain user interface settings (yes, at Setup | Customize | User Interface) cannot be changed:

When this is enabled, you cannot turn off two settings

Here’s my prediction: We will start to see two major mistakes during Salesforce demos:

1. We will continue to see the link asking if we want more information on inline editing (after more than a year, it’s time to turn that off, people).
2. At the top of the Opportunity detail page, we will see this link.

And I will continue to think less of all demonstrators who make these mistakes.

Happy Spring 2010!

I had this problem when Content was first released and I was asked to be one of the first SysAds to use it. At the time, we used Solution 1 (below), but since then, other products have been released to help with this.

Why is it even an issue?

• Surely we can download each file? Yes, but who wants to?
• Can't we do a Data Export and then upload those to Content? Yes, but all the files are renamed with their 15-character Ids, making renaming them all-but-impossible.

Solution 1

# Nick Marcantonio
# nmarcantonio at salesforce.com
# 08/07

$file = 'Attachment.csv';

open (F, $file) || die ("Could not open $file!");

$line = <F>; #read first line which is nothing but column headers
while ($line = <F>)
{
  ($id,$name) = split ',', $line;
  chomp($id);
  $id =~ s/\"//g;
  chomp($name);
  $name =~ s/\"//g;
  
  #print "$id : $name\n";
  
  $result = rename($id, $name);
  #print "$result\n";
}

close (F);

If you've done a data export you've noticed that all attachments are placed in the Attachments subfolder and named with their salesforce ID, not the actual file name or extension. One must then consult the Attachment.csv file included in the data export to find the name associated with the ID and rename the file. Attached to this solution is a Perl script that will rename all of the exported attachments to their proper names. Please follow these steps to run this:

1. Perform a data export and unzip the resulting zip file
2. Launch the data loader and export from the Attachments table ONLY the Id and Name column. This file must be named Attachment.csv.
3. Install ActivePerl. This will allow perl scripts to be run on a Windows machine. ActivePerl is available here (http://www.activestate.com/activeperl).
4. Copy the Attachment.csv file and the attached AttachmentParser.pl file to the Attachments subdirectory of the data export.
5. Double-click on AttachmentParser.pl.

All of the files named with their salesforce IDs will be renamed with their proper names and file extensions.

(This solution will work for documents as well. Follow the same procedure and be sure to name the extract from the Documents table Attachment.csv) 

Note: This will not preserve folders, as far as I know. You may be able to recreate this by exporting the Folder table and doing some work on that, as the Document table does include a FolderId column.

A heartfelt thank-you to Nick Marcantonio for his help!

Solution 2

Install DreamFactory's FREE DreamTeam Document Management application from the AppExchange to drag-and-drop your Documents to your desktop.
This doesn't work with Attachments, though, so you may need to use another method for them.

Please let us know how it goes - good luck and enjoy Content!

Workbook
http://www.salesforce.com/us/developer/docs/workbook/index.htm

Fundamentals
http://www.salesforce.com/us/developer/docs/fundamentals/index.htm

Cookbook
http://www.salesforce.com/us/developer/docs/cookbook/index.htm

Apex Advanced Code Example
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_shopping_cart_example.htm
https://sites.secure.force.com/appexchange/listingDetail?listingId=a0N30000001saDCEAY

And many more to come!

Lookup filters function similarly to validation rules when you save a record. That is, actions that cause related records to save, such as changes to a roll-up summary fields, also trigger the lookup filters on the related record and block the save.

The implications for this are massive. Let's explore two examples:

Example 1: Filter as Validation Rule from Parent Record

• We create a lookup on a Child object to Parent.
• We filter the lookup to EXCLUDE Parent.Status = 'Closed' (Parent.Status is only Open or Closed.)
• We can edit the Child records as long as the Parent Status is not Closed.
• When Parent.Status is changed to Closed, existing related Child records are not affected...
• BUT if we attempt to edit a Child when the Parent is Closed, Force.com will throw an error (which we can customize) beause that the Lookup is invalid.
• (and clearly we cannot add new Child records either)

Conclusion: Thus, Filtered Lookups act much like Validation Rules. A quick experiment shows that Filtered Lookup errors actually fire before Validation Rules.

Example 2: Filter as Validation Rule on Roll-Up Summary (from Child Record) - what the line above was referencing

• Use the above example, but change the lookup to a master-detail relationship
• Create a Roll-Up Summary field to count all child records
• Prevent saving more than 10 child records for one parent record

Here, we have triggered a filter error without touching a parent record, yet we throw an error based on a value on the parent record.

This second example is significant because we could already prevent more than 10 child records from saving, but doing so required a Roll-Up Summary field on the parent object AND a Validation Rule on the child object. Now we can replace the Validation Rule with the Lookup Filter, though we still need the Roll-Up Summary field. Whether or not this simplifies things is definitely up for debate...

Conclusion

This is a very powerful feature! Thanks to salesforce.com for rolling it out, even in beta form.

Real world example: The above example would be great for Time Sheet Entry and Time Sheet Header objects, as they would create, in effect, a validation rule on the Header record preventing editing of any child records. Awesome!

For further reading, check Salesforce Help's Lookup Filters examples.

These pains can partially be alleviated by keeping all Apex code in one place--as Apex Classes. With the addition of a consolidated trigger list in Summer09, some may feel that this post is superfluous, but consolidating code in one place, combined with the trigger list, will lead to a better development, debugging, and org administration experience.

First, here's a sample trigger (written by Jeff Douglas):

trigger AddOwnerColor on Account (before insert, before update) {

    // create a set of all the unique ownerIds
    Set<Id> ownerIds = new Set<Id>();
    for (Account a : Trigger.new)
        ownerIds.add(a.OwnerId);    

    // query for all the User records for the unique userIds in the records
    // create a map for a lookup / hash table for the user info
    Map<Id, User> owners = new Map<Id, User>([Select Favorite_Color__c from User Where Id in: ownerIds]);   

    // iterate over the list of records being processed in the trigger and
    // set the color before being inserted or updated
    for (Account a : Trigger.new)
        a.Owner_Favorite_Color__c = owners.get(a.OwnerId).Favorite_Color__c; 
}

Let's pull the code from the trigger into an Apex Class and leave a reference to that class & method in the trigger. We need to pass the list Trigger.new as a parameter to the new class's method:

The trigger:

trigger AddOwnerColor on Account (before insert, before update) {
AccountTriggers.AddOwnerColor(Trigger.new);
}

public class AccountTriggers {
    public static void AddOwnerColor(Account[] accts) {

    // create a set of all the unique ownerIds
    Set<Id> ownerIds = new Set<Id>();
    for (Account a : accts)
        ownerIds.add(a.OwnerId);    

    // query for all the User records for the unique userIds in the records
    // create a map for a lookup / hash table for the user info
    Map<Id, User> owners = new Map<Id, User>([Select Favorite_Color__c from User Where Id in: ownerIds]);   

    // iterate over the list of records being processed in the trigger and
    // set the color before being inserted or updated
    for (Account a : accts)
        a.Owner_Favorite_Color__c = owners.get(a.OwnerId).Favorite_Color__c; 
    } // close AddOwnerColor
}

• Easier to work in Eclipse (all code in the Classes section)
• Easier to write test code (can see tests and their associated methods in one place)
• Can promote code reuse by allowing other classes and triggers to call the same method.
• For those who like to include test code in the same class as the regular Class, this allows them to do so.

There's a catch (there always is):

You should comment into your Class which trigger is calling the class because otherwise, it is almost impossible to see at a glance where the code flows. This will especially help when writing and debugging tests.

Just a matter of personal style: It may be a good idea to write an Apex Class for each object's triggers (such as class AccountTriggers above). Code reuse is still possible, but it can track where triggers were originally used.

Happy coding!]]> http://www.x2od.com/2009/05/18/pulling-code-out-of-triggers.html/feed 6 http://www.x2od.com/2009/05/07/dashboards-are-improved-and-new-in-summer-09.html http://www.x2od.com/2009/05/07/dashboards-are-improved-and-new-in-summer-09.html#comments Thu, 07 May 2009 21:54:18 +0000 David Schach http://www.x2od.com/?p=509 get yours now! Upon first look, something cool stood out and merits immediate posting: Dashboards are improved. The colors are more vivid, there's detail in the bars and pie chart wedges, and... pie charts can now display the actual and percentage values!]]> The Summer09 prerelease orgs are here, so get yours now! Upon first look, something cool stood out and merits immediate posting:

Dashboards are improved. The colors are more vivid, there’s detail in the bars and pie chart wedges, and… pie charts can now display the actual and percentage values!

Dashboards are also new. Visualforce pages can now be included as dashboard components, and there’s a new “Color-Blind Palette on Charts” setting for each user. Here are before and after shots.

Salesforce dashboard with regular color scheme

Dashboard with color-blind/alternate color scheme

It looks like a pretty cool way to work on RESTful integrations while making some pretty pictures for your users.

For those unfamiliar with the Salesforce/Google Visualization toolkit, developer.force.com has a great introduction.

The code is ridiculously simple, thanks to the apex:EnhancedList Visualforce tag:

<apex:page standardController="Task" >
<apex:enhancedList type="Activity" height="800" rowsPerPage="50" />
</apex:page>

1. The original use-case required displaying all upcoming events without the header or sidebar. We still cannot do this. Quoting from the Winter ’09 Release Notes: The enhancedList component is not allowed on pages that have the attribute showHeader set to false.
2. We’d like to create a custom tab for this page. We create a Visualforce Tab, pick a custom icon, and show the page… and when I click on the tab, the enhanced list is displayed, but the tab is not highlighted. Also, the custom icon I chose is not displayed. How do we highlight our tab?
   After making the page, we make the tab as desribed above. Then we RETURN to the page and add a tabstyle modifier to the apex:page tag, like so:

   <apex:page standardController="Task" tabstyle="enhanced_activities__tab">
   <apex:enhancedList type="Activity" height="800" rowsPerPage="50" />
   </apex:page>
   

   [Of course, change the tab name to whatever you choose.]

   Success? Not quite. There’s another catch:

3. The tab is highlighted (brown in our case), but the color and icon for the enhanced list are standard green/home.
   Sadly, I have no workaround for this one. Sorry.

Moving forward, consider if you want to create a particular enhanced list view instead of calling the standard enhanced Activity list as I have done here. If you would prefer to make a custom enhanced list view, then you will need to add more code, but that is beyond the scope of this post.

Enjoy!]]> http://www.x2od.com/2009/01/05/the-ultimate-visualforce-events-tab-almos.html/feed 4 http://www.x2od.com/2008/12/22/sites-guest-profile.html http://www.x2od.com/2008/12/22/sites-guest-profile.html#comments Mon, 22 Dec 2008 16:54:39 +0000 David Schach http://www.x2od.com/?p=294 I’m working on an event registration application for the Sites Developer Challenge, and it involves a validation that the registrant’s email exists in a Contact record. Remembering that Steve Andersen had run into some obstacles with Contact.Email visibility, I decided to check the guest profile for Contact Field Level Security. Here’s what I found:

Guest profile Contact Field Level Security

If you squint a bit, you can see that the Opt-Out and Email fields are hidden to the guest user. I have no idea why these, in particular, are hidden. Likewise, I couldn’t find a pattern in which fields were shown on the custom objects I had created, nor which were visible on standard objects.

In any event, I don’t have any pearls of wisdom on this topic; this is more of an informative note to all that are using Sites (especially if you plan to do any communication-subscriptions) to check out the Field-Level Security.

For those wondering how to get to this Profile (since it is not visible in the usual Profile section), go to the Sites page > Site Name or URL > Public Access Settings (a button).