Closed kmcculloch closed 7 years ago
This is a perfect use case for selectors. Selectors are meant to compute state on existing models. I've added a commit that encapsulate "stale" detection, importing it in the new UrlLock
component (nice add, btw) and imports/api/url.js
. Also modified the admin checkin button to be a little more "warning, this is a forceful action".
I've discussed this with @kmcculloch on slack & he approves. merging!
Addresses https://github.com/edgi-govdata-archiving/archivers.space/issues/32
This change allows admin users to check URLs back in after they've been checked out for two weeks. It's not a cron job, but it's a start.
I'm trying to figure out how best to encapsulate control logic in this framework. On the UI end, I've pulled all of the logic for the URLs page into a UrlLock component. This gives us a single point of reference for answering the two UI questions: what state is this URL in? and what can the current user do about it?
But to impose the "check in by admins after two weeks" logic, I've had to duplicate the date check: once in the urls api object, to enforce the rule, and once in the UI component to determine whether to give the user the option to unlock. This redundancy seems wrong to me. When we change the rule to allow check-in after, say, one week, I hate the idea of hunting for the same logic throughout the code and changing it in multiple places.
I think there should either be an independent utility that accepts a URL and calculates whether it's unlockable, or there should be an "I am expired?" calculator attached to all URL objects.
Thoughts?