Change Details

####Problem In {https://phabricator.wikimedia.org/T392898}, we defined that the fields Start date and End date should both be required, and should be validated as such on submit when configuring experiments and instruments. However, users need to be able to leave the end date empty when defining data collection instruments. This means that setting an End date should not be required for instruments, and users should be allowed to leave said field empty. ####Solution We should make the End date field in the instrument configuration form optional. ####Acceptance criteria [] Users can leave the End date field empty when configuring instruments #### Technical notes Just a few considerations we should keep in mind to work on this: - End date (`utc_end_dt` column) is currently mandatory in the database (defined as `NOT NULL`) - Once we fix the above, by removing the mentioned constraint, we will find that current frontend/backend is storing `utc_end_dt` as empty string (`''`) in the database and not as a `NULL` value, which causes error there because the empty string is not an allowed value for a `DATETIME` column. We should change something to set `utc_end_dt` as `NULL` when the user doesn't fill the corresponding field in the form

####Problem In {https://phabricator.wikimedia.org/T392898}, we defined that the fields Start date and End date should both be required, and should be validated as such on submit when configuring experiments and instruments. Following the principles of [[ https://wikimediafoundation.org/who-we-are/transparency/2024-1/eu-digital-services-act-information/ | data minimization ]] we should not collect data indefinitely. Requiring an end date for an instrument reminds data collectors about this key principle. However, we want to reduce uncertainty and provide recommendations where possible, and make clear the implications of this end date. ####Solution Default the instrument's end date to the start of the next Fiscal Year. (Why? Most data collection initiatives are linked to objectives and key results as part of our APP. Having a single date to review data collection activity end date means users will be able to plan that review and make the decision on a clear cadence, rather than having to set reminders.) ####Acceptance criteria [] End date field defaults to July 1 of the next fiscal year: examples: * If I create an instrument on May 4 2026, the data collection should default to end July 1 2027. * If I create an instrument on July 2 2026, the data collection should default to end July 1 2028 [] Users can set a different end date if they so choose [] End date (`utc_end_dt` column) should remain mandatory in the database (defined as `NOT NULL`)

####Problem In {https://phabricator.wikimedia.org/T392898}, we defined that the fields Start date and End date should both be required, and should be validated as such on submit when configuring experiments and instruments. However, users need to be able to leave the end date empty when defining data collection instruments. This means that setting an End date should not be required for instruments, and users should be allowed to leave said field empty. ####Solution We should make the End date field in the instrument configuration form optionalFollowing the principles of [[ https://wikimediafoundation.org/who-we-are/transparency/2024-1/eu-digital-services-act-information/ | data minimization ]] we should not collect data indefinitely. ####Acceptance criteriaRequiring an end date for an instrument reminds data collectors about this key principle. However, we want to reduce uncertainty and provide recommendations where possible, and make clear the implications of this end date. [] Users can leave the End date field empty when configuring instruments####Solution Default the instrument's end date to the start of the next Fiscal Year. (Why? Most data collection initiatives are linked to objectives and key results as part of our APP. Having a single date to review data collection activity end date means users will be able to plan that review and make the decision on a clear cadence, rather than having to set reminders.) #### Technical notesAcceptance criteria Just a few considerations we should keep in mind to work on this:[] End date field defaults to July 1 of the next fiscal year: examples: * If I create an instrument on May 4 2026, the data collection should default to end July 1 2027. * If I create an instrument on July 2 2026, the data collection should default to end July 1 2028 - End date (`utc_end_dt` column) is cur[] Users can set a differently mandatory in the end database (defined as `NOT NULL`)e if they so choose - Once we fix the above, by removing the mentioned constraint, we will find that current frontend/backend is storing `utc_end_dt` as empty string (`''`) in the database and not as a `NULL` value, which causes error there because the empty string is not an allowed value for a `DATETIME` column. We should change something to set `utc_end_dt` as `NULL` when the user doesn't fill the corresponding field in the form[] End date (`utc_end_dt` column) should remain mandatory in the database (defined as `NOT NULL`)