Feature #1871

Consolidate project file directories

Added by Bernhard Koschiček-Krombholz 4 months ago. Updated 4 months ago.

Target version:
Start date:
Estimated time:


For the containerization of OpenAtlas, it would be beneficial if the folders where files are written are in one. Right now we have openatlas/uploads, openatlas/export/sql and openatlas/processed_images/. Can we move these folders in one folder named maybe files, e.g. openatlas/ files /uploads, openatlas/ files /export and openatlas/ files /images?



Updated by Bernhard Koschiček-Krombholz 4 months ago

  • Tracker changed from Question to Feature
  • Subject changed from Move files folder together to Consolidate project file directories
  • Status changed from Assigned to Acknowledged
  • Assignee deleted (Alexander Watzinger)
  • Target version set to 7.9.0

Updated by Alexander Watzinger 4 months ago

We talked about it a few times but you are absolutely right, it really is time to consolidate them because it would have a lot of advantages. It of course would mean that extra steps will be needed when updating the instances but better to do it now than later.
I would even suggest putting the new directory into the project root (already thinking about maybe having one OpenAtlas software installed to run many instances). So the new structure would look like:

  • files
    • export (former openatlas/export/sql)
    • processed_images (former openatlas/processed_images, I would keep the processed_ prefix for clarity)
    • uploads (former openatlas/uploads)
How to implement
  • Move folder (locally)
  • Adapt .gitignore and taking care of that the empty folders are still tracked in git but not their content
  • Adapt paths in config/ Ideally needed only there, if more is needed we should change this
  • Adapt install notes in
  • Note it in install/upgrade/, also mention that backup scripts might have to be adapted
  • When releasing
To consider
  • I was thinking about a script to automate the folder moves but decided against it, it's better to do it manually because e.g. backup scripts might have to be adapted too
  • It should be done in an extra branch and only be merged to develop shortly before a release to avoid complications when switching branches while developing
  • Would the frontends need adaption too? I would hope not but we should check and change it for future versions, if this is the case.

What do you think? And is this something you would like to do or should I do it (both is fine with me).


Updated by Bernhard Koschiček-Krombholz 4 months ago

  • Status changed from Acknowledged to Assigned
  • Assignee set to Bernhard Koschiček-Krombholz

Thank you, Alex, for your thoughts! I will take this issue.


Updated by Bernhard Koschiček-Krombholz 4 months ago

So far, I'm done. My last issue is how we want to handle the upgrade of instances. But let's talk in person about this.


Updated by Alexander Watzinger 4 months ago

  • Status changed from Assigned to Closed

I took a look at it, fixed some stuff and adapted the install and upgrade notes a bit, see:
About how to proceed: I guess I will merge it in the new release_candidate when freezing for next release to avoid complications while developing.
Thank you for your work, just as a reminder for me when releasing:

  • Test frontends and backup scripts

Also available in: Atom PDF