Hello all!

I have a scenario where I want to use the Power of 1 functionality in a custsom object to count how many checkboxes are checked when i run a custom report. Any help on setting this up from A-Z is greately appreciated! Thanks in advance!

Custom Object Name: Atmosphere

Custom API Checkbox Field Name: Traveler

I think there's a bug in this module - the requirements state that the sales executive profile "can create reports and lists for their own needs, but can’t share them with others, except through the Unfiled Public Reports folder." However, the Set Up Reporting challenge (step 5) won't pass if the Sales Executive User profile has Create and Customize Reports enabled.

I downloaded it this afternoon (6/25, around 2.30p Pacific time), before I knew what it was for. I've got to Step 2 in the challenge, created the user and opportunitites, but I can't run the tests because . . . there were no tests in the package.

For reference, here's a screenshot of the package components. Am I missing something?

Hi All,

In attempting to compile the first test class provided in the 'Explore Custom Transaction Security Policies' module, I receive 2 compile errors.

The first was around line 29, where the semi colon beside eventData needs to be moved outside of the right parenthesis.

However after trying to compile after that change there is another error complaining that the platform field of the LoginHistory object (declared as loginHistoryObj for our instance) is not writeable.  Below are the lines of importance...

    /* Create a history object that has Platform = Android 4. */
    LoginHistory loginHistoryObj = new LoginHistory();
    loginHistoryObj.Platform = 'Android 4';  <---- this is where the compile is complaining (Error: Compile Error: Field is not writeable: LoginHistory.Platform at line 7 column 5)

I checked the LoginHistory Object documentation, and it looks like it should be writeable to me.

Does anyone have any suggestions? or is this a bug of some sort?

I think there's a bug in this module - the requirements state that the sales executive profile "can create reports and lists for their own needs, but can’t share them with others, except through the Unfiled Public Reports folder." However, the Set Up Reporting challenge (step 5) won't pass if the Sales Executive User profile has Create and Customize Reports enabled.

I downloaded it this afternoon (6/25, around 2.30p Pacific time), before I knew what it was for. I've got to Step 2 in the challenge, created the user and opportunitites, but I can't run the tests because . . . there were no tests in the package.

For reference, here's a screenshot of the package components. Am I missing something?

Hello all!

I have a scenario where I want to use the Power of 1 functionality in a custsom object to count how many checkboxes are checked when i run a custom report. Any help on setting this up from A-Z is greately appreciated! Thanks in advance!

Custom Object Name: Atmosphere

Custom API Checkbox Field Name: Traveler

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.