Add var to persist former-agents' roles for SLA metrics

[fivetran-jamie]

PR Overview

This PR will address the following Issue/Feature:
fivetran/dbt_zendesk#120 and #40

This PR will result in the following new package version:

v0.10.1 -- by default nothing will change for folks. they'll need to explicitly set the internal user criteria var

Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:

dbt_zendesk_source v0.10.1

PR #43 introduces the following updates:

Feature Updates

• Added the internal_user_criteria variable, which can be used to mark internal users whose USER.role may have changed from agent to end-user after they left your organization. This variable accepts SQL that may reference any non-custom field in USER, and it will be wrapped in a case when statement in the stg_zendesk__user model.
  • Example usage:

# dbt_project.yml
vars:
  zendesk_source:
    internal_user_criteria: "lower(email) like '%@fivetran.com' or external_id = '12345' or name in ('Garrett', 'Alfredo')" # can reference any non-custom field in USER

• Output: In stg_zendesk__user, users who match your criteria and have a role of end-user will have their role switched to agent. This will ensure that downstream SLA metrics are appropriately calculated.

Under the Hood

• Updated the way we dynamically disable sources. Previously, we used a custom meta.is_enabled flag, but, since we added this, dbt-core introduced a native config.enabled attribute. We have opted to use the dbt-native config instead.
• Updated the pull request templates.
• Included auto-releaser GitHub Actions workflow to automate future releases.

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt run –full-refresh && dbt test
• dbt run (if incremental models are present)

Before marking this PR as "ready for review" the following have been applied:

• The appropriate issue has been linked, tagged, and properly assigned
• All necessary documentation and version upgrades have been applied
• docs were regenerated (unless this PR does not include any code or yml updates)
• BuildKite integration tests are passing
• Detailed validation steps have been provided below

Detailed Validation

Please share any and all of your validation steps:

Will validate internally with @jackiexsun

[fivetran-joemarkiewicz]

Omg love this example!

[fivetran-jamie]

reminder to myself to add this to the transform README (no release needed there tho) after approval

[fivetran-joemarkiewicz]

@fivetran-jamie just a few comments around the changes. Once you reply to them and make any updates then let me know for re-review and I can check again and approve.

[fivetran-joemarkiewicz]

Maybe it would be relevant to include here that this is used as a case when clause in the staging model. Just so users know the context of the variable. The example shows this well, but I feel a bit of an explanation to this would be helpful to someone new to the concept.

[fivetran-jamie]

added a brief note!

[fivetran-joemarkiewicz]

Can we include a similar update to one I suggested in the CHANGELOG here as well?

[fivetran-jamie]

added a little something

[fivetran-joemarkiewicz]

I didn't know that false would work in this context. I thought it would need to be [] (or something like that). Are we sure this works on all dbt versions supported by the package? It may be worthwhile to test this on dbt 1.3.0 just to make sure.

[fivetran-jamie]

just ran it on dbt-bigquery==1.3.0 with and without providing internal_user_criteria: "lower(email) like '%@fivetran.com'" and it works as expected 😄

yeah i think it works similarly to how we provide false (or true i suppose) as the default value for using_<possibly missing source table> variables

[fivetran-joemarkiewicz]

@fivetran-jamie these changes look good to me. I just have one small request to update the example snippet before moving the a release review as I ran into a small issue when trying to copy/paste the snippet provided.

Thanks!