Update field selection, etc

[fivetran-jamie]

Are you a current Fivetran customer?

Fivetran made PR

What change(s) does this PR introduce?

• incorporates new passthrough column format (will be documented in readme later)
• temporarily points to a branch of fivetran utils where the passthrough column macros i have added are now backwards compatible
• break out staging column macros into their own respective files
• includes new fields (will document later)
• moves aliasing of fields to staging models, where we no longer select *
• renamed the CTEs to be consistent with new template
• create an empty refund table if there's no source table (adapted from https://github.com/fivetran/dbt_zendesk_source/blob/main/models/tmp/stg_zendesk__ticket_schedule_tmp.sql)
• reverts aliasing of _at fields to _timestamp (so we don't change their names. did this for consistency across the package)
• removed a field that will be replaced by a new staging model

Did you update the CHANGELOG?

• Yes

NOT ENTIRELY i just noted the models i switched the timestamp column names in bc it was a low lift

Does this PR introduce a breaking change?

• Yes (please provide breaking change details below.)
• No (please provide an explanation as to how the change is non-breaking below.)

its base branch is a breaking change

Did you update the dbt_project.yml files with the version upgrade (please leverage standard semantic versioning)? (In both your main project and integration_tests)

• Yes

NA

Is this PR in response to a previously created Bug or Feature Request

• Yes, Issue/Feature [Feature] Call out column names in staging models #34
• No

How did you test the PR changes?

• CircleCi
• Local (please provide additional testing details below)

Select which warehouse(s) were used to test the PR

• BigQuery
• Redshift
• Snowflake
• Postgres
• Databricks
• Other (provide details below)

Provide an emoji that best describes your current mood

⛈️

Feedback

We are so excited you decided to contribute to the Fivetran community dbt package! We continue to work to improve the packages and would greatly appreciate your feedback on our existing dbt packages or what you'd like to see next.

[fivetran-reneeli]

Thanks Jamie! Just had some minor comments

[fivetran-reneeli]

Do you mind explaining why this model is different than the rest?

[fivetran-jamie]

if i remember correctly, a request to do this came from a customer to @fivetran-joemarkiewicz ... joe would you mind elaborating here if i didn't make that up lol

[fivetran-joemarkiewicz]

The refund tables are only synced once a refund is provided. Therefore, a customer could go months without refunding anything and never use that table. However, the second a refund is provided this table will be synced.

The experience from the customer was that it was difficult to maintain when refunds started. This is not a "I don't use this feature" as it is always used, but will only start syncing once a refund is provided. Customers shouldn't have to worry about managing their dbt project once refunds are processed. Therefore we took the approach of having this refund table be one that syncs as empty if it is not populated, then seamlessly switches to the source table once it exists.

[fivetran-reneeli]

Looks good!