Location information is not included in reports when default culture is not en
|Target version:||Release 2.5.0|
|Google Code Legacy ID:||Tested version:||2.4, 2.5|
- In apps/qubit/config/settings.yml, set the default installation culture to another language, like "fr"
- Remember to restart services and reindex
- Create a new description with some item-level children in the French UI
- Link the item-level children to new storage locations - ensure new locations have all info filled out (name, location, type)
- Return to parent description, and generate a physical locations report (e.g. HTML - though same issue is present in CSV)
- When it is generated, open the new report
- Name on report is a raw URL, instead of a hyperlinked name
- Location is not included in the report
See attached screenshot.Expected result
- Reporting works across cultures. If the descriptions are in french, the UI is in french, and the report request was submitted via the French interface, then there should be no conflicts, and the report should work.
#6 Updated by Mike Cantelon about 4 years ago
- Status changed from New to Code Review
- Assignee changed from Mike Cantelon to Nick Wilkinson
PR for CR: https://github.com/artefactual/atom/pull/716
I wasn't able to replicate the problem specified in this issue in 2.5, but there was an error preventing the report from being generated.
I'm going to see if I can replicate the issue in 2.4 and submit a separate PR for that as I don't think the problem the above PR fixes will be present in 2.4.
#10 Updated by Dan Gillean about 4 years ago
- Status changed from QA/Review to Verified
- Assignee deleted (
- Target version set to Release 2.5.0
Strangely, French accents don't display properly on the HTML report page - but that's a separate issue, and can be filed as one if needed. I repeated the test described above, and got hyperlinks and location names in the HTML report, so I think that the original issue has been addressed. I was able to generate the report when default culture was FR, and EN, so it seems like Mike's fix might have resolved a different regression! As such, marking this as verified for now. Thanks!