increase datepicker limit

[MateoLostanlen]

let's use a year as requested by firefighters

[fe51]

@MateoLostanlen asked by 77 ? It means it enforced to store data for 1year on pyro-api.

Sorry to challenge it now, but I'm curious to know when it would be useful to them?

Maybe we need to keep the last summer's data for feedback purposes, so would six months be appropriate?

Alternatively, we could stick with a period of around three months and export data on demand if necessary?

What do you think?

[MateoLostanlen]

Hi @fe51

Yes, it was requested by the 77, they need to do the feedback analysis, so 3 months isn’t enough to access the images from June right now

I figured that keeping them for 1 year allows us to cover from last summer to the next one, same for us to showcase interesting fires

It’s really not a problem to keep the images for a year, it doesn’t prevent us from annotating them in the meantime.
Why don’t you want to keep them for a year? Is it because of storage costs?

I’m not a fan of on-demand exports, we should minimize manual tasks as much as possible

[fe51]

Yes, it was about storage costs (in the long term as long number of stations is going to rise) and also just wondering their use case (from time to time, users are happy to know they can do something but do not use the feature)

To showcase, why not, but might be even better to put them in the dev env ? (to have them on hand after a year)

Also, the flusing process of img in the alert api in manuel so far ?

[MateoLostanlen]

Overall I agree with you, but for now none of that is in place, so it’s convenient to keep access to the alerts through the platform

There’s no flushing mechanism implemented yet

So I suggest setting up a clean pipeline:
Export via the annotation API and extract key alerts to the dev environment,
then perform a periodic flush of the alert API every six months for example

Once we have that in place, we can restrict platform access on the same schedule

[fe51]

Sounds good !