Skip to content
This repository was archived by the owner on Jul 27, 2025. It is now read-only.

Fix: make date format year consistent overall #1712#1726

Merged
zachgoll merged 6 commits intomaybe-finance:mainfrom
scodes73:fix-1712
Feb 3, 2025
Merged

Fix: make date format year consistent overall #1712#1726
zachgoll merged 6 commits intomaybe-finance:mainfrom
scodes73:fix-1712

Conversation

@scodes73
Copy link
Contributor

@scodes73 scodes73 commented Jan 28, 2025

Fixes simple year formatting, making it consistent everywhere
Fixes : https://github.com/maybe-finance/maybe/issues/1712
Before:
image
After:
Unsaved Image 1

@scodes73 scodes73 changed the title Fix: make date format year consistent overall Fix: make date format year consistent overall #1712 Jan 28, 2025
Copy link
Contributor

@zachgoll zachgoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tackling this!

There are a few more spots in the codebase where these date formats are used. I think this may be a good time to consolidate some of these and centralize so that changes like these can be quicker (i.e. referencing a helper method for all of the import forms that use these date formats)

CleanShot 2025-01-28 at 11 11 01

@scodes73
Copy link
Contributor Author

There are a few more spots in the codebase where these date formats are used. I think this may be a good time to consolidate some of these and centralize so that changes like these can be quicker (i.e. referencing a helper method for all of the import forms that use these date formats)

Using date_format_options from app/helps/application_helper.rb for the date formats.
Made changes in:

  1. app/views/import/configurations/_mint_import.html.erb
  2. app/views/import/configurations/_trade_import.html.erb
  3. app/views/import/configurations/_transaction_import.html.erb

It's adding more formats [ "D/MM/YYYY", "%e/%m/%Y" ], [ "YYYY.MM.DD", "%Y.%m.%d" ], Is it fine having these 2 as well in these?

@scodes73 scodes73 requested a review from zachgoll January 28, 2025 17:55
@scodes73
Copy link
Contributor Author

Also, Should we have required both in HTML attributes and also in the attributes section as well.
<%= form.select :date_format, date_format_options, { label: t(".date_format"), required: true}, label: true, required: true, disabled: import.complete? %> Here we're having required in both sections, is it required? I'm not sure if the required parameter is checked else where manually through code

@zachgoll
Copy link
Contributor

@scodes73 looking better! The required attribute only needs to be written once per input. It should be in the attributes section, not the select options.

I think the last step here is to consolidate that list of formats that we have in family.rb with the list in application_helper. Ideally, I think we actually remove the helper from application_helper entirely and store the canonical list of date formats directly in the Family model:

class Family < ApplicationRecord
  DATE_FORMATS = [
    [ "MM-DD-YYYY", "%m-%d-%Y" ],
    [ "DD.MM.YYYY", "%d.%m.%Y" ],
    [ "DD-MM-YYYY", "%d-%m-%Y" ],
    [ "YYYY-MM-DD", "%Y-%m-%d" ],
    [ "DD/MM/YYYY", "%d/%m/%Y" ],
    [ "YYYY/MM/DD", "%Y/%m/%d" ],
    [ "MM/DD/YYYY", "%m/%d/%Y" ],
    [ "D/MM/YYYY", "%e/%m/%Y" ],
    [ "YYYY.MM.DD", "%Y.%m.%d" ]
  ].freeze
end

Then, in our forms, we can use Family::DATE_FORMATS as options and have confidence that these are only defined in one spot across the entire app

@scodes73
Copy link
Contributor Author

@scodes73 looking better! The required attribute only needs to be written once per input. It should be in the attributes section, not the select options.

I think the last step here is to consolidate that list of formats that we have in family.rb with the list in application_helper. Ideally, I think we actually remove the helper from application_helper entirely and store the canonical list of date formats directly in the Family model:

class Family < ApplicationRecord
  DATE_FORMATS = [
    [ "MM-DD-YYYY", "%m-%d-%Y" ],
    [ "DD.MM.YYYY", "%d.%m.%Y" ],
    [ "DD-MM-YYYY", "%d-%m-%Y" ],
    [ "YYYY-MM-DD", "%Y-%m-%d" ],
    [ "DD/MM/YYYY", "%d/%m/%Y" ],
    [ "YYYY/MM/DD", "%Y/%m/%d" ],
    [ "MM/DD/YYYY", "%m/%d/%Y" ],
    [ "D/MM/YYYY", "%e/%m/%Y" ],
    [ "YYYY.MM.DD", "%Y.%m.%d" ]
  ].freeze
end

Then, in our forms, we can use Family::DATE_FORMATS as options and have confidence that these are only defined in one spot across the entire app

Done, let me know of any more changes. Thank you for guiding me thoroughly :)

Copy link
Contributor

@zachgoll zachgoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks for tackling this!

@zachgoll
Copy link
Contributor

@scodes73 looks like we have a few tests failing for i18n translations. You can run the following commands to see which ones are unused/missing:

bundle exec i18n-tasks unused -l en
bundle exec i18n-tasks missing -l en

@scodes73
Copy link
Contributor Author

@scodes73 looks like we have a few tests failing for i18n translations. You can run the following commands to see which ones are unused/missing:

bundle exec i18n-tasks unused -l en
bundle exec i18n-tasks missing -l en

I've made new changes:
image

But it marks the variable as unused, I could always change it to individual labels if you want me to

image

@scodes73
Copy link
Contributor Author

scodes73 commented Feb 1, 2025

But it marks the variable as unused, I could always change it to individual labels if you want me to

Now reverting to the previous state of individual translations

@scodes73 scodes73 requested a review from zachgoll February 2, 2025 18:13
Copy link
Contributor

@zachgoll zachgoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@zachgoll zachgoll merged commit f57fa52 into maybe-finance:main Feb 3, 2025
5 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Incorrect date format option for CSV imports

2 participants