Issue #602

[RubenHalman]

#602

@VinceFINET This PR is my attempt at implementing the integration based on your earlier feedback. My understanding of the requirements may be limited, so there could be some misinterpretations, please let me know if anything needs adjustment. Any additional guidance would be greatly appreciated!

Integration Points

1. Flow Dataset (../dataset/orgcheck-api-dataset-flows.js)

   • Calls LFSScanner.scanFlows() after retrieving flow metadata
   • Applies violations before score computation

2. Score Rules (../core/orgcheck-api-secretsauce.js)

   • Defines rule IDs 100-125 for LFS violations
   • Maps to OrgCheck categories (Code Quality, Security, Documentation, etc.)

LFS Rule Mapping

LFS Rule	OrgCheck ID	Category	Replaces OrgCheck Rule
InactiveFlow	100	Useless	Rule 35
ProcessBuilder	101	Useless	Rule 37
FlowDescription	102	Documentation	Rules 38, 53
APIVersion	103	API Version	Rules 39, 4
UnsafeRunningContext	104	Security	Rule 40
SOQLQueryInLoop	105	Code Quality	NEW
DMLStatementInLoop	106	Code Quality	NEW
ActionCallsInLoop	107	Code Quality	NEW
HardcodedId	108	Hard-coded IDs	NEW
HardcodedUrl	109	Hard-coded URLs	NEW
MissingNullHandler	110	Code Quality	NEW
MissingFaultPath	111	Code Quality	NEW
...	112-125	Various	NEW

Integration Summary

• +26 LFS rules (IDs 100-125) scanning in parallel
• +21 unique new checks not previously covered by OrgCheck
• OrgCheck unique capabilities preserved:
  • Rules 0, 3: Dependency tracking (exclusive to OrgCheck)
  • Rule 36: Version proliferation (>7 versions)
  • Rule 41: Simple node count (>100 nodes)

[VinceFINET]

Hello

thank you for your effort on this.

First comment: i don't see the point having duplicate rules like:

LFS Rule	OrgCheck ID	Category	Replaces OrgCheck Rule
InactiveFlow	100	Useless	Rule 35
ProcessBuilder	101	Useless	Rule 37
FlowDescription	102	Documentation	Rules 38, 53
APIVersion	103	API Version	Rules 39, 4
UnsafeRunningContext	104	Security	Rule 40

[vBritt0]

Hey @VinceFINET,

Thanks for the feedback. We understand the goal of avoiding pure duplication (e.g., InactiveFlow vs. rule 35), and de-duplication makes sense. The rapid release cycle of OrgCheck — Boron landed in April 2025 with breaking changes — combined with the need to set it up in an Org, makes phased contributions from external/community folks really hard.

This PR therefore aims for a phased, low-risk approach:

• Add the genuinely new checks (e.g., 105–125) as high-value rules.
• Map overlapping rules but exclude duplicates from scoring initially (or deprecate old ones gradually with migration docs).
• Include a config toggle to enable/disable LFS scanning, protecting users on older setups.

Thoughts? Any commitment to a phased approach, or guidance on upcoming changes?

[VinceFINET]

Hello

I appreciate your effort into this integration.
No question about that.
The list of modifications in this PR clearly stands that you got the all logic of the core javascript.
Again Thank you for this.

I was just mentioning the duplicate rules as a starting point.
As you mentioned yourself, if we have duplicated rules, the score will then have +2 instead of +1.
That's all i was writing about.

Let's discuss also how you plan to include the existing LFS code.
At some point I would like to have Org Check not only as a Salesforce application but also as a SFDX plugin, to do so all imports need to be not as static resources.
At this time, I have the javascript in the build folder and then use rollup to push the code into the LWC components that needs it.
At this time i am using third party libraries in a unique static resource in the app:

• D3js --> to generate graphs
• fflate --> to zip the content we store in the browser cache
• JsForce --> to access the different apis from salesforce
• SheetJS -> to export data as Excel files instead of poor CSV files

That means the feature related to the libs included in this static library are doomed to stay in the app and not in the future sfdx plugin...
And it would be the same if we include LFS as a static resource.

As JsForce does not need to be included of course because its out of the box in a sfdx plugin, still i would like to have the hability to use these libraries in the app and in the plugin later one. I guess the solution is that i have to include the library and the code around them in the javascript core code and not in the application anymore.

That would allow me to have the feature of exporting XSL files, to generate SVG files for diagramming, and potentially to have a local storage with the same zip optimisation.

I strongly believe that this applies to the way we can include the FLS lib as well.

What could be the options??
Thank you

[RubenHalman]

@VinceFINET

I think there’s a small misunderstanding in this part:

“That means the feature related to the libs included in this static library are doomed to stay in the app”

Using a static resource is just one way of injecting JavaScript into a Salesforce app and doesn’t prevent the same library from being used elsewhere.

For example, LFS today:

• is bundled as a static resource in a Salesforce app(and can be updated with this build script automatically)
• is bundled as a seperate JS file in Inspector Reloaded via a slightly different build process.
• at the same time is used as a module for the VS Code extension, CLI plugin and GitHub Action, etc.

It’s the same core JS, just injected differently. The static resource is an implementation detail and not a lock-in. It can always be replaced later with imports from a shared package or copied/injected into any file directly using a build script.

So including LFS as a static resource now wouldn’t “doom” it to the app, it just reflects the current delivery mechanism and keeping this similar was the most straight forward path, but it can be fully adapted as you see fit. The important part is keeping the core logic environment-agnostic, which LFS already is.

Hello

I appreciate your effort into this integration. No question about that. The list of modifications in this PR clearly stands that you got the all logic of the core javascript. Again Thank you for this.

I was just mentioning the duplicate rules as a starting point. As you mentioned yourself, if we have duplicated rules, the score will then have +2 instead of +1. That's all i was writing about.

Let's discuss also how you plan to include the existing LFS code. At some point I would like to have Org Check not only as a Salesforce application but also as a SFDX plugin, to do so all imports need to be not as static resources. At this time, I have the javascript in the build folder and then use rollup to push the code into the LWC components that needs it. At this time i am using third party libraries in a unique static resource in the app:

* D3js --> to generate graphs

* fflate --> to zip the content we store in the browser cache

* JsForce --> to access the different apis from salesforce

* SheetJS -> to export data as Excel files instead of poor CSV files

That means the feature related to the libs included in this static library are doomed to stay in the app and not in the future sfdx plugin... And it would be the same if we include LFS as a static resource.

As JsForce does not need to be included of course because its out of the box in a sfdx plugin, still i would like to have the hability to use these libraries in the app and in the plugin later one. I guess the solution is that i have to include the library and the code around them in the javascript core code and not in the application anymore.

That would allow me to have the feature of exporting XSL files, to generate SVG files for diagramming, and potentially to have a local storage with the same zip optimisation.

I strongly believe that this applies to the way we can include the FLS lib as well.

What could be the options?? Thank you