The Notification struct doesn't include the subject's ID or number (e.g. issue number, PR number), even though the underlying forge APIs provide this information.
- GitHub:
notification.Subject.URL contains /repos/owner/repo/issues/123
- GitLab:
todo.Target.IID is the issue/MR number directly
- Gitea/Forgejo:
notification.Subject.HTMLURL contains the issue/PR number in the URL path
Currently the conversion functions in github/notifications.go, gitlab/notifications.go, and gitea/notifications.go read the subject title and type but discard the subject URL and ID.
Adding a SubjectID (or SubjectNumber) and SubjectURL field to the Notification struct would let consumers link notifications to their underlying issues/PRs without making additional API calls.
The URL field is also inconsistent across forges: GitHub sets it to the repository HTML URL, while GitLab and Gitea set it to the subject URL. Having separate URL (subject web URL) and Repo fields would make this unambiguous.
The Notification struct doesn't include the subject's ID or number (e.g. issue number, PR number), even though the underlying forge APIs provide this information.
notification.Subject.URLcontains/repos/owner/repo/issues/123todo.Target.IIDis the issue/MR number directlynotification.Subject.HTMLURLcontains the issue/PR number in the URL pathCurrently the conversion functions in github/notifications.go, gitlab/notifications.go, and gitea/notifications.go read the subject title and type but discard the subject URL and ID.
Adding a
SubjectID(orSubjectNumber) andSubjectURLfield to the Notification struct would let consumers link notifications to their underlying issues/PRs without making additional API calls.The URL field is also inconsistent across forges: GitHub sets it to the repository HTML URL, while GitLab and Gitea set it to the subject URL. Having separate
URL(subject web URL) andRepofields would make this unambiguous.