Extensive use of type checking. Movement of pytest conf towards handling managers (for db agnostic unittest). Starting to organize pytests.

1 files changed, 1 insertions, 27 deletions

diff --git a/jb/models/definitions.py b/jb/models/definitions.py
index a3d27ba..4ae7a21 100644
--- a/jb/models/definitions.py
+++ b/jb/models/definitions.py
@@ -1,4 +1,4 @@
-from enum import IntEnum, StrEnum
+from enum import IntEnum
 
 
 class AssignmentStatus(IntEnum):
@@ -37,32 +37,6 @@ class HitReviewStatus(IntEnum):
     ReviewedInappropriate = 3
 
 
-class PayoutStatus(StrEnum):
-    """These are GRL's payout statuses"""
-
-    # The user has requested a payout. The money is taken from their
-    #   wallet. A PENDING request can either be APPROVED, REJECTED, or
-    #   CANCELLED. We can also implicitly skip the APPROVED step and go
-    #   straight to COMPLETE or FAILED.
-    PENDING = "PENDING"
-    # The request is approved (by us or automatically). Once approved,
-    #   it can be FAILED or COMPLETE.
-    APPROVED = "APPROVED"
-    # The request is rejected. The user loses the money.
-    REJECTED = "REJECTED"
-    # The user requests to cancel the request, the money goes back into their wallet.
-    CANCELLED = "CANCELLED"
-    # The payment was approved, but failed within external payment provider.
-    #   This is an "error" state, as the money won't have moved anywhere. A
-    #   FAILED payment can be tried again and be COMPLETE.
-    FAILED = "FAILED"
-    # The payment was sent successfully and (usually) a fee was charged
-    #   to us for it.
-    COMPLETE = "COMPLETE"
-    # Not supported # REFUNDED: I'm not sure if this is possible or
-    #   if we'd want to allow it.
-
-
 class ReportValue(IntEnum):
     """
     The reason a user reported a task.