Feature assemblies base

[webdevinition]

Hello @jbtronics,

In relation to #1051 the feature for adding the base of assembly as an new data source.
Also mentioned in the discussion under #1041, section 1.

The changes are the remaining delta to the other extracted feature pull requests related to the mentioned discussion.

Configuration opportunity of Bills of Materials (BOMs) with referencing of other assemblies, cycle prevention included

Simplified import overview with template description for filling the parts lists (BOM) of an assembly

Human-readable export in CSV and PDF format for simplified viewing of basic information

Human-readable export in PDF format to simplify understanding of which parts are actually required for a multiply nested assembly, for example, completely independent of a build function as is the case with projects.

Thanks for everything so far! I am grateful for integration!

Best regards,
Marcel

[webdevinition]

@jbtronics, I've rebased the branch to the master branch.

It would be great if you could take a look at the pull request and give me some feedback on what else needs to be done for you to integrate it.

I wish you even now a nice and fulfilling holiday season!

Best regards,
Marcel

[codecov]

Codecov Report

❌ Patch coverage is 27.12100% with 1572 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.52%. Comparing base (05a9e4d) to head (e4cd243).

Files with missing lines	Patch %	Lines
src/Services/ImportExportSystem/BOMImporter.php	14.98%	312 Missing ⚠️
src/Services/ImportExportSystem/EntityExporter.php	3.96%	242 Missing ⚠️
src/Helpers/Assemblies/AssemblyPartAggregator.php	0.74%	133 Missing ⚠️
src/DataTables/AssemblyDataTable.php	0.00%	115 Missing ⚠️
src/Controller/AssemblyController.php	60.13%	61 Missing ⚠️
src/Controller/TypeaheadController.php	1.63%	60 Missing ⚠️
src/Controller/StatisticsController.php	0.00%	58 Missing ⚠️
src/DataTables/AssemblyBomEntriesDataTable.php	62.16%	56 Missing ⚠️
src/DataTables/Filters/AssemblySearchFilter.php	0.00%	56 Missing ⚠️
src/Form/Filters/AssemblyFilterType.php	0.00%	48 Missing ⚠️
... and 35 more

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1082      +/-   ##
============================================
- Coverage     54.77%   52.52%   -2.25%     
- Complexity     8012     8580     +568     
============================================
  Files           601      629      +28     
  Lines         25691    27807    +2116     
============================================
+ Hits          14073    14607     +534     
- Misses        11618    13200    +1582     

☔ 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.

[jbtronics]

I do not quite understand what the semantic difference between an assembly and the existing projects should be?

[webdevinition]

Hello @jbtronics,

I hope you had a wonderful holiday season.
First of all, Happy New Year, best of luck, and above all, good health! :)

Here's the explanation:

1. Logical vs. Physical Entity
   Project (Operational): A project is a concrete work order. It uses the "Build Part" function to retrieve physical parts from inventory at the end of the process and book the finished product/device. It represents the manufacturing process for users in a way.
   Assembly (Structural): An assembly is a purely logical definition (similar to a "virtual component"). It serves to define the bill of materials (BOM) for a complex part without having to go through a virtual part or even a build process in our every day life working with Part-DB.

2. The Problem of "Flat" Projects
   Without assemblies, a user building a complex machine would have to create a huge project with many of individual parts.

With assemblies: The user defines the "Motor" assembly once and the "Control" assembly once with all the depending structure.
In another assembly where this is needed, the user simply adds these example assemblies to the bill of materials with the necessary quantity.
The key advantage: Since assemblies don't have their own build part/stock inventory in the pull request, they serve as transparent containers.

The difference lies in the level of abstraction:
Projects are designed mainly for the physical build process of specific users. They have a 'build part' because they actively modify the inventory (components removed, finished product added).
Assemblies are designed for structural organization in our every day life. They don't have their own inventory but serve as reusable templates for bills of materials in other assembly entries.

Assemblies thus specifically solve the problem of reusing blueprints, while projects solve the problem of inventory changes during manufacturing.
This adds another useful feature to the part database for all users who wish to utilize it.

[jbtronics]

Im still not really convinced that introducing a new kind of entity is the best approach there. Especially as this PR is very big and complex (136 file changes) and a lot of logic seems to be duplicated from projects.

Maybe the goal could also be reached by adding some new functionality to the existing projects (like adding a flag, that makes them non-buildable and only work as generic placeholder, or assembly if you wanna call it that way).

I am not sure how many people would actually profit from that feature anyway, and if it is worth to the additional complexity/maintenance effort of the PR in the current form.

[webdevinition]

Hello @jbtronics,

thank you for your reply. I don't currently see this being represented in the projects via a flag or similar.

Benefits for the community:
Hierarchical BOMs: complex hardware cannot really do without nested parts lists (multi-level BOMs) and cannot really be represented. This should be separated from the projects to avoid unwanted sideeffects- because it is a new type of datasource.
Basically, anyone who not only soldered circuit boards but also defined housings, motors, or cable harnesses as subgroups needed this structure to maintain an overview. That's why I see a certain benefit for the community.
It is also a feature that can be activated. Those who don't need it don't have to activate it.

In addition, a separate assembly entity is certainly more intuitive for such users, as assemblies often serve as reusable blueprints (templates), while projects are one-time instances (actually real orders in a way).

I would greatly appreciate it if you could take on this task as well and would also be happy to contribute further to any future inquiries that may arise, because I enjoy doing so.

I will also modify the Custom Part State feature to include multiple selection in the near future and prepare it as a pull request—unfortunately, I haven't had time to do so yet ;)

Best regards,
Marcel