Bug #11507

Title of descriptions not displayed on Jobs page when created in a different culture

Added by Dan Gillean over 1 year ago. Updated 9 months ago.

Status:VerifiedStart date:09/12/2017
Priority:MediumDue date:
Assignee:Nick Wilkinson% Done:

0%

Category:I18N
Target version:Release 2.5.0
Google Code Legacy ID: Tested version:2.0.0
Sponsored:No Requires documentation:

Description

First reported in the user forum, 2017-09-12: link

To reproduce:

  • Flip the user interface to a different language than your default installation culture (e.g. Spanish). Make sure that language is properly added to Admin > Settings > i18n languages and the search index is up to date
  • Create a new descriptive hierarchy - a top level record with several children. Make sure all records are in Draft mode.
  • While still in the other culture, update the publication status of the entire hierarchy to "Published".
  • Navigate to the Jobs page

Resulting error

  • Jobs info message does not include title of description - no culture fallback where installation culture translation is unavailable.
  • Jobs info message reads: "Updating publication status for the descendants of "" to "Published"."

Expected result

  • When no title in the installation culture is available, culture fallback is used and the original language title is used in the Jobs page
  • Jobs info message reads: "Updating publication status for the descendants of "[original title]" to "Published"."

jobs-msg.png (46.2 KB) Dan Gillean, 09/12/2017 09:24 AM

History

#1 Updated by Dan Gillean over 1 year ago

Attaching screenshot for reference

#2 Updated by Mike Cantelon 10 months ago

  • Status changed from New to Code Review
  • Assignee set to Nick Wilkinson

#3 Updated by Nick Wilkinson 10 months ago

  • Assignee changed from Nick Wilkinson to Steve Breker

Hi Steve, passing to you for CR.

#4 Updated by Steve Breker 10 months ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Steve Breker to Mike Cantelon

CR complete. Looks great!

#5 Updated by Mike Cantelon 10 months ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from Mike Cantelon to Dan Gillean

Merged into qa/2.5.x and ready for QA. Can backport.

#6 Updated by Mike Cantelon 10 months ago

  • Target version set to Release 2.5.0

#7 Updated by Michelle Curran 9 months ago

  • Status changed from QA/Review to Feedback
  • Assignee changed from Dan Gillean to Mike Cantelon
  • Tested version 2.0.0 added

I'm getting a 500 internal server error after creating a new Spanish language description with multiple children and then set description to 'Published' (step 3 below).

To reproduce:

  1. Flip the user interface to a different language than your default installation culture (e.g. Spanish). Make sure that language is properly added to Admin > Settings > i18n languages and the search index is up to date
  2. Create a new descriptive hierarchy - a top level record with several children. Make sure all records are in Draft mode.
  3. While still in the other culture, update the publication status of the entire hierarchy to "Published".

#8 Updated by Dan Gillean 9 months ago

  • Assignee changed from Mike Cantelon to Michelle Curran

Hi Michelle,

This might be due to the atom-worker needing a restart - there is a known configuration issue where the atom-worker sleeps after too long a period of inactivity.

Often when I get a 500 error when trying something involving the job scheduler, I will then test another task that also uses it, such as moving a record from one parent to another, exporting from the clipboard, generating a report or a finding aid, etc. If those also fail with a 500 error, odds are good that the job scheduler needs a restart.

You can try restarting the job scheduler and repeating the test with the following command:

sudo systemctl restart atom-worker

See: https://www.accesstomemory.org/docs/2.5/admin-manual/maintenance/troubleshooting/#restarting-the-job-scheduler

You can always get the full 500 error message from the Nginx log, which can help with troubleshooting:

sudo tail -f /var/log/nginx/error.log

See:

If that still doesn't help, then it could be a bug related to this fix! If so, please add the relevant error message from the Nginx log to the ticket, to assist Mike in debugging the issue :)

#9 Updated by Michelle Curran 9 months ago

  • Status changed from Feedback to Verified
  • Assignee changed from Michelle Curran to Nick Wilkinson

Thanks for the tip, Dan.

Verified in qa/2.5.

Also available in: Atom PDF