Open aaccomazzi opened 9 years ago
For the backend, I had this extension in mind to handle some aspects of what you noted above: http://sqlalchemy-continuum.readthedocs.org/en/latest/.
A nice extension that allows auditing and reverting to older versions for SQLAlchemy handled databases.
Within the current architecture, I cannot think of any reason why we cannot implement the specification you have outlined. If anyone else has opinions, feel free to chime in.
SQLAlchemy-Continuum looks great Jonny. And it brings up something which I haven't mentioned yet but which we know we need to support: backup and restoration of a library after user/system errors (we get these in ADS classic I think once a month or so). Not clear how to do this using an admin console but it looks like the plumbing is there.
Implementation of this step would also have made the salvation of PR #100 much easier.
There are "social" aspects of ADS libraries which we should consider when architecting the system. Given the shared nature of these resources, we should make it possible for notifications to be propagated and sent to the proper actors, whether by email or simply an event log which a user can review once on our site.
I should note that the issue of notifications goes beyond the library system and should be fully fleshed out once we tackle the revamped myADS system, but I'm bringing this up here so that we don't lose sight of the fact that the libraries and the events generated on them should be at least "notification-friendly."
Here are the cases the come to mind: