Uploaded image for project: 'CFA MX '
  1. CFA MX
  2. CFAMX-1161

Investigate options for inheriting culture specific settings

    Details

    • Type: Story
    • Status: Closed (View Workflow)
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: CFA 2019R1
    • Component/s: Core
    • Labels:
      None
    • Sprint:
      CFAMX 2019R1 Sprint 5
    • SOW (Time Tracking) Project:
      44866
    • Work Type Classification:
      Sustaining

      Description

      Further to conversation with Rehan Weber and Kevin Reid.

      The implementation undertaken to support localization of date formats in MxC is based on Short and Long date formats defined in tbEntity and tbUser.

      When making the decision about which culture (Language and date formats) to display, the system checks in this order.

      1. Check for a user override, if one exists use this setting, else:
      2. Check for an entity override, if one exists use this setting, else:
      3. Use the setting for the system default culture

      These User and Entity settings will require maintenance and there is the possibility that data may get out of sync.

      • This story is to investigate the best option to implement a maintainable/scalable solution

      Will's suggestion:

      • Extend tbLocalisation to include Short Date Format and Long Date Format
        • Update /MMS_System_CultureAdmin.aspx to include the two new fields
        • Stretch - Update the page to support Adding the Date Formats via the UI
      • Ideally, we would look at this table to figure out the Date Formats (i.e. not need to set them at the Entity / User level)
        • If a Locale/Culture does not have the Short and Long format specified, it should look at the parent, in the same way that the localization does
      • Using this method, it is not necessary to maintain the Short and Long Format fields at the Entity and User, instead, once the Localization/Culture is set these values will be derived from that Culture

      However

      • If it is easier/more expedient to leverage the db format that we have in place we can use it, but will need to make other changes.
        • If the Localization is selected in the Entity Manager, the Short and Long Date should be updated to match those stored in tbLocalisation. If the Localization = Default Language, use the Short and Long Date formats for the Default Language
        • If the Locale is selected for a User, the Short and Long Date should be updated to match those stored in tbLocalisation.If the Localization = Not Set, use the Short and Long Date formats for the Default Language
      • This approach would require changes to:
        • Employee Setup
        • Entity Manager
        • Employee Details Import
        • Location/Entity Import

        Attachments

          Issue Links

          There are no Sub-Tasks for this issue.

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                will.englefield Will Englefield (Inactive)
              • Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 4h Original Estimate - 4h
                  4h
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 8h
                  8h

                    PagerDuty

                    Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.