864978 - Should updatedAt and createdAt always be generated by the MakeAPI instead of passed in?

Status: RESOLVED WORKSFORME

(Webmaker Graveyard :: MakeAPI, defect)

Description

[inactivate account for kate]

I don't think we should allow individual apps to set createdAt or updatedAt when creating makes.

When a user visits a page on webmaker.org that sorts makes by "most recent", the user should always see makes sorted relative to each other, not whatever date/time the original app has assigned them. Additionally, we shouldn't allow a situation in which an app could set an arbitrarily high date to always push makes to the top.

What do you guys think?

Comment 1

[David Humphrey (:humph)]

I think it's sane to say that these dates are when the thing entered the MakeAPI index, yeah.  Have the MakeAPI handle it.

You might also want to add an authoredDate, which is optional, and could default to createdAt if not given, but could also represent a date external to our stuff.  This is often done for archiving.

Comment 2

[Chris DeCairos (:cade)]

I agree with Dave, it's good form to let the API handle those fields.

I think the idea of an authoredDate could be useful to lots of apps. i.e. Work started on this Make on Date X but it wasn't published until Date Y

Comment 3

[inactivate account for kate]

Sounds fine to me. Likely not something that would surface often in our UI but nothing wrong with having it I guess

Comment 4

[Matthew Schranz [:mjschranz]]

Based on the discussions I had with :humphd about how we are going to want to handle Makes around Events in the future, adding in the extra field isn't needed.

At this point, updatedAt and createdAt can't be set on initial creation and can be updated afterwards. Going to close this bug as WORKSFORME.

Comment 5

[Matthew Schranz [:mjschranz]]

Correction, neither values are can be set by callers of the API. createdAt always stays the same and updatedAt is set by the API as updates are made. Same with deletedAt.