e1f0917659
The new API requires at least one event and will automatically save a snapshot of the document and related state. Document.save() will now throw an exception if called directly, as the new API is intended to ensure that documents are saved with both an appropriate snapsnot and relevant history log, both of which are easily defeated by just calling .save() directly. To simplify things, the snapshot is generated after the changes to a document have been made (in anticipation of coming changes), instead of before as was usual. While revising the existing code to work with this API, a couple of missing events was discovered: - In draft expiry, a "Document has expired" event was only generated in case an IESG process had started on the document - now it's always generated, as the document changes its state in any case - Synchronization updates like title and abstract amendmends from the RFC Editor were silently (except for RFC publication) applied and not accompanied by a descriptive event - they now are - do_replace in the Secretariat tools now adds an event - Proceedings post_process in the Secretariat tools now adds an event - do_withdraw in the Secretariat tools now adds an event A migration is needed for snapshotting all documents, takes a while to run. It turns out that a single document had a bad foreign key so the migration fixes that too. - Legacy-Id: 10101 |
||
|---|---|---|
| bin | ||
| bootstrap | ||
| buildbot/masters/datatracker | ||
| django | ||
| etc | ||
| form_utils | ||
| ietf | ||
| notes | ||
| redesign | ||
| static | ||
| test | ||
| timedelta | ||
| vzic | ||
| .gitignore | ||
| changelog | ||
| changelog.py | ||
| control | ||
| debug.py | ||
| hold-for-merge | ||
| INSTALL | ||
| LICENSE | ||
| LICENSE.django | ||
| README-CDN.rst | ||
| README.datatracker | ||
| ready-for-merge | ||
| release-coverage.json | ||
| requirements.txt | ||
| tzparse.py | ||
The "new" datatracker uses Twitter Bootstrap for the UI. Get familiar with http://getbootstrap.com/getting-started/ and use those UI elements instead of cooking up your own. We have some site-wide customization applied to the bootstrap version we keep in bootstrap/ (from which the minified dist version is built); it modifies some stuff under less/ We also apply some additional custiomizations in static/css/ietf.css; we should eventually move that under bootstrap/less/ if possible. (ietf.css was what Lars used initially for customization with an unmodified bootstrap.) Some ground rules: * Think hard before tweaking the bootstrap CSS, it will make it harder to upgrade to future releases. * No <style> tags in the HTML! Put CSS into the "morecss" block of a template instead. * CSS that is used by multiple templates goes into static/css/ietf.css. * Javascript that is only used on one template goes into the "js" block of that template. * Javascript that is used by multiple templates goes into static/js/ietf.js. * Every template includes jquery, so write jquery code and not plain Javascript. It's shorter and often faster. * No CSS, HTML styling or Javascript in the python code! * Templates that use jquery or bootstrap plugins include the css file in the "pagehead" block, and the Javascript in the "js" block.