• KevinShuk
  • NEWBIE
  • 50 Points
  • Member since 2010

  • Chatter
    Feed
  • 2
    Best Answers
  • 1
    Likes Received
  • 0
    Likes Given
  • 5
    Questions
  • 4
    Replies
Does anyone know how to customize the layout of the Quote PDF output?  I need to hide a column, as well as add some additional text before we can use it in production, but can't find where I can do this.
  • March 09, 2010
  • Like
  • 0

The documentation for javascript remoting says, "Your method can take Apex primitives as arguments," and I'd like to pass a Javascript Date into my remoted function. Javascript Date has a time component, so it's analogous to an Apex DateTime.

 

However, when I pass in the Date from javascript calling my remoted function, the remoting javascript code throws an exception complaining that I'm not passing in a DateTime but rather the time as an ISO string. 

 

I noticed that in the opposite direction, DateTimes get marshaled as an integer of the number of milliseconds since the epoch (Jan 1, 1970), which javascript can use in a Date constructor, so I tried passing that in for the DateTime arg, but it still complained.

 

Is there a way to pass a Javascript Date directly to a remoted function as an Apex DateTime??

 

My workaround in the meantime was to accept the Date as an ISO string, replace the "T" with a space, and use the result to construct the Apex DateTime with DateTime.valueOf. It'd be nice to be able to skip this, though. 

 

Thanks,

--Kevin

I believe I already have this figured out, but I wasn't able to find definitive instruction on this in the Apex docs nor the boards, so I wanted to post this to hopefully help someone else and to see if anyone can further clarify this. The example code below is contrived and is just to illustrate what I've seen. 

 

First, I have a custom object named My_Object__c with a custom Text field named Private_Field__c. Through field level security, this field is not visible to any profile.

 

Next, I have a custom visualforce controller defined without sharing. To give a very rudimentary example:

 

 

public without sharing class MyObjectController {
     public My_Object__c myObject { get; private set; }  

     public MyObjectController() {
          queryMyObject('a01000000000001');
     }

     public queryMyObject(Id myObjectId) {
          myObject = [select Id, Name, Private_Field__c 
                         from My_Object__c 
                         where Id = :myObjectId];
          System.debug(myObject);
     }
} 

 

 

On my visualforce page, if I access the field directly through the sobject property, the value will not display:

 

<apex:page controller="MyObjectController">
myObject's Private Field Value: {!myObject.Private_Field__c}<br/>
</apex:page>

 

 

When I access the page, it is as though the sharing is once again applied to this field. The merge field yields no value. Looking at debug logs, however, I can see that I'm seeing the value for Private_Field__c in the controller when queryMyObject is called.

 

If I add a property to the controller class to return the field, however, I'm able to access it in the page:

 

 

public without sharing class MyObjectController {
     public My_Object__c myObject { get; private set; }
     String privateField { get { return myObject.Private_Field__c; } } // added this property 

     public MyObjectController() {
          queryMyObject('a01000000000001');
     }

     public queryMyObject(Id myObjectId) {
          myObject = [select Id, Name, Private_Field__c 
                         from My_Object__c 
                         where Id = :myObjectId];
          System.debug(myObject);
     }
} 

 Accessing the field property instead of accessing the field directly from the sobject property works:

 

 

<apex:page controller="MyObjectController">
myObject's Private Field Value (direct access): {!myObject.Private_Field__c} (this still won't work)<br/>
myObject's Private Field Value (property access): {!privateField} (this works!)<br/>
</apex:page>

 

My questions here are:

 

Is this documented anywhere? I couldn't find explanation of this specific behavior in the apex code dev guide or the visualforce dev guide.

 

What if I need system access to a collection of child objects? Do I have to wrap them all in objects of a class defined without sharing, and provide accessor properties for each field I want to access?

 

I would have thought that I could access the fields of the sobject property freely since the containing class was defined without sharing, but my guess is that sobject classes are all defined with sharing.

 

 

I'm wondering what all setting the "wizard" attribute of apex:page to true will do for me? The only thing that the visualforce reference mentions is that this is "A Boolean value that specifies whether the page should use the style Boolean of a standard Salesforce wizard page. If true, wizard styling is used. If not specified, this value defaults to false." The wizard example in the VF reference doesn't use this style, so it's not much help. Searching the boards finds 700+ hits, but none that I've read so far address this attribute.

 

Clearly it changes the style of the page. I can use standard styling of elements, but the header has no links or tabs that could take someone out of the wizard.

 

It also creates a blue bar, about a centimeter high with rounded corners that spans most of the width of the page - it seems like I might be able to put things (navigation buttons?) in it.

 

Does anyone have experience or information to share on this attribute? Is it just visual, or are there some other features of the wizard look that we can modify?

 

Thanks,

--Kevin

 

 My name is Kevin Shuk, and I'm a Force.com developer with Palantir Technologies.

Silicon Valley has been missing a Force.com Developer's Group of its
own - Mike Fullmore, Senior Software Engineer at Salesforce.com and I
aim to fix this. After all, the birthplace of the technology age and
the hottest DaaS platform out there are a natural fit! We're
definitely aiming for a more technical angle here - Apex code,
Visualforce, the Apex API and integrations, for example.

We're pulling together the first meeting rather quickly as we're
aiming to meet on Thursday, March 25 in the early evening (an exact
time hasn't been set yet). Adobe Systems has graciously offered a space for
us to meet in their downtown San Jose headquarters, and Markus Spohn,
Director of Product Management at Salesforce.com will present the
Adobe Flash Builder for Force.com. We'll also touch on new features
for developers in Spring '10 now that it's rolled out, and cover some
other tips and tricks.

Please RSVP for this meeting or express your interest in future
meetings of this group by completing a quick online signup at
http://www.surfous.com/svfdcdev
Even if you can't make the 25th, please sign up if you'd like to know
about future meetings, or have suggestions for topics you'd like to
learn about or present.

Specific details of this first meeting will be posted here early next
week as well as sent to those who RSVPd for the meeting.

Hope to see all you devs there!

Hi all,

 

Like most of you, I'm aware of the recent changes to opportunity save behavior where changes to products cause workflow rules, triggers, etc on the parent opportunity to be evaluated again. Regarding workflow rules, my understanding is that they will be evaluated more often, but that the resultant actions are still subject to the evaluation criteria as well as the rule criteria. 

 

Here is the scenario - a workflow on an opportunity has the eval criteria of "When a record is created, or when a record is edited and did not previously meet the rule criteria." The rule criteria are "StageName equals Closed Won", "Opportunity Name does not contain Test" and "Account Name does not contain Test"

 

When an Opportunity is moved to Closed Won, and neither it not its account have "Test" in their names, then the rule evaluates and the actions fire - this much is correct. 

 

The problem is that if the pricebook is changed, the rule will not only be evaluated again, but the actions will fire again even though the rule criteria have previously been met, and switching pricebooks does not visibly affect the rule criteria. Further, adding or changing products on this opportunity does not cause the rule actions to fire again, nor does editing the opportunity itself, say, changing the description. Only changing pricebooks causes the behavior I describe.

 

This behavior feels like a bug because the events are contrary to the eval criteria of,  "When a record is created, or when a record is edited and did not previously meet the rule criteria," because the rule criteria have already been met and the edit in question does not seem to affect those criteria.

 

I'm going around with SFDC support on this, and we're still at the stage where the analyst looking at this issue is confusing rule evaluation with the actions firing. They're initially blaming this on the new oppty save behavior, but I don't think that explains the whole issue. So, I pose the question to you: I say it's a bug - what do you think? 

The documentation for javascript remoting says, "Your method can take Apex primitives as arguments," and I'd like to pass a Javascript Date into my remoted function. Javascript Date has a time component, so it's analogous to an Apex DateTime.

 

However, when I pass in the Date from javascript calling my remoted function, the remoting javascript code throws an exception complaining that I'm not passing in a DateTime but rather the time as an ISO string. 

 

I noticed that in the opposite direction, DateTimes get marshaled as an integer of the number of milliseconds since the epoch (Jan 1, 1970), which javascript can use in a Date constructor, so I tried passing that in for the DateTime arg, but it still complained.

 

Is there a way to pass a Javascript Date directly to a remoted function as an Apex DateTime??

 

My workaround in the meantime was to accept the Date as an ISO string, replace the "T" with a space, and use the result to construct the Apex DateTime with DateTime.valueOf. It'd be nice to be able to skip this, though. 

 

Thanks,

--Kevin

The documentation for javascript remoting says, "Your method can take Apex primitives as arguments," and I'd like to pass a Javascript Date into my remoted function. Javascript Date has a time component, so it's analogous to an Apex DateTime.

 

However, when I pass in the Date from javascript calling my remoted function, the remoting javascript code throws an exception complaining that I'm not passing in a DateTime but rather the time as an ISO string. 

 

I noticed that in the opposite direction, DateTimes get marshaled as an integer of the number of milliseconds since the epoch (Jan 1, 1970), which javascript can use in a Date constructor, so I tried passing that in for the DateTime arg, but it still complained.

 

Is there a way to pass a Javascript Date directly to a remoted function as an Apex DateTime??

 

My workaround in the meantime was to accept the Date as an ISO string, replace the "T" with a space, and use the result to construct the Apex DateTime with DateTime.valueOf. It'd be nice to be able to skip this, though. 

 

Thanks,

--Kevin

 My name is Kevin Shuk, and I'm a Force.com developer with Palantir Technologies.

Silicon Valley has been missing a Force.com Developer's Group of its
own - Mike Fullmore, Senior Software Engineer at Salesforce.com and I
aim to fix this. After all, the birthplace of the technology age and
the hottest DaaS platform out there are a natural fit! We're
definitely aiming for a more technical angle here - Apex code,
Visualforce, the Apex API and integrations, for example.

We're pulling together the first meeting rather quickly as we're
aiming to meet on Thursday, March 25 in the early evening (an exact
time hasn't been set yet). Adobe Systems has graciously offered a space for
us to meet in their downtown San Jose headquarters, and Markus Spohn,
Director of Product Management at Salesforce.com will present the
Adobe Flash Builder for Force.com. We'll also touch on new features
for developers in Spring '10 now that it's rolled out, and cover some
other tips and tricks.

Please RSVP for this meeting or express your interest in future
meetings of this group by completing a quick online signup at
http://www.surfous.com/svfdcdev
Even if you can't make the 25th, please sign up if you'd like to know
about future meetings, or have suggestions for topics you'd like to
learn about or present.

Specific details of this first meeting will be posted here early next
week as well as sent to those who RSVPd for the meeting.

Hope to see all you devs there!
Does anyone know how to customize the layout of the Quote PDF output?  I need to hide a column, as well as add some additional text before we can use it in production, but can't find where I can do this.
  • March 09, 2010
  • Like
  • 0

Hi all,

 

Like most of you, I'm aware of the recent changes to opportunity save behavior where changes to products cause workflow rules, triggers, etc on the parent opportunity to be evaluated again. Regarding workflow rules, my understanding is that they will be evaluated more often, but that the resultant actions are still subject to the evaluation criteria as well as the rule criteria. 

 

Here is the scenario - a workflow on an opportunity has the eval criteria of "When a record is created, or when a record is edited and did not previously meet the rule criteria." The rule criteria are "StageName equals Closed Won", "Opportunity Name does not contain Test" and "Account Name does not contain Test"

 

When an Opportunity is moved to Closed Won, and neither it not its account have "Test" in their names, then the rule evaluates and the actions fire - this much is correct. 

 

The problem is that if the pricebook is changed, the rule will not only be evaluated again, but the actions will fire again even though the rule criteria have previously been met, and switching pricebooks does not visibly affect the rule criteria. Further, adding or changing products on this opportunity does not cause the rule actions to fire again, nor does editing the opportunity itself, say, changing the description. Only changing pricebooks causes the behavior I describe.

 

This behavior feels like a bug because the events are contrary to the eval criteria of,  "When a record is created, or when a record is edited and did not previously meet the rule criteria," because the rule criteria have already been met and the edit in question does not seem to affect those criteria.

 

I'm going around with SFDC support on this, and we're still at the stage where the analyst looking at this issue is confusing rule evaluation with the actions firing. They're initially blaming this on the new oppty save behavior, but I don't think that explains the whole issue. So, I pose the question to you: I say it's a bug - what do you think?