Salesforce für Entwickler

Zur Abwechslung möchte ich die APEX-Welt verlassen und eine kleine, aber keine triviale Aufgabe in Bezug auf die Frontend-Programmierung beschreiben. Ich habe eine VisualForce Page, die als Suchmaske fungiert. Es gibt eine Hand voll Felder, die in einem Block mehrzeilig und mehrspaltig dargestellt werden. Insgesamt gibt es 3 Zeilen und 3 Spalten. Problem: die letzte Spalte wird auf die minimale Breite zusammengedrückt, so dass es einen Umbruch in den Feldbezeichnungen gibt. In meinem Konstrukt gibt es viele Felder mit Default-Werten. Aus dem Grund muss ich auf die einfache Darstellung eines Feldes  < apex:inputField value = "{!myObject.name}" />  verzichten. Statt dessen sieht der Aufbau eines Feldes so aus: < apex:pageBlockSectionItem >   < apex:outputLabel   value = "{!$ObjectType.myObject.fields.City__c.label}" />   < apex:inputText   value = "{!City}"   /> </ apex:pageBlockSectionItem > Lösung: di...

Die Entwicklung von VisualForce Seiten ist zwangsweise mit der Entwicklung von Apex-Controllern verbunden. Meistens greift man auf die Standard-Controller zurück und erweitert die Standard-Funktionalität wie z.B. "Save" oder "Close" um weitere Funktionen. Die neuen Funktionen werden in einer neuen Klasse entwickelt, die als " extensions " in die VisualForce Seite eingebunden ist, z.B. < apex:page standardController = "Lead" extensions = "LeadConvert" > Meistens muss entweder der aufgerufene Datensatz oder die mit diesem Datensatz verknüpften Datensätze modifiziert werden. Um eine Instanz des aufgerufenen Datensatzes zu erzeugen, stehen zwei Methoden zur Verfügung. 1) Klassische SOQL Methode: Lead  leadObj = [ Select id, name, Firstname, Lastname  from Lead where id =:idParameter limit 1]; in der " idParameter " zuerst berechnet werden muss: idParameter  = Apexpages.currentPage().getParameters(). get...

Beim Entwickeln und Testen einer neuen Funktionalität für Portal Benutzer, die Cases einstellen dürfen, bin ich auf ein interessantes Systemverhalten gestossen. Kurze Beschreibung: ein Portal Benutzer erstellt einen neuen Case. Das Feld "Account" bleibt leer, bzw. dieses Feld hat die Eigenschaft "Read only" für Portal Benutzer und ist somit nicht editierbar. Nach dem Speichern und dem erneuten Öffnen des Cases ist das Feld "Account" gefüllt. Recherche: ich war mir ziemlich sicher, dass hier ein Trigger im Spiel ist. Nachdem ich die Ressourcen untersucht habe, stellte ich fest, dass es keine programmierte Funktion gibt, die den Account berechnet und im Case abspeichert. Nach einigen Tests, unter anderem mit der neu entwickelten Funktion, war das Muster erkennbar: * ein Portal Benutzer impliziert die Existenz der beiden Datensätze "Contact" und "User" im System * ein Contact ist zwangsweise mit einem Account verknüpft => d...

Für einen Kunden habe ich einen Case Trigger entwickelt, der unter anderem den Case Owner überschreibt. Der neue Eigentümer ist eine Queue. Beim Testen stellte ich fest, dass alle Mitglieder der entsprechenden Queue mit jedem Eigentümerwechsel per Email benachrichtigt werden. Der Inhalt dieser Emails sieht so aus: Ticket 00075342 has been assigned to you. Please click on the link below to view the record. Wie kann ich diesen Email-Versand stoppen? Ich habe viel Zeit mit der Suche nach einer Lösung verbracht. Folgende Optionen habe ich ausprobiert. Die letzte Option (5) beschreibt die Lösung. 1) Die Eigenschaft "Notify Case Owners when Cases Ownership Changes" der Support Settings deaktiviert. => Die Deaktivierung der Eigenschaft hatte keine Auswirkung auf den Email-Versand. 2) Die Queue-Eigenschaft "Send Email to Members" deaktiviert. => Die Deaktivierung der Eigenschaft hatte keine Auswirkung auf den Email-Versand. 3) Die Implementierun...