Bug #11700

Accession counter not incrementing after upgrade to 2.4

Added by Darren Craze about 1 year ago. Updated 8 months ago.

Status:VerifiedStart date:11/16/2017
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:AccessionsEstimated time:20.00 hours
Target version:Release 2.4.1
Google Code Legacy ID: Tested version:2.4
Sponsored:No Requires documentation:

Description

Report from a user:

When creating a new accession record, the number is still filled in automatically with the next value after the current counter. However the counter does not change, so when we create another accession record, it gives this the same number as the previous accession record.

Reproduced in 2.4. To reproduce:

  • Ensure that Accession mask and accessions counter are enabled in Admin > Settings > Global
  • Navigate to Add > Accession record
  • Create a new accession and save
  • Navigate again to Add >< Accession record
  • Enter some test data
  • Attempt to save second accession record
Resulting error
  • User cannot save record
  • Interface says that accession number is already in use
  • Accession counter has not incremented, and is trying to use the same number again
Expected result
  • Accessions counter automatically increments when accessions are created via the user interface
  • Second accession record can be created with a unique accession number autopopulated

History

#2 Updated by Dan Gillean about 1 year ago

  • Description updated (diff)
  • Target version deleted (Release 2.4.0)
  • Tested version 2.4 added

#3 Updated by Nick Wilkinson 11 months ago

  • Estimated time set to 20.00

#4 Updated by Nick Wilkinson 9 months ago

  • Assignee set to José Raddaoui Marín

Hi Radda, can you please look into this?

#5 Updated by Nick Wilkinson 9 months ago

  • Assignee changed from José Raddaoui Marín to Mike Cantelon

Hi Mike, reassigning to you to balance out workloads.

#6 Updated by Mike Cantelon 9 months ago

  • Status changed from New to Code Review
  • Assignee changed from Mike Cantelon to Nick Wilkinson

#7 Updated by Nick Wilkinson 9 months ago

  • Assignee changed from Nick Wilkinson to José Raddaoui Marín

Hi Radda, can you please CR this?

#8 Updated by Mike Cantelon 9 months ago

  • Status changed from Code Review to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

Merged (into both stable/2.4.x and qa/2.5.x) and ready for QA.

#9 Updated by Dan Gillean 9 months ago

  • Status changed from QA/Review to Feedback
  • Assignee changed from Dan Gillean to Mike Cantelon
  • Target version set to Release 2.4.1

Hi Mike,

I'm testing in the 2.5 vagrant box. Not actually sure if this is a regression that appeared somewhere else, or as a result of this work, but I'm experiencing the following issue: Accession records are inaccessible after being created in the user interface; disappear after reindexing.

To reproduce
  • Log into AtoM and navigate to Add > Accession
  • Create an accession record
  • Save
Error encountered
  • On save, user is taken to a "Page not found" message
  • Returning to Manage > Accessions and clicking on the new accession produces the same result
  • Running the search:populate task causes the new accession record to disappear completely
Expected result
  • Users can create accession records via the user interface, and access them after creating them
  • Re-indexing does not cause new accession records to disappear

#10 Updated by Mike Cantelon 9 months ago

Weird... I get that too. I'll take a look.

#11 Updated by Mike Cantelon 9 months ago

  • Status changed from Feedback to Code Review
  • Assignee changed from Mike Cantelon to José Raddaoui Marín

I forgot a line when I moved the transaction code (I should have re-tested before merging).

PR for CR: https://github.com/artefactual/atom/pull/679

#12 Updated by José Raddaoui Marín 9 months ago

  • Status changed from Code Review to Feedback
  • Assignee changed from José Raddaoui Marín to Mike Cantelon

#13 Updated by Mike Cantelon 9 months ago

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

Merged into qa/2.5.x for QA.

#14 Updated by Dan Gillean 9 months ago

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

Hi Mike,

I think the counter's incrementation might be off by one. In a fresh 2.5 instance with demo data loaded:

  • Navigate to Admin > Settings: counter is at 5
  • Create a new accession (auto-assigned accession number 2018-03-16/6)
  • Create a second accession (auto-assigned accession number 2018-03-16/7)
  • Navigate back to Admin > Settings to check counter
  • Expected result: counter is now at 7
  • Actual result: counter is now at 6

Thoughts?

#15 Updated by Mike Cantelon 9 months ago

  • Status changed from Feedback to Code Review
  • Assignee changed from Mike Cantelon to José Raddaoui Marín

Hi Dan... ah, my implementation's a bit flawed. I've made a new PR to simplify when the counter get incremented.

PR for CR: https://github.com/artefactual/atom/pull/681

#16 Updated by José Raddaoui Marín 9 months ago

  • Status changed from Code Review to Feedback
  • Assignee changed from José Raddaoui Marín to Mike Cantelon

Thanks Mike, a few comments in the PR.

#17 Updated by Mike Cantelon 9 months ago

  • Status changed from Feedback to Code Review
  • Assignee changed from Mike Cantelon to José Raddaoui Marín

Awesome... I made those tweaks, wrapped the increment in a transaction (let me know if more should be wrapepd), and re-tested.

#18 Updated by José Raddaoui Marín 9 months ago

  • Status changed from Code Review to Feedback
  • Assignee changed from José Raddaoui Marín to Mike Cantelon

#19 Updated by Mike Cantelon 9 months ago

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

Merged into qa/2.5.x (once it's QAed I'll add it to stable/2.4.x).

#20 Updated by Dan Gillean 8 months ago

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

Looks good Mike, can you please backport to stable/2.4.x?

#21 Updated by Mike Cantelon 8 months ago

  • Assignee changed from Mike Cantelon to Dan Gillean

Hi Dan. It should be backported now.

#22 Updated by Dan Gillean 8 months ago

  • Status changed from In progress to Verified
  • Assignee deleted (Dan Gillean)

Also available in: Atom PDF