SalesForce comes crashing down. Again !

I first read about this last Friday. Beloved cloud CRM solution had a data breach, and fixed it by removing all security features.

It seems the US tech giant granted Pardot customers access privileges they should not have, which is to say access to everything and alter any data. As was observed on Reddit, "One of our projects had all its profiles modified to enable modify all, allowing all users access to all data."

To deal with the mess, Salesforce's IT team has denied all access to more than 100 cloud instances that host Pardot users, shutting out everyone else using those same systems, whether or not they were using Pardot.

And the outage continued on Monday. Over the weekend, Salesforce staff developed, tested, and ran a script that attempted to restore user permissions from backups, though this was not always successful. In some cases, it even went backwards, and regranted full read-write permissions to users.

Timeline

- A dodgy database script on Friday gave all current and past Pardot users sysadmin-level create-read-write-delete access to all data, which is a huge security and privacy blunder.

- Instances running Pardot were disabled to avoid any data theft or tampering, which kicked any customers using those instances – Pardot and non-Pardot – off Salesforce.

- Salesforce removed all access permissions from affected users and restored full permissions to customers' administrator accounts, allowing them to repair users' permissions. Some instances were fired back up so folks could log back in, others remained offline. Admins were encouraged to reassign their users' access permissions by hand to allow users to continue working.

- On Saturday, Salesforce was able to restore previous user permissions from a backup using a script on one instance of 105 affected.

- By Sunday, the permission restoration script had been run on the majority of instances, repairing user permissions with an "89 per cent" success rate – meaning about one in ten organizations still had their user rights wiped. Admins were told, if they still had permission issues, to fix it themselves or contact Salesforce support.

- On Monday, Salesforce staff are still working to restore sandboxed instances. We're told GovCloud was not affected by the snafu.

So if you are contemplating moving to the cloud, now will be…a good time ?

BIP: Number to Text , complex version

Oracle never ceases to amaze me. I recently saw this question being asked again on stackoverflow.

Basically, this is an RTF template supposed to print a check. And the amount has to be converted to text, to be printed on the 'Amount' line on the check. BIP provides a function for this called xdofx:to_check_number.
It is documented over here. The function can print the output text in different locales, and decimal number settings. But the number to be printed has to be in an XML node. It only accepts simple XPATH notations, and the value itself cannot be a result of a sum() function, or the result of any mathematical operation.
Which means, if you have an XML like this:

<root>
     <amt>3243243</amt>
     <amt>6436464</amt>
     <amt>243</amt>
     <amt>445454</amt>
     <amt>67676</amt>
</root>

And you want to print the output as the sum of all the 'amt' elements, that cannot be done.

<?xdofx:to_check_number(sum(amt),'EUR')?>

Outputs:

Zero and xx/100



Which leads me to say: WTF Oracle ?

I had solved this problem years ago, but I couldn't remeber how. So I deep dived, again, into the same problem.


Using the RTF template, I exported the XSL-FO stylesheet out:

This extracts the intermediate XSL file BIP uses to generate the final report output.
Search for "to_check_number" in this XSL:

It can be seen that although there is a for-each loop there, the template itself is not called recursively.  It access the element 'amt' without a proper XPATH, and then does a stupid (.///)[1]  whatever that means.

But if you pass a string with the number into the function to_check_number, this works out perfectly.


For the foe-each loop to sum up all the values, it has to call itself recursively. Obviously, this function is broken.

But is there a way to fix this ?

Turns out, there is. Look two lines lower in the XSL file.



It can be seen that the XSL finally invokes another hidden function xdoxslt:toCheckNumber. This namespace is unique, I am guessing it is shared between the XSL and XDO name spaces.

So I tried using this 'hidden' function directly in the template.

Like this:

<?xdoxslt:toCheckNumber($_XDOLOCALE, sum(amt), ('EUR'))?>

Which produces the output:

Voila !!

So in case you have to convert a dynamically generated number to text, use the toCheckNumber function directly.

Which leads to the question, why have the xdo function in the first place ?

But do bear in mind, that this is an undocumented function, which works for now.