Closed shurwit closed 3 months ago
Hi @shurwit,
I think you messed up a little two strategies in the definition of the URL parameters for GET /surveys
that would be designed for survey start and end dates.
Since the client app is interested in only the currently "active" surveys, the URL parameters that it will get passed (as defined currently) will allways be:
GET /surveys?before=now&after=now&...
where now
is the current timestamp.
In my opinion, there are two options for definition of time filtering URL parameters:
A. Assuming that only the active surveys will be requested, we can use a single datetime URL parameter that will pass the current datetime. If applied, the filter will be (start_date < current_date) AND (end_time > current_date)
. Something more, we can even use boolean URL parameter, e.g. "active", and let the backend determine the current datetime and apply the above filtering.
B. If we want to expose the full potential strength of datetime filtering in GET , we should expose 4 URL parameters like:
starts_before: start_date < starts_before;
starts_after: start_date > starts_after;
ends_before: end_date < ends_before;
ends_after: end_date > ends_after.
We already used this model in POST /events/load from Calendar BB, and it is proven to do the work. For a long time i would bet on option B.
Thanks for pointing out this issue @mihail-varbanov, I was rushing a bit when writing the spec and clearly didn't think it all through. I agree that we should move ahead with option B in order to do this the right way from the start.
@stefanvit , please let us know if you have any questions about this.
Thanks!
Thanks for pointing out this issue @mihail-varbanov, I was rushing a bit when writing the spec and clearly didn't think it all through. I agree that we should move ahead with option B in order to do this the right way from the start.
@stefanvit , please let us know if you have any questions about this.
Thanks!
Hi @shurwit , i dont have any questions. I think is the same as it is in CallendarBB if i am understanding right, so i will do it first thing tomorrow.
Is your feature request related to a problem? Please describe. Currently we do not have a concept of when surveys are active vs inactive.
Describe the solution you'd like We should add a
start_date
andend_date
field to the survey data structure. By default if nostart_date
is provided we should set this field to the current timestamp.We should also support
before
andafter
query params on theGET /surveys
endpoint. Thebefore
query param should apply a filter to load only surveys with anstart_date
property before the date specified. Theafter
query param should apply a filter to load only surveys with aend_date
property after the date specified. These results should be sorted reverse chronologically bystart_date
.