I can’t even write to my FTP with Sandbox. It’s configured to go to my Azure File Share. Guess what, they only programed it for one or the other. Well I have both. When I told them that, they were like “We were told that was not possible.” And instead of adding the option, it will have to be chosen and configured on the backend.
1 Like
Communication. Something that was evidently lacking here. I understand both sides of this, but from a controls standpoint, no production code should EVER be updated without the proper development cycle to document the changes necessary to remediate the required changes. Just forcing it is unacceptable.
Communicating with @klincecum would have allowed for all of this to happen. And if it didn’t and his code no longer worked because of controls put in place on SaaS, then it would have been on him.
3 Likes
And Epicor could argue the same. If I’m a health care company sharing infrastructure, how can I guarantee another tenant doesn’t have access to my file system? This was a bigger deal with VMs but containers buy us some isolation, at the cost of ditching Windows for Linux.
If we were in control of the source, there would have been an issue filed and maybe a pull request with the proposed fixes. The owner could then accept or fix the request before deploying. This would be one way to improve the communication, which I agree wasn’t good in this situation.
1 Like
Yes, this would have probably made this a non-issue.
Coincidentally, I just read an article about how to deploy code in a way that respects the user. Great read.
1 Like
Same thing happened to me with three of my clients on the cloud.
The issue isn’t so much on them changing it - it’s them changing it with ZERO NOTIFICATION that they changed something. We can get into a good discussion of whether they should or should not be allowed to change the code - there’s good arguments on both sides. But I’d like to hear the arguments for them changing code in both a PILOT and PRODUCTION environment with ZERO NOTIFICATION.
I just went in and changed the code back - figured I’d deal with the Sandbox issue at a later date. Today’s that later date. Their statement
Sandbox.Compatibility.ConvertPath
(from their conversion) is now throwing a warning when saving in a Function:
warning CS0618: 'ICompatibility.ConvertPath(string)' is obsolete: 'Use FilePath instead.'
Tried finding some documentation on EpicWeb - nothing. So now, I’m putting in a ticket to ask for some documentation. I’m pretty sure I’ll get the standard response “you can talk to our custom solutions group”. Frustrating.
5 Likes
I would agree, isn’t it best practice to do all the changes in pilot, test, and then do them in live?
5 Likes
2 Likes
I just want to say, this wouldn’t be an issue if they actually corrected the code correctly. As it stands now, they insert that ConvertPath method everywhere, parenthesis are all out of whack, and half the time the code they modify doesn’t compile. Worst, even when it DOES compile, behavior is changed, silently! If you are going to modify the code and do a half assed job, then I would prefer it were not modified at all. Not to mention, they modify it on on-premise environments as well, where they have no business doing so.
I am pretty frustrated at this because as a consultant we are already spread thin doing all of the upgrades for all customers to be ready for 2026 as it is, the last thing I need is some half-working script corrupting perfectly fine code all over the GD place with no warning… AT LEAST they could have copied the code widget and keep the original code unmolested. Then I can just disconnect and delete the crappily modified version, and reconnect the original code…
We have lost SO MANY HOURS correcting all that crap recently…
4 Likes
They’re using their ‘Janky Code Review Tool’ 
2 Likes
When I spoke to support management about this, they claimed that none of our code should have gotten changed and they had no idea why that would have happened. I provided the conversion workbench logs, and before and after code as proof. They said they would look into it.
9 Likes
Obligatory reference… just imagine a bubble of Epicor Management much higher, but still disconnected.
3 Likes
Should we be asking at which point it starts to make sense for cloudies to deploy all custom code to 3rd party serverless functions outside of epicor servers? Azure Functions for example.
Use a true IDE, real SCM, and git deploy is a cinch. Your code is yours not theirs.
Having done but a handful of Epicor Functions, I have no clue on the dependencies or legal aspects. Assuming no blockers, maybe the trade offs are a net win. 
4 Likes
Skip all of that and simply use source control for free or next to no cost with GitHub. If something is changed, git has source diff - a minor investment of time.
1 Like
You mean like copy and paste your Fx code out to files or commit .efxj ? The former sounds like a burden and the latter has encoded C# body so diff is visually useless. But yeah something is better than nothing for SCM, we agree on that.
PS - I was thinking more along the lines of this for IDE/SCM experience. Plus possibly git-deploy to az functions, but now that I think of it, the perf on directives would be atrocious if such a thing is even possible.
We can access the raw code juice through the BOs, a function could be put to iterate all functions, build a collection of strings and some metadata to represent them, and export to a folder structure of .cs files and save out to zip file for download/upload.. make syncing to source control a few clicks.. i don’t know if the abstracted Sandbox.IO functions give us enough control to set date/time modified on the created files, but that’d be nice..
2 Likes
Yeah I’m pretty sure @klincecum was working that into his ExportAllTheThings if not already there.
I agree with you gentlemen. Being able to export a source representation of customizations is helpful in finding differences, etc. Where the real power of having source control is with deployment. But we don’t have a way (easy anyway) to take our exported representations and importing them back into Kinetic.
One possibility is to add the exported file to git but also “explode it” to a text representation and save that with the export file. When it’s time to deploy, we still have the exported file and use that to deploy the artifact.
This leads to questions about instance management. We should be able to deploy to various instances and keep track. We should have a commit ID that is used inside Kinetic to know which version of a customization was deployed. Also, how could we use branch names to help with feature/instance management?
It’s a big topic and it’s good to get it started with source control, but there’s more work ahead of us.
3 Likes