Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Y25-074 - Use only the label print templates in the Deployment project for Limber #2198

Open
2 tasks
yoldas opened this issue Jan 31, 2025 · 0 comments
Open
2 tasks
Labels
Barcode Label Printing Enhancement New feature or request Size: S Small - low effort & risk Value: 3 Value to the insitute is average

Comments

@yoldas
Copy link
Member

yoldas commented Jan 31, 2025

User story

As a PSD developer, AY, I would like Limber to use only the label print templates from the Deployment project to avoid inconsistency and unexpected results in label templates. Remove the label template files (*.yml) from Limber config/sprint/label_templates directory in Limber project or find an alternative.

Limber looks for label templates in the Limber project folder in config/sprint/label_templates if it needs to print using Sprint.
Deployment contains label templates in roles/sprint/files in the Deployment project folder.
Limber deployment includes the sprint role. When Limber is deployed, both the limber project directory and the templates from the sprint role are copied to the target host.

Who are the primary contacts for this story

Abdullah

Who is the nominated tester for UAT

TBD

e.g. John S (don't include surnames in public repos)

Acceptance criteria

Consider if these features can be featured flagged to decouple testing and deployment.
To be considered successful the solution must allow:

  • There is only one copy of the label templates for Limber, which is stored in roles/sprint/files.
  • Test that it does not break Limber in the local development environment.

Dependencies

This story is blocked by the following dependencies:
N/A

References
This story has a non-blocking relationship with:
#2190

Additional context

This story aims to have a single source of truth for limber label templates for Sprint because it loads them from local directory to print directly to the Sprint service.

There are two source folders for the label templates for Limber at the moment:

  1. Limber project config/sprint/label_templates directory
  2. Deployment project roles/sprint/files/label_templates directory

When Limber is deployed using deploy_limber.yml, which includes the sprint role, both set of label templates are copied to the destination folder on the Limber host. This causes inconsistency in the label templates if they are not in sync. because the label templates in the sprint role are copied later and overwrites the Limber copies, and the extra files in Limber project are also kept. Ideally there should be only one source of label templates, i.e. from the sprint role, and ultimately Limber should send the print jobs over PMB and not store any label templates.

Until moving Limber Sprint printing to PMB, there is also a separate playbook to deploy the label templates from the deployment project without having to deploy the whole app. This playbook is a temporary workaround; it will be removed when all printing from Limber is moved to PMB because there will be no need to copy templates to the Limber host.

@yoldas yoldas added the Enhancement New feature or request label Jan 31, 2025
@psd-issuer psd-issuer bot changed the title Use only the label print templates in the Deployment project for Limber Y25-074 - Use only the label print templates in the Deployment project for Limber Jan 31, 2025
@stevieing stevieing added Size: S Small - low effort & risk Value: 3 Value to the insitute is average labels Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Barcode Label Printing Enhancement New feature or request Size: S Small - low effort & risk Value: 3 Value to the insitute is average
Projects
None yet
Development

No branches or pull requests

2 participants