ecency/esync-py#59 makes the curator roster writable so the database can be the single source of truth for who curates. The gateway needs to forward the three new admin-only routes, the same way it forwards every other desk write:
POST /private-api/curation-desk/roster-list -> curation/desk/roster/listPOST /private-api/curation-desk/roster-set -> curation/desk/roster/setPOST /private-api/curation-desk/roster-retire -> curation/desk/roster/retire
The existing GET /private-api/curation-desk/roster stays as it is: it is edge-cached for 10 minutes and must not start carrying notes, added_by or retired rows, which is why the private view is a POST.
One difference from the read routes: rules is refused rather than trimmed. A read filter with an unknown value is dropped so the backend applies its default, but an admin who sets a rule must not be told it was saved when it was discarded.
ecency/esync-py#59 makes the curator roster writable so the database can be the single source of truth for who curates. The gateway needs to forward the three new admin-only routes, the same way it forwards every other desk write:
POST /private-api/curation-desk/roster-list->curation/desk/roster/listPOST /private-api/curation-desk/roster-set->curation/desk/roster/setPOST /private-api/curation-desk/roster-retire->curation/desk/roster/retireThe existing
GET /private-api/curation-desk/rosterstays as it is: it is edge-cached for 10 minutes and must not start carrying notes,added_byor retired rows, which is why the private view is a POST.One difference from the read routes:
rulesis refused rather than trimmed. A read filter with an unknown value is dropped so the backend applies its default, but an admin who sets a rule must not be told it was saved when it was discarded.