Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: it's hard to maintain fpr-admin as a separate repo #181

Closed
sevein opened this issue Sep 18, 2018 · 5 comments

Comments

Projects
None yet
6 participants
@sevein
Copy link
Contributor

commented Sep 18, 2018

Expected behaviour
It should be easy to make changes to our fpr Django app.
Suggested solution: move fpr to dashboard.

Current behaviour
fpr lives in a separate repo with its own releases. When we want to make a change, we usually submit a PR against fpr-admin, CR, merge, release, submit a PR against AM bumping the requirement, CR, merge... it's highly inconvenient!

Your environment (version of Archivematica, OS version, etc)
Any!


For Artefactual use:
Please make sure these steps are taken before moving this issue from Review to Verified in Waffle:

  • All PRs related to this issue are properly linked 👍
  • All PRs related to this issue have been merged 👍
  • Test plan for this issue has been implemented and passed 👍
  • Release documentation (e.g. release notes, wiki documentation, etc) regarding this issue has been written 👍
@sevein

This comment has been minimized.

Copy link
Contributor Author

commented Sep 18, 2018

It'd be as easy as copying fpr into src/dashboard/src and adjusting the requirements. Once this is done, it'll also become easier to deal with some known issues like the problems with template inheritance and other issues like artefactual/archivematica-fpr-admin#28, artefactual/archivematica-fpr-admin#34...

@sevein

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2018

Things that we need to consider during the migration:

  • south_migrations can potentially be removed
  • load_data should not be used in migrations (deprecated in Django 1.9!)
  • setup.py, testproject, etc... would not be needed anymore
  • Template inheritance should be reviewed (_fpr_update_button.html? fpr/templates/app_layout.html:layout_fluid.html?)
  • Shared assets like datatables should be reviewed
@sevein

This comment has been minimized.

Copy link
Contributor Author

commented Dec 20, 2018

I've done this as part of the work that I was doing in #213.

@sevein sevein added this to the 1.9.0 milestone Dec 20, 2018

@sevein sevein removed their assignment Jan 8, 2019

@sevein

This comment has been minimized.

Copy link
Contributor Author

commented Jan 8, 2019

For QA, just make sure that the preservation planning tab works as usual.

@sallain sallain assigned sallain, ablwr and peterVG and unassigned sallain and ablwr Feb 4, 2019

@peterVG

This comment has been minimized.

Copy link

commented Feb 7, 2019

The Preservation Planning tab works as usual. Policy changes were successfully tested for Characterization, Event Details, Normalization, Transcription and Validation.

There is a separate known issue (#485) for File Identification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.