🔧 chore(aci): add action group to action handler abc

[iamrajjoshi]

so that the ui can group different action types together, we introduce a action_group class variable on the NotificationActionHandler which will let us group different types of notification actions togather.

defined the groups based on

[codecov]

Codecov Report

Attention: Patch coverage is 98.24561% with 1 line in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...low_engine/handlers/action/notification/handler.py	98.07%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #87259      +/-   ##
==========================================
- Coverage   87.74%   87.73%   -0.01%     
==========================================
  Files        9863     9863              
  Lines      558344   558658     +314     
  Branches    22024    22024              
==========================================
+ Hits       489892   490164     +272     
- Misses      68069    68111      +42     
  Partials      383      383              

[codecov]

Codecov Report

Attention: Patch coverage is 98.24561% with 1 line in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...low_engine/handlers/action/notification/handler.py	98.07%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #87259     +/-   ##
=========================================
  Coverage   87.74%   87.74%             
=========================================
  Files        9863     9864      +1     
  Lines      558344   559356   +1012     
  Branches    22024    22024             
=========================================
+ Hits       489892   490830    +938     
- Misses      68069    68143     +74     
  Partials      383      383             

Pull Request Overview

This PR introduces an action group feature for notification action handlers so that actions can be categorized into groups (e.g. NOTIFICATION, TICKET_CREATION, OTHER). The changes add a new ActionGroup enumeration in the types module and update the handler registrations to assign each action handler a group.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/sentry/workflow_engine/handlers/action/notification/handler.py	Added new functions to execute notifications via a group type registry and updated action handler classes to assign groups.
src/sentry/workflow_engine/types.py	Introduced a new ActionGroup enum and a group class variable on ActionHandler.

Comments suppressed due to low confidence (2)

src/sentry/workflow_engine/handlers/action/notification/handler.py:133

• Rename 'GithubActionHandler' to 'GitHubActionHandler' for consistency with the proper branding.

class GithubActionHandler(NotificationActionHandler):

src/sentry/workflow_engine/handlers/action/notification/handler.py:138

• Rename 'GithubEnterpriseActionHandler' to 'GitHubEnterpriseActionHandler' to maintain consistent naming conventions.

class GithubEnterpriseActionHandler(NotificationActionHandler):

[saponifi3d]

🎉 such SOLID design - also like that now we have a place to easily override the data_schema if any of these require different data attributes (same thing for the config 🎉) -- we could now have strict enforcement per type. For example, that would mean if Discord requires the target_identifier and none of the other properties, we could setup the config_schema on this class to be different.

[iamrajjoshi]

yep i saw how useful it would be here when i made this pr to override the config schema:
#87372

[saponifi3d]

If you want to make this even moar SOILD, you could define the execute interface on the ABC then invoke the execute_via_group_type_registry in each class. it's a bit of replication, but it would be how you uphold the I in solid (inversion principle).

that said, i don't think we'd gain much value from doing that work unless we plan to start overriding this method in the individual action handlers (we could do this refactor when that use case arises), just wanted to call out the example. :)

[saponifi3d]

Suggested change

	group = NotificationActionHandler.ActionGroup.NOTIFICATION
	group = ActionHandler.Group.NOTIFICATION

^ we should probably access this from the top level ActionHandler -- that way it's a little clearer that this is defined a little higher up the OOP stack.

[saponifi3d]

Suggested change

	class ActionGroup(StrEnum):
	class Group(StrEnum):

nit: ActionHandler.ActionGroup makes Action in ActionGroup feel a little redundant. Then in each handler it could be: ActionHandler.Group.TICKET_CREATION which reads pretty cleanly to me.