Sign Up ›
  • JV100
  • NEWBIE
  • 10 Points
  • Member since 2011
  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 0
    Questions
  • 4
    Replies
17 replies

Why you might get OP_WITH_INVALID_USER_TYPE_EXCEPTION from a trigger

Posting this in order to help others who, months from now, might Google "OP_WITH_INVALID_USER_TYPE_EXCEPTION" and find this explanation.

 

We wrote an Apex trigger on the User object, to insert a custom object record anytime a user updates their Chatter status.  This was done to fulfill a client's requirement to audit all Chatter activity.

 

The trigger worked fine, until one day the client signed up some Chatter Free users.  When such a user tried to update their status, they got a pop-up with an OP_WITH_INVALID_USER_TYPE_EXCEPTION error.

 

We scratched our collective heads for awhile.  After all, Apex triggers run in "system mode," right?  That is supposed to mean that "object and field-level permissions of the current user are ignored."  And yet this trigger seemed like it was running in "user mode," enforcing restrictions based on who the current user was.

 

The root cause turned out to be that a Chatter Free user cannot be the owner of a custom object record, and SFDC by default sets the current user as a new record's first owner.  We discovered this when we realized, via experiment, that Apex triggers fired as the result of actions by Chatter Free users could definitely update an existing record, but were having problems creating records.

 

So the simple solution was to explicitly set the owner of the new record to some fully-licensed user prior to inserting it.

7 replies

Looking for experienced SF architect/consultant/developer in or around Waltham, MA

We need someone who can audit a current (broken) process, recommend a more elegant solution and potentially implement it. Ideally this person would work on site for 3-5 weeks.

 

Future projects are definitely a possibility.

SOLVED
55 replies

Unable to refresh resource...

Hi,

Am unable to refresh any of the resources in the IDE from the server.

When am trying to refresh a page from the web, getting an Exception saying:

 

 

Unable to refresh resource 'MileaeExension.cls':
com.salesforce.ide.api.metadata.types.Metadata$JaxbAccessorF_fullName cannot be cast to com.sun.xml.bind.v2.runtime.reflect.Accessor

 

Unable to refresh resource 'MileaeExension.cls':


com.salesforce.ide.api.metadata.types.Metadata$JaxbAccessorF_fullName cannot be cast to com.sun.xml.bind.v2.runtime.reflect.Accessor

 

Please assist to rectify the issue. 

 

Thanks in advance,

VNath

10 replies

PDF generation hangs

 

 I have a program feature that generates PDF documents via the standard Visual Force 'renderAs="PDF"' mechanism. This feature does not work reliably for 'larger' documents (i.e. 50 pages). By 'reliably' I mean that I can run PDF generation 10 times, and it will work successfully 3-5 times out of these 10. The rest of the time, after a 3+ min delay, I get the following error message:

"PDF generation couldn't complete because the request took too long. You are using components that are not fully supported by PDF generation, please consult the documentation for a list of unsupported components."

I've reviewed the page (it's a long and ugly beast, so am not posting it here), but am not seeing anything unsupported or suspicious.  This test can be run on the exact same object, with the exact same data, 10 times in a row, and the results are non-deterministic.   The fact that it works for some runs, but not others makes me suspect that this doesn't have to do with any specific page markup, but I could be wrong.

When I look at the system log output, I see that the controller code for this page is done after 12-15 sec. After that, there's a long delay--when the PDF is rendered successfully, the delay is about 30-40 sec. When it fails, as above, it is 3+ min.

It appears that something is making the PDF rendering engine go haywire, but I have not been able to figure out what it may be, and therefore, how to work around it.

If you have the system log open, you can see that the last statement from the controller (CODE_UNIT_FINISHED|StaticResourcePick <init>) is usually executed a long time before the CUMULATIVE_LIMIT_USAGE line. 

 

 

Does anyone have any ideas/suggestions?