Function and Function Library become read-only?

[SAD (Sergey Davydkin)]

@Mark_Wonsil

More and more development for Epicor has been going to 3rd parties: Electronic Warehouse, Super Advanced Project Management Plus

In general, it was the main reason why library installation works as it works in 10.2.700. EFx is for 3rd parties in the first place, and most of them want to protect their IP. Especially in the case of cloud.

[SAD (Sergey Davydkin)]

@hkeric.wci

I think ultimately perhaps it shouldnt lock it unless someone clicks the Encrypt Source Code in SW checkbox. Just a thought.

Regarding Encrypt Source Code option… I doubt that it affects EFx, since EFx export does not contain source code (except snippets inside workflow or code-based functions). So nothing to encrypt there

[Mark_Wonsil]

@SAD

where settings file looks like

Any thoughts on replacing that with the new secrets management capability coming to PowerShell soon?

Secrets Management Development Release | PowerShell Team (microsoft.com)

The users need to know how to use this for API keys too. It’s just something we should teach users now to prevent passwords from being embedded into source codes, etc.

[SAD (Sergey Davydkin)]

@Mark_Wonsil

Any thoughts on replacing that with the new secrets management capability coming to PowerShell soon?

It sounds like a good approach, unfortunately, I just have no time to play with it. I implemented this script when we started testing EFx via REST. To simplify my QAs live.

So, if someone modifies the script and shares its updated version, it will be interesting to me too

[josecgomez]

By the way I went back and RTFM (again) and this is indeed documented in the Function Manual in the Epicor Help. All changes to Installed Functions (via Solution Workbench) must be made by re-installing the solution the only thing that can be changed is company mapping and enable / disable.

We (the collective we) just suck at keeping up with that thing hehe! ( the manual that is)

[SAD (Sergey Davydkin)]

@Mark_Wonsil

The users need to know how to use this for API keys too. It’s just something we should teach users now to prevent passwords from being embedded into source codes, etc.

Missed this statement. Unfortuantely, Epicor API-key is not a replacement for user/password
As for me, it is a kind of claim

[SAD (Sergey Davydkin)]

@josecgomez

We (the collective we) just suck at keeping up with that thing hehe! ( the manual that is)

Most unclear things are described in the documentation. At least I tried to control that.
Definitely, we could forget something…

[Mark_Wonsil]

@SAD

Epicor API-key is not a replacement for user/password

Right, but API-Keys shouldn’t be embedded in scripts/code. Sorry that’s what I was trying to say but not very well.

[SAD (Sergey Davydkin)]

@Mark_Wonsil

Right, but API-Keys shouldn’t be embedded in scripts/code.

In such a case, I completely agree with you!

Sorry that’s what I was trying to say but not very well.

Or the problem is in my understanding

[jgiese.wci (Joshua Giese)]

@josecgomez

So please keep that in mind. If you (we) are unhappy with a particular feature we should take action via the appropriate channels (support / ideas portal) to correct it. Once we have determined that it is or isn’t a bug.

Or write around the issue because… well that’s the beauty of Epicor and its flexibility. What one person cares about another does not #WipIsGarbage

[krum (Kevin Krumwiede)]

Solutions have so many bugs that we completely stopped using them. If I develop something in our test environment, I rewrite it in production by hand.

[hkeric.wci (Haso Keric)]

@krum

If I develop something in our test environment, I rewrite it in production by hand.

For us at a Publicly Traded company… We dont get access to Production, only DEV/TST. So we use Solution Workbench and have had no issues for about 7yrs now, a few minor bugs here there but for most part it works.

[krum (Kevin Krumwiede)]

I’ve encountered things like solutions building without error, but containing nothing; changes being applied on the target system but the solution name not being added to the list of installed solutions, creating confusion; and things that are more limitations than bugs, like solutions being unable to contain certain kinds of changes, like the removal of a custom field.

[Edge (Stephen Edginton)]

Thanks everyone for the debate here, we will explore options here as we balance the needs of different use cases.

[caleb.grundmeier]

@SAD

In general, it was the main reason why library installation works as it works in 10.2.700. EFx is for 3rd parties in the first place, and most of them want to protect their IP. Especially in the case of cloud.

I don’t like to reference other software vendors functionality because I hope Epicor already knows this but… in the Salesforce world, this is called a managed vs unmanaged package(similar to a solution) where the managed code is hidden and can’t be tampered with when installed into an environment. An unmanaged package can viewed and/or modified. Vendors/Developers have the choice when they create the package.

[SAD (Sergey Davydkin)]

EFx supports both scenarios (actually it supports 3 different scenarios). SW does not yet.
As I wrote, stay tuned.

[Edge (Stephen Edginton)]

The next release has an option when adding functions to solution workbench that allows you to define if you want to install or import the function library. Installed functions can be used and called but not edited, imported can be edited.

We recognize we should have probably defaulted to import not install where we did not give the choice but I hope this helps realign expectations.
Thanks all for the continued feedback.

[fuji36 (Bill Jackson)]

Thank you Edge for the info

[josecgomez]

Thank you @Edge much appreciated!!!

[AndrewM (Andrew)]

@Edge

The next release

That gets my support. I hate to be ‘that guy’, but just wondering which release you’re considering next release? Is it 11.1.100?