InvenTree icon indicating copy to clipboard operation
InvenTree copied to clipboard

Add option ot mark the build item as complete if all tests passed

Open martonmiklos opened this issue 1 year ago • 5 comments

Fixes #6006

martonmiklos avatar Sep 03 '24 20:09 martonmiklos

Deploy Preview for inventree-web-pui-preview canceled.

Name Link
Latest commit 5abdd714e6c8b69115c206c6984489906aa0c973
Latest deploy log https://app.netlify.com/sites/inventree-web-pui-preview/deploys/66d7efc19e9dc200080853ed

netlify[bot] avatar Sep 03 '24 20:09 netlify[bot]

Codecov Report

Attention: Patch coverage is 97.82609% with 1 line in your changes missing coverage. Please review.

Project coverage is 83.80%. Comparing base (f144158) to head (5abdd71). Report is 644 commits behind head on master.

Files with missing lines Patch % Lines
src/frontend/src/forms/PartForms.tsx 66.66% 1 Missing :warning:
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #8061      +/-   ##
==========================================
- Coverage   83.87%   83.80%   -0.07%     
==========================================
  Files        1142     1143       +1     
  Lines       50979    51019      +40     
  Branches     1783     1785       +2     
==========================================
- Hits        42760    42758       -2     
- Misses       7760     7824      +64     
+ Partials      459      437      -22     
Flag Coverage Δ
backend 85.72% <100.00%> (+0.01%) :arrow_up:
pui ∅ <85.71%> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:
  • :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

codecov[bot] avatar Sep 03 '24 21:09 codecov[bot]

@martonmiklos thanks for looking at this, and apologies for the delayed response.

Looking at the new model field implementation here, I think that it should be an option against the BuildOrder instance, rather than the Part instance.

@matmair @wolflu05 any thoughts or preferences here?

SchrodingersGat avatar Sep 23 '24 03:09 SchrodingersGat

@martonmiklos thanks for looking at this, and apologies for the delayed response.

No worries.

Looking at the new model field implementation here, I think that it should be an option against the BuildOrder instance, rather than the Part instance.

@matmair @wolflu05 any thoughts or preferences here?

I see your point, but I would say both options could make sense. In my use case most of the products got packaged as the part of the last teststep so closing the build order when all units passed makes sense. Enabling the "autoclose" feature for each build order created would not makes too much sense in this case.

I am open to tailor this feature further by adding an "autoclose" option to the build orders dynamically (if it is not enabled at part level).

martonmiklos avatar Sep 23 '24 08:09 martonmiklos

@martonmiklos I was envisioning a much "simpler" approach, where you can set the "default value" for the "auto close" option as a global setting, but then adjust on a per-build level as needed.

Having this as a "per part" option seems a bit messy (for lack of a better word) especially as most parts cannot be "built" (they are components, e.g. ) and so the option does not even make sense for them. At a bare minimum the option should be hidden for parts which are not "assemblies".

The issue here is that we do not have any other "dependent attributes" - the attributes such as "purcahsesable", "trackable" , "salable" (etc) are all independent of each other.

SchrodingersGat avatar Sep 26 '24 10:09 SchrodingersGat

@martonmiklos thinking about this further, I believe that this would be much better as a custom plugin. This way we do not need to add new internal logic to multiple points in the code to implement a feature which most people would disable anyway.

We have a comprehensive set of event triggers which could be hooked into by a plugin to "auto-complete" a build when the tests are completed. And, the plugin could expand with additional complexity as required, without needing to change core behaviour.

SchrodingersGat avatar Nov 19 '24 22:11 SchrodingersGat

@martonmiklos I'm going to close this out, but if you want to discuss further how to implement this as a plugin I'd be happy to assist

SchrodingersGat avatar Dec 24 '24 01:12 SchrodingersGat