Bug #7652

Default repository upload limit not applied to repositories created via CLI

Added by Tim Hutchinson over 7 years ago. Updated almost 7 years ago.

Status:VerifiedStart date:12/03/2014
Priority:MediumDue date:
Assignee:Dan Gillean% Done:

0%

Category:Repository
Target version:Release 2.2.0
Google Code Legacy ID: Tested version:2.1, 2.2
Sponsored:No Requires documentation:No

Description

To reproduce:
- make sure the default upload limit is set to a non-zero value, e.g. 1 or 10
import a description(s) via CLI where the repository name is not yet in the database
Result:
- uploads disabled for new repository
Expected result:
- default upload limit based on value in settings

Note: tested with MODS import, but I have seen this before - probably with CSV import of information objects


Related issues

Related to Access to Memory (AtoM) - Task #8491: Extend all tasks from arBaseTask instead of sfBaseTask New 05/29/2015

History

#1 Updated by Dan Gillean over 7 years ago

  • Category set to Repository
  • Assignee set to Mike Cantelon
  • Target version set to Release 2.2.0
  • Tested version 2.1 added

#2 Updated by Dan Gillean almost 7 years ago

  • Target version deleted (Release 2.2.0)

#3 Updated by Mike Cantelon almost 7 years ago

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

Fixed in XML and CSV import tasks.

https://github.com/artefactual/atom/pull/177

#4 Updated by Dan Gillean almost 7 years ago

  • Target version set to Release 2.2.0
  • Requires documentation set to No

#5 Updated by Nick Wilkinson almost 7 years ago

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

Hi Radda, can you please take a look at this for code review? Thanks!

#6 Updated by José Raddaoui Marín almost 7 years ago

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

Hi Mike, it looks good. But I'm thinking that we created an arBaseTask to tweak the formatter, we could add the settings there to sfConfig and extend all our tasks from it. I think that will fix PR 176 too and it will avoid us to add it in all tasks.

#7 Updated by Mike Cantelon almost 7 years ago

Hi José. Good thinking I'll make that change.

#8 Updated by Mike Cantelon almost 7 years ago

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

Hi José... I've made that change. Cheers.

#9 Updated by José Raddaoui Marín almost 7 years ago

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

Awesome Mike, it looks great!

I've created #8491 to do it in all our tasks.

#10 Updated by José Raddaoui Marín almost 7 years ago

  • Related to Task #8491: Extend all tasks from arBaseTask instead of sfBaseTask added

#11 Updated by Mike Cantelon almost 7 years ago

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

Merged into 2.2 and 2.3 branches.

#12 Updated by José Raddaoui Marín almost 7 years ago

Since #8491 has been moved to 2.3, I've added this fix to the digitalobject regen-derivates task to solve the issue reported by Zachary Howarth in Github (PR 176)

https://youtu.be/LEvv6N_mlnM

Dan, could you check if that's fixed too?

Thanks!

#13 Updated by Dan Gillean almost 7 years ago

  • Status changed from QA/Review to Verified

Also available in: Atom PDF