Another little, but hopefully useful, quick tip to ease Dynamics portal deployment pains.
I used to get a load of errors when using the Portal Data Mover in the (awesome) XrmToolBox to move portal config from dev to test, specifically when moving records from the Web Files entity.
The problem was that, by default, files with a .js extensions are blocked when being loaded to Notes in D365, which is where the binary content of all js files are stored.
This unfortunately means when you migrate portal configuration from one instance to another (e.g. dev to test), the Web File annotations fail to load.
To rectify this:
- In your target CRM instance, navigate to Settings > System Settings > General Tab > Set blocked file extensions for attachments
- Remove “.js;” from the delimited list of blocked extensions
Some thoughts on this to perhaps ease those worried about turning off an out of box security measure:
- The block is only enforced on initial upload. Re-enabling the block won’t purge js files already in your system. So you could always have a deployment task to disable the block, run the migration/deployment and then re-enable.
- From my, admittedly limited, testing both portals, and Dynamics in general, seem quite robust in its handling of injected code and potential xss attacks. But of course it does also depend on whatever custom processing you do on these files thereafter.
- Best I think though, and this is normally my preferred route if feasible, try not to store any js files or libraries in CRM at all. The development, deployment and testing paths unfortunately leave a lot to be desired so why bother. Instead, host your js in a CDN and reference that in your Web Templates so you can develop and test in a more traditional way without the all too regular “copy and paste” or “upload and test” scenarios we see in Dynamics development.
Hit me with a comment if you have questions or other/better alternatives! 🙂