[feature] Rework timeline code to make it useful for more than just statuses (#373)

* add preparable and timelineable interfaces

* initialize timeline manager within the processor

* generic renaming

* move status-specific timeline logic into the processor

* refactor timeline to make it useful for more than statuses

1 files changed, 21 insertions, 0 deletions

diff --git a/internal/gtsmodel/status.go b/internal/gtsmodel/status.go
index e80924ca3..e798ea41b 100644
--- a/internal/gtsmodel/status.go
+++ b/internal/gtsmodel/status.go
@@ -66,6 +66,27 @@ type Status struct {
 	Likeable                 bool               `validate:"-" bun:",notnull"`                                                                          // This status can be liked/faved
 }
 
+/*
+	The below functions are added onto the gtsmodel status so that it satisfies
+	the Timelineable interface in internal/timeline.
+*/
+
+func (s *Status) GetID() string {
+	return s.ID
+}
+
+func (s *Status) GetAccountID() string {
+	return s.AccountID
+}
+
+func (s *Status) GetBoostOfID() string {
+	return s.BoostOfID
+}
+
+func (s *Status) GetBoostOfAccountID() string {
+	return s.BoostOfAccountID
+}
+
 // StatusToTag is an intermediate struct to facilitate the many2many relationship between a status and one or more tags.
 type StatusToTag struct {
 	StatusID string  `validate:"ulid,required" bun:"type:CHAR(26),unique:statustag,nullzero,notnull"`