Subscription Depletion

Description / Overview

There needs to be a way of registering when subscriptions are depleted, storing this information and querying whether the depleted status has changed. I propose the following system:

• A is_depleted boolean field is added to the GeneralTaskSubscription model
• When a SubscriptionEnded Exception is raised, is_depleted = true is set
• A new subscription/:id/depleted/ (or maybe check-depleted ?) DetailRoute is added to the Subscription View
  • when POSTing (or maybe PATCHing? damn those HTTP verbs...) to this detail route the depletion status is checked via calling _get_next_assignment_in_subscription() on the subscription
  • if the subscription is still depleted an appropriate error code should be returned
  • otherwise the serialized subscription should be returned

Use cases

The frontend is able to handle depleted subscriptions differently (e.g. hide them). Via the new proposed endpoint it's able to periodically query for changes to the depletion status. This is necessary for validation or conflict subscription who may be temporarily depleted until new Feedback/Conflicts are created.

Feature checklist

• is_depleted boolean field on GeneralTaskSubscription
• setting of aforementioned field either when SubscriptionEnded is thrown or _get_next_assignment_in_subscription() (@j.michal which is confusingly named btw. since it returns submissions) returns a submission
• new DetailRoute on Subscription view that allows to query depletion status