In our org, we have two users whose records are returned twice when called via APEX, or via the API.
If this SOQL is executed:
Selected Id, LastViewedDate, LastReferencedDate from User where Id='005xxxxxxx'
is executed in our org, you can see where the same result is returned twice. In fact, if you include a "limit 1" on the end of that SOQL query, it STILL returns those two, identical results.
If both LastViewedDate and LastReferencedDate are removed from the query, only one result is returned for each record, which is the expected, normal behavior.
I've been working with OAuth for a ruby app off and on for a year or so, and just today took it up again. I had, many months ago, created a remote access application in one of my sandboxes or dev orgs, and had put the client id and secret keys into my omnioauth strategy file. Since that time, I've deleted that remote access application.
What concerns me is that, upon running my ruby app with the old (presumably defunct) id an secret, I was able to get a token from this deleted app. I would expect that I shouldn't be able to do that. Worse still, is that I could get a token regardless of the org I was logged in to! To be clear, I could of course only see the data for the org I was logged in to, but the fact remains that an id and a secret from a delete remote access app on Org A served to give me access to not only Org A (after logging in there), but Org B (after logging in to Org B), and Org C (after logging in to Org C).
So my questions:
1: Why does a deleted remote access app still give out tokens?
2: Why does that same app, regardless of the answer to question 1, give out tokens to multiple orgs? - EDIT - OK, I see after looking around that this is relatively normal. That is SFDC doesn't partition by org. Question 1 still stands, though.
This is a post with a bunch of very closely-related questions. First, the general problem:
We've got an Apex method grabing a bunch of Attachments, and putting their body and data into a bunch of EmailFileAttachments, which are then sent right out. This method has worked great for over a year, without a single error. Just this past weekend, though, we started to get a bunch of these errors:
Query of LOB fields caused heap usage to exceed limit.
We've narrowed it down, and figured out that any group of Attachments with total body size of over 3MB or so is causing this error. So these are the questions.
1: Why are we just now starting to get this error, when in the past I know we've sent up to 9 or 10MB worth of attachments? Is it something to do with Winter 12, which just hit this org this weekend?
2: Why, in the past, have we been able to queue up 10MB worth of attachments and send them without running into the 3MB heap size limit?
3: Why are we having trouble with 3MB now, when it seems like the heap size has been increased to 6MB? (6MB would still be a problem, of course, as we should be able to send 10MB worth of email attachments.)
Here's the code. The exception is occuring right at the SELECT:
Messaging.EmailFileAttachment[] attachments=new List<Messaging.EmailFileAttachment>();
for (Attachment a:[select id, body, contenttype, name from Attachment where id in :selectedAttachmentIds]) {
Messaging.EmailFileAttachment ef=new Messaging.EmailFileAttachment();
ef.setBody(a.body);
ef.setContentType(a.ContentType);
ef.setFileName(a.name);
ef.setInline(false);
attachments.add(ef);
}
I've built a simple, unauthenticated web service in Sinatra, running on Heroku, that takes a list of attachment Ids, uses OmniAuth and the databasedotcom gems to authenticate into SFDC and access the attachements. Once I've downloaded them, I zip them up, and send them back to the requestor.
Doing this straight from the browser works great: type in the REST url, watch the webservice redirect me to SFDC, where I can enter my SFDC credentials. (Or, if I'm already logged in to SFDC in another window, I don't even have to enter them). Once I'm authenticated, I'm redirected back to Heroku, where the attachments are pulled down and zipped up.
Great. Things look good. But now I'm trying to build this functionality into the Apex app I'm writing, and I hit a wall from the git-go. HTTPRequest doesn't like redirects. Looking at the debug log, the whole process just stops with that first 302.
I can't believe I'm the first one try and consume external RESTful services that redirect, but I can't find any references to this problem elsewhere. Any help would be appreciated.
I've got a workflow that will send out an email after 1 hour if a particular set of conditions are met. To simplify, let's say the workflow formula is
fieldA__C==1 && ISPICKVAL(fieldB__c,"Location B")
I can successfully get the email sent after an hour when I set fieldA__C to 1 and fieldB__c to "Location B". What I want, though, is for that email to NOT go out if the workflow formula evaluates to false after the email is already been queued. That is, the workflow evaluates to true, and queues up the email. Then I change, say, fieldA__c to 2. I was under the impression, from reading the help docs, that this would dequeue the pending email. Real-life experiments seem to indicate otherwise, though, as I still get the email.
Any input would be appreciated.
BTW - Here's the relevant section from the help docs:
"Time-dependent actions remain in the workflow queue only as long as the workflow rule criteria are still valid. If a record no longer matches the rule criteria, Salesforce removes the time-dependent actions queued for that record. "
In our org, we have two users whose records are returned twice when called via APEX, or via the API.
If this SOQL is executed:
Selected Id, LastViewedDate, LastReferencedDate from User where Id='005xxxxxxx'
is executed in our org, you can see where the same result is returned twice. In fact, if you include a "limit 1" on the end of that SOQL query, it STILL returns those two, identical results.
If both LastViewedDate and LastReferencedDate are removed from the query, only one result is returned for each record, which is the expected, normal behavior.
I have the following VF page that is called by a button on a Person Account record.
<apex:page standardController="Account" title="Cancel Account">
<apex:sectionHeader title="Cancel Account"/>
<apex:form id="theForm">
<apex:pageBlock id="theBlock">
<apex:pageBlockSection id="sectionOne">
<apex:outputField value="{!Account.Name}" />
<!-- Bound to Date Field -->
<apex:inputField value="{!Account.Account_Cancel_Eff_Date__c}" />
<!-- Bound to Picklist -->
<apex:inputField value="{!Account.Account_Cancel_Reason__c}" />
</apex:pageBlockSection>
</apex:pageBlock>
</apex:form>
</apex:page>
When the page is called for a person account, Salesforce returns:
Validation Errors While Saving Record(s)
There were custom validation error(s) encountered while saving the affected record(s). The first validation error encountered was "Record Type ID: value not valid for the entity: Account".
When the page is called for a normal Account, it renders as expected. If I remove the inputField that is bound to the picklist, then call the page for a person account, everything works as expected. What's going on here?
