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

fix/feat: Allow extension of barcode types (without validation) #16006

Merged
merged 4 commits into from
Dec 3, 2018

Conversation

gbm001
Copy link
Contributor

@gbm001 gbm001 commented Nov 16, 2018

Currently, it is difficult to add new custom barcode types for two reasons, both of which relate to validate_barcode in item.py:

  • There is a bug where barcode types with a space in, such as Code 128, are split in two (so barcode_type is checked against 'Code' and '128' rather than 'Code 128'). This is fixed by splitting the Options field against a newline, instead of spaces.
  • All barcodes are validated against the stdnum.ean library. This only handles EAN-8, EAN-13 and UPC-12 barcodes and any other barcode will fail. Barcodes with no type will continue to not be checked. Barcodes with the default barcode_types of EAN, UPC will continue to be checked. The non-default barcode_types of EAN-13 and EAN-8 will also be checked. The barcode_type is cast to upper case before this check is made so ean, upc, ean-13 and ean-8 will also be validated.

This allows people to add their own barcode types, such as Code 128 and QR codes. Users can add custom validation of these barcodes using the usual hooks, but they cannot remove the standard validation.

Andrew McLeod added 2 commits November 16, 2018 11:08
Currently, it is difficult to add new custom barcode types for two reasons, both of which relate to validate_barcode in item.py:
- There is a bug where barcode types with a space in, such as Code 128, are split in two (so barcode_type is checked against 'Code' and '128' rather than 'Code 128'). This is fixed by splitting the Options field against a newline, instead of spaces.
- All barcodes are validated against the stdnum.ean library. This only handles EAN-8, EAN-13 and UPC-12 barcodes and any other barcode will fail. Barcodes with no type will continue to not be checked. Barcodes with the default barcode_types of EAN, UPC will continue to be checked. The non-default barcode_types of EAN-13 and EAN-8 will also be checked. The barcode_type is cast to upper case before this check is made so ean, upc, ean-13 and ean-8 will also be validated.
This allows people to add their own barcode types, such as Code 128 and QR codes. Users can add custom validation of these barcodes using the usual hooks, but they cannot remove the standard validation.
Adds three different barcodes and barcodes types to a test item and
checks that they are added correctly.
Adds a barcode that already exists, and checks a DuplicateEntryError
is raised.
Adds an invalid EAN barcode and checks InvalidBarcode (a subclass of
ValidationError) is raised.
@gbm001
Copy link
Contributor Author

gbm001 commented Nov 16, 2018

Added some unit testing for Item Barcodes, even though they don't test what I have added, because why not.

@gbm001 gbm001 closed this Nov 20, 2018
@gbm001 gbm001 reopened this Nov 20, 2018
@nabinhait nabinhait merged commit 3ecb995 into frappe:staging-fixes Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants