Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Person] Different ages for a specific search #11788

Closed
AliciaRaber opened this issue Apr 4, 2023 · 5 comments
Closed

[Person] Different ages for a specific search #11788

AliciaRaber opened this issue Apr 4, 2023 · 5 comments
Assignees
Labels
change A change of an existing feature (ticket type) persons vaadin-app Affects the Vaadin application

Comments

@AliciaRaber
Copy link

Bug Description

If you set date filters for person in person directory the age of persons get displayed differently.

Reproduction Steps

  1. Login into SORMAS
  2. Go to menu "Persons"
  3. Enter "1989" in year of birth search field
  4. Enter "May" in month of birth search field
  5. Enter "6" in day search field
  6. Click on button "Apply filters"
  7. Check column "Age and birth of date"
  8. If you click on person ID the person opens and the correct age is visible

Expected Behavior

If you search for a specific date the age of the person the age have to be displayed correctly.

Affected Area(s)

Web app

SORMAS Version

SORMAS 1.83.0-Snapshot (70a685d)

Android version/Browser

Edge

User Role(s)

Admin

Server URL

https://test-auto.sormas.netzlink.com/

Additional Information

image

image

@AliciaRaber AliciaRaber added the bug An error or misbehavior of an existing feature (ticket type) label Apr 4, 2023
@AliciaRaber
Copy link
Author

Possible issue can result in the fact that the field is stated with "approximateAge" and there is no correct counting of the correct age.

@MateStrysewske MateStrysewske added vaadin-app Affects the Vaadin application persons major A functional requirement is incorrect or incomplete, ... (Severity for bugs/defects) labels Apr 5, 2023
@MateStrysewske MateStrysewske added this to Backlog in SORMAS Team 2 - DEV - Iteration Backlog via automation Apr 5, 2023
@sergiupacurariu sergiupacurariu self-assigned this Apr 7, 2023
@sergiupacurariu sergiupacurariu moved this from Backlog to In Progress in SORMAS Team 2 - DEV - Iteration Backlog Apr 7, 2023
@sergiupacurariu
Copy link
Contributor

sergiupacurariu commented Apr 10, 2023

@AliciaRaber @bernardsilenou @MateStrysewske
This difference comes from the flexibility with which the age and birthday fields are implemented.
First of all, let’s walk briefly through the process of adding the birthdate. This can be done in two ways:

  • By adding the birth date of the person. Once the birth year is added the age field is no longer available. It will be calculated.
  • By adding the age of the person. It is possible to add only the age without adding anything to the birth date fields.
    In order to accommodate this approach both birth date and age are stored separately in the database. The age calculation logic occurs on person details loading or if the birth year is updated. When the person's age is displayed in the person grid the data is picked from the database without any additional calculation or check.
    The following situations arrive from this approach:
  • If the user fills only the age field (no birth year) and it passes more than a year since the age was added the age remains the same. At this point, there is no automatic process to do this
  • If the user fills the birth year field then the person's age is calculated automatically, filled in the age field and the field is made read-only. Birth month and day do not count if there is no birth year. On person save the birth year and the person's age are saved in separate fields. The age field is not updated automatically so if more than a year passes the age will become obsolete.

Below you have my thoughts as a starting point:

  1. Create a CronJob which updates the person's age periodically using "Approximate age reference date"
    • Remove the age field from the database and convert the age inserted by the user to an actual year
    • Calculate the age during person grid loading, change sorting from "Approximate age" to Birth date

@sergiupacurariu sergiupacurariu moved this from In Progress to Waiting in SORMAS Team 2 - DEV - Iteration Backlog Apr 11, 2023
@MateStrysewske
Copy link
Contributor

@sergiupacurariu Is this really relevant here? Because all of these persons have a concrete birthdate, including year, month, and day, so the automatic age calculation shouldn't really have an effect here, should it? As @AliciaRaber mentioned, in the person pages themselves the age is always calculated correctly, so it's supposed to be a display issue in the person directory, right?

@sergiupacurariu
Copy link
Contributor

@MateStrysewske Indeed initially I thought the same a display issue, but after some investigation, it turned to be something else. In the person detail page the age is shown correctly because this calculation is done in toPersonDto when the person page is loaded no matter what is stored in the database. If the user would just saves the person without doing anything else then the newly calculated age will be stored in the database. If the user does this then the grid will show the correct age.

@bernardsilenou
Copy link

@MateStrysewske @sergiupacurariu

  • The computation of age can depend on the entity referenced. The age (through the case view) is generally defined as the age at the time (report date) that the person was a case. But when looking at the general person entity, then we show the age of the personal based on the current calendar date (current implementation [Person] Different ages for a specific search #11788 (comment)).
  • What about have two types of methods to compute age?
  • It's generally not a big issue if the age is not updated. The important data is the birth date.
  • Will adding a cronjob not lead to performance issues? There are instances with over 100 million persons.

@MateStrysewske MateStrysewske added change A change of an existing feature (ticket type) and removed bug An error or misbehavior of an existing feature (ticket type) major A functional requirement is incorrect or incomplete, ... (Severity for bugs/defects) labels Apr 12, 2023
@MateStrysewske MateStrysewske removed this from the Iteration 2023-04 - 1.83.0 milestone Apr 12, 2023
@SORMAS-Foundation SORMAS-Foundation locked and limited conversation to collaborators Apr 12, 2023
@MateStrysewske MateStrysewske converted this issue into discussion #11828 Apr 12, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
change A change of an existing feature (ticket type) persons vaadin-app Affects the Vaadin application
Projects
None yet
Development

No branches or pull requests

5 participants