Custom routes + Further notification cleanup

[ttannis]

Summary of Changes

This PR adds a new feature to allow the configuration of custom and completes some cleanup in the notifications code.

1. There is a new config variable INIT_CUSTOM_ROUTES. It is a Callable that takes a Flask application and is called during create_app. This allows individuals to configure custom endpoints to support custom logic. In our case at Lyft, we are using it to hook on a new endpoint to our frontend application that will process some internal callback to generate some custom metrics.

2. In our python code I have added an enum class NotificationType, that matches the NotificationType interface in the frontend application, and replaced all usages of hardcoded notification type strings to leverage the enum class. This makes it easier to maintain the code snd prevent some human error when it comes to writing our notification logic.

3. For notification emails, instead of passing "notification" as the email type, we will pass the exact notification_type instead. This is more helpful because it will allow custom mail clients to execute specific logic based on the notification_type.

4. In _build_metrics() in action_log.py we now catch any exceptions that occur when getting the user for metrics, and fallback to the default. The reason is that actions that are logged in any of the custom routes, if that endpoint was hit by another service as opposed to being the result of a user action -- the AUTH_USER_METHOD might encounter some error.

Tests

Added a python test to cover calling get_notification_subject() with an unsupported notification type.

Documentation

Added documentation for INIT_CUSTOM_ROUTES to flask_config.md.

CheckList

Make sure you have checked all steps below to ensure a timely review.

• PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.
• PR includes a summary of changes, including screenshots of any UI changes.
• PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public python functions and the classes in the PR contain docstrings that explain what it does
• PR passes all tests documented in the developer guide

[codecov-io]

Codecov Report

Merging #309 into master will increase coverage by 0.02%.
The diff coverage is 83.33%.

@@            Coverage Diff            @@
##           master    #309      +/-   ##
=========================================
+ Coverage   71.57%   71.6%   +0.02%     
=========================================
  Files         143     143              
  Lines        3684    3701      +17     
  Branches      459     462       +3     
=========================================
+ Hits         2637    2650      +13     
- Misses       1014    1018       +4     
  Partials       33      33

Impacted Files	Coverage Δ
amundsen_application/config.py	100% <100%> (ø)	⬆️
..._application/static/js/interfaces/Notifications.ts	100% <100%> (ø)	⬆️
...undsen_application/api/utils/notification_utils.py	91.83% <76.47%> (-3.35%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a90e8a...9660544. Read the comment docs.

[ttannis]

@jinhyukchang can you give your input on the changes in amundsen_application/log/action_log.py?

Now that I think about it, we could also modify our our custom authentication method and return some default "service user" for our new use case where a service is hitting a custom endpoint as opposed to a real user. What do you think?

[ttannis]

Reverted the change to _build_metrics in favor of a modification to our custom AUTH_USER_METHOD.

[ttannis]

@danwom PTAL

[danwom]

Looks fine on my end, but maybe you'll want to get @jinhyukchang to look as well?

[ttannis]

Looks fine on my end, but maybe you'll want to get @jinhyukchang to look as well?

Jin was fine with the changes I tagged him to look at in our private repo, will go ahead and merge this.