Mint MD5 hash values for Key field

[ghukill]

Purpose and background context

It was determined that columns used from the data warehouse, expected to be enduringly the same and unique, were changing across warehouse runs. These values were used for Quickbase merge fields, but this would not work if the values changed.

Values for tables Employee Appointments, Employee Salary History, and Employee Leave were needed that uniquely identified the record/row, and would not change over time from warehouse runs.

The solution was to follow a pattern already established in Employee Leave to create an MD5 hash of record values that are known to uniquely identify a record.

For example, the following is the code that mints an MD5 hash for Employee Appointments:

emp_appts_df["key"] = emp_appts_df.apply(
            lambda row: md5_hash_from_values(
                [
                    row.mit_id,
                    row.position_id,
                    row.appt_begin_date,
                    row.appt_end_date,
                ]
            ),
            axis=1,
        )

How can a reviewer manually see the effects of these changes?

New tests demonstrate how the utility function md5_hash_from_values() creates an MD5 hash from a list of strings. Each Transform task for these tables utilizes this to set a Key field (naming convention from Quickbase) from a list of values. There are tests (example, example, example) for these transforms that show the value of the Key field is expected given the input row data.

Includes new or updated dependencies?

NO

Changes expectations for external applications?

NO

What are the relevant tickets?

• https://mitlibraries.atlassian.net/browse/HRQB-36

Developer

• All new ENV is documented in README
• All new ENV has been added to staging and production environments
• All related Jira tickets are linked in commit message(s)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer(s)

• The commit message is clear and follows our guidelines (not just this PR message)
• There are appropriate tests covering any new functionality
• The provided documentation is sufficient for understanding any new functionality introduced
• Any manual tests have been performed or provided examples verified
• New dependencies are appropriate or there were no changes

[ehanson8]

Great shifting and reuse of existing code!

[ehanson8]

Good explanation of why this test is different from the others!