It can be useful for org admins to see more than one week's worth of shift
occurrences. For example to look farther into the future to see when shifts need
to be filled, or to audit a site or volunteer over a few months. The current
single week view is pretty limiting.
This adds a start and end time to the shift filter that allows someone to pick
start and end date. The filter now sets the time range instead of the
controller. This also allows us to add some methods to the filter which let us
cleanly set a url to navigate back and forward through the window of shifts.
I tried at first to move the timeline inside the shift filter, but to make a
timeline requires a list of shifts, users, or an organization. That parameter
would get passed to the filter, which would then mean there are extra attributes
that had nothing to do with the filter. An org is the most minimal thing to
pass, but we can't allow someone to enter an org id in the url to see data from
other orgs. In addition to the security risk and a broken abstraction, it would
also complicate how we turn the filter into params.
I also put a max duration on the filter so someone doesn't accidentally or on
purpose overload the server. If there are any other filters, the max range is 1
year. If there are no filters, the max duration is 4 months.
new filter
It can be useful for org admins to see more than one week's worth of shift
occurrences. For example to look farther into the future to see when shifts need
to be filled, or to audit a site or volunteer over a few months. The current
single week view is pretty limiting.
This adds a start and end time to the shift filter that allows someone to pick
start and end date. The filter now sets the time range instead of the
controller. This also allows us to add some methods to the filter which let us
cleanly set a url to navigate back and forward through the window of shifts.
I tried at first to move the timeline inside the shift filter, but to make a
timeline requires a list of shifts, users, or an organization. That parameter
would get passed to the filter, which would then mean there are extra attributes
that had nothing to do with the filter. An org is the most minimal thing to
pass, but we can't allow someone to enter an org id in the url to see data from
other orgs. In addition to the security risk and a broken abstraction, it would
also complicate how we turn the filter into params.
I also put a max duration on the filter so someone doesn't accidentally or on
purpose overload the server. If there are any other filters, the max range is 1
year. If there are no filters, the max duration is 4 months.
