Y26-045 - [BUG] Integrate 2D barcode re-printing behaviour

[dasunpubudumal]

Describe the bug

Currently, when a tube manifest is created, the user can specify which kind of barcode he/she needs (either 1D or 2D). When the manifest is created, then, it would generate and print the barcode.

After the manifest is created, if the user wants to re-print the tube labels, there is also an a "Re-print all labels" button in the manifest view page, as shown below, that allows the user to re-print the labels.

However, the underlying code that is triggered when the button is pressed is not hooked up to print 2D barcodes. So, if a user creates a tube manifest and selects a 2D barcode to be printed when creating the manifest, the re-print option will still trigger the 1D barcode corresponding to the tubes in the manifest.

The way that 2D barcodes are created is just by passing a couple of additional attributes to the print job.

As PSD we need therefore to fix the code that is triggered when the re-print button is pressed so that if the user expects a 2D barcode when re-printing, it would print 2D barcodes. The fix could be such that the user is allowed on re-print to select from a dropdown which barcode type he/she needs.

FreshSerivce/RT Ticket Number

#SR-55454

To Reproduce
Steps to reproduce the behaviour:

1. Create a tube manifest with a 2D barcode. Give psd-2 as the printer to check what the label looks like (you need to be there in the office to check it out!). Note down the manifest ID created.
2. Visit /sdb/sample_manifests/<manifest-id>, give psd-2 as the printer in the "Barcodes" section and click "Re-print all labels" button.
3. Assert that the labels printed upon re-printing are 1D labels.

Expected behaviour

Print 2D barcodes upon re-printing

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Windows or Mac?
• Browser Chrome, Firefox, Safari or other?
• Browser version (use 'About' to look up)?

Additional context

This was related to the FreshService ticket #SR-55454.