[FEATURE] Start/end date

[shurwit]

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 and end_date field to the survey data structure. By default if no start_date is provided we should set this field to the current timestamp.

We should also support before and after query params on the GET /surveys endpoint. The before query param should apply a filter to load only surveys with an start_date property before the date specified. The after query param should apply a filter to load only surveys with a end_date property after the date specified. These results should be sorted reverse chronologically by start_date.

[mihail-varbanov]

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.

[shurwit]

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!

[stefanvit]

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.