update TODOs

2 files changed, 16 insertions, 36 deletions

diff --git a/TODO b/TODO
index e1a2417d..7692444b 100644
--- a/TODO
+++ b/TODO
@@ -1,29 +1,20 @@
 
+## In Progress
+
 ## Next Up
 
-- all errors should result in transaction rollback
-- test: re-deleting a deleted entity should be 4xx, not 5xx
-- test: can't delete an accepted edit
-- test: redirect to a WIP row
-- test: revert to current version (should be disallowed)
-- test: hide/expand in lookups
-- test: python get revision endpoint, whether accepted or now
-- test: GET redirects endpoint
-- test: additional edits, editgroup already accepted
-- test: prev_rev in various cases
-- test: release pointing to a collection that has been deleted/redirected (etc)
-- many webface tests:
-    => entity redirects, wip, deletions
-    => sub-entity redirects, wip, deletions
-- test: new release points to new container; then container deleted from
-    editgroup and editgroup accepted
-    => also web UI
-- handle wip, deleted, redirects in web UI
-- remove the concept of "active editgroup"
+- fileset/webcapture entities
+- authentication
+- remove the concept of "active editgroup", and simplify autoaccept batch path
+- fix returned error messages; should return type (shortname), and then actual
+  message/description
+- handle wip entities in web UI
 - elastic inserter should handle deletions and redirects; if state isn't
   active, delete the document
-    => and an end-to-end test of this behavior. hoo-boy.
-- release_year (in addition to date)
+    => don't delete, just store state. but need to "blank" redirects and WIP so
+       they don't show up in results
+    => refactor inserter to be a class (eg, for command line use)
+    => end-to-end test of this behavior?
 
 ## Ideas
 
@@ -31,8 +22,6 @@
 - when getting "wip" entities, require a parameter ("allow_wip"), else get a
   404
 - consider dropping CORE identifier
-- fix returned error messages; should return type (shortname), and then actual
-  message/description
 - maybe better 'success' return message? eg, "success: true" flag
 - idea: allow users to generate their own editgroup UUIDs, to reduce a round
   trips and "hanging" editgroups (created but never edited)
@@ -55,6 +44,7 @@
 
 ## Metadata Import
 
+- cleaning/matching: https://ftfy.readthedocs.io/en/latest/
 - manifest: multiple URLs per SHA1
 - crossref: relations ("is-preprint-of")
 - crossref: two phase: no citations, then matched citations (via DOI table)
@@ -64,7 +54,7 @@
     => title length and title/slug blacklist
     => at least one author (?)
     => make this a method on Release object
-    => or just set release_stub as "stub"?
+    => or just set release_type as "stub"?
 
 new importers:
 - pubmed (medline) (filtered)
@@ -76,7 +66,6 @@ new importers:
 
 ## Entity/Edit Lifecycle
 
-- redirects and merges (webface, etc)
 - commenting and accepting editgroups
 - editgroup state machine?
 
@@ -101,7 +90,7 @@ new importers:
 
 - arxiv_id field (keep flip-flopping)
 - original_title field (?)
-- FileSet and WebSnapshot entities
+- FileSet and WebCapture entities
 - `doi` field for containers (at least for "journal" type; maybe for "series"
   as well?)
 - `retracted`, `translation`, and perhaps `corrected` as flags on releases,
@@ -111,7 +100,6 @@ new importers:
 
 ## Other / Backburner
 
-- look at: https://ftfy.readthedocs.io/en/latest/
 - refactor openapi schema to use shared response types
 - consider using "HTTP 202: Accepted" for entity-mutating calls
 - basic python hbase/elastic matcher
diff --git a/rust/TODO b/rust/TODO
index 81ed7a06..18b94346 100644
--- a/rust/TODO
+++ b/rust/TODO
@@ -1,12 +1,9 @@
 
 correctness
 - extra or typo-d fields in requests don't seem to be errors (silently accepted)
-- enforce "previous_rev" required in updates
 - reread/review editgroup accept code
-- enforce "no editing if editgroup accepted" behavior
 - changelog sequence without gaps
 - batch insert editgroup behavior; always a new editgroup?
-- redirect rev_id needs to be updated when primary changes
 
 edit lifecycle
 - editgroup: state to track review status?
@@ -20,6 +17,7 @@ account helper tool
 - test/validate tokens
 
 later:
+- "prev_rev" required in updates
 - tried using sync::Once to wrap test database initilization (so it would only
   run migrations once), but it didn't seem to work, maybe I had a bug or it
   didn't compile?
@@ -32,9 +30,3 @@ later:
 - test using hash indexes for some UUID column indexes, or at least sha1 and
   other hashes (abstracts, file lookups)
 
-schema/api questions:
-- url table (for files)
-- get works/releases by creator
-- "types"
-- define release field stuff
-- what should entity POST return? include both the entity and the edit?