Prevent merging of non-frontend-viewable orders

[Noah-Silvera]

Summary

Non-frontend viewable orders are created by Solidus admins, and these can be unintentionally merged into a user's existing orders when they login.

We want to exclude them from the list of order merge candidates

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have localized any and all user-facing strings that I added to the source code.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.37%. Comparing base (f4654cf) to head (54f1c9e).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6362   +/-   ##
=======================================
  Coverage   89.37%   89.37%           
=======================================
  Files         961      961           
  Lines       20200    20200           
=======================================
  Hits        18054    18054           
  Misses       2146     2146           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tvdeyen]

I am not sure about this. Consider a customer service agent creating an order for a customer (on the phone or maybe in a showroom).

If those orders now do not are listed in the customers account section they might be surprised.

What about making the order merger a configurable class and let stores decide how they want to handle this in their store?

[tvdeyen]

The order merger is already configurable. Why are we not using it?

[tvdeyen]

Ok. We do, but this business logic is outside of it and just handles merging one order. This is worth refactoring

[tvdeyen]

Another idea: Why are we hard coding frontend_viewable into the order params in the admin orders controller. What about making this a checkbox on the admin orders screen? Then a customer agent could decide.

Anyhow. This is worth a bit more discussion.

[tvdeyen]

We agreed in the core team meeting on merging this and work on the topics I mentioned in subsequent PRs

Thanks