search

distributeaid / aggregated-public-information

https://aggregated-public-information.vercel.app
1 stars 4 forks source link

Survey year should be an integer not a string, right? #127

Open veryeli opened 2 months ago

veryeli commented 2 months ago

Just because this kind of migration is difficult after the fact.

ll-zerr commented 2 months ago

I agree, having the survey year as an integer would be best. The issue that arose when creating it as an integer was that Strapi displays it as a 4-digit number with a comma (X,XXX) which doesn't reflect it as a year. Regex was the adopted solution for the time being with the hope that Strapi would eventually have a more applicable option. If you know of any other solutions/suggestions for this that would be awesome!

guel-codes commented 3 weeks ago

I would leave year as a string just incase there is a need to concat the year and quarter (i.e. 2024Q3) they will be the same type. It might make it a little easier that way.

guel-codes commented 3 weeks ago

We should also try to find a way to automate the default year so we don't have to keep changing it. Something like this: const defaultYear = new Date().getFullYear();

jtfairbank commented 2 weeks ago

@veryeli @ll-zerr looks like we settled on a consensus to leave the year as a string. Can I close this PR?

Agree that it'd be nice to automate the default year but I don't see a way to do that b/c the schemas are a .json file. Open to ideas here, might be worth making an issue for this one in case someone comes up with a solution?

guel-codes commented 2 weeks ago

Yeah good call. Not sure how we could handle it exactly. There are these lifecycle hooks in Strapi that could let us grab the year on the fly before or after an action. https://docs.strapi.io/dev-docs/backend-customization/models#lifecycle-hooks

jtfairbank commented 2 weeks ago

@guel-codes definitely a good shout. I don't see us manually entering needs data via the CMS. My guess is that most of the data will be sent to the server, via the API via upload scripts for existing data or form entries for new Needs Assessment data once the new tool is up. All the current needs data has the year specified, and the year can be set on the client programatically when filling out a new Needs Assessment survey.

Maybe we just remove the default year and require the sending side to specify a correct year?