Skip to content

🐛 Bug: Issues created or updated via REST API send no notifications or emails#9307

Open
wildsurfer wants to merge 2 commits into
makeplane:previewfrom
wildsurfer:fix/api-issue-notifications
Open

🐛 Bug: Issues created or updated via REST API send no notifications or emails#9307
wildsurfer wants to merge 2 commits into
makeplane:previewfrom
wildsurfer:fix/api-issue-notifications

Conversation

@wildsurfer

@wildsurfer wildsurfer commented Jun 24, 2026

Copy link
Copy Markdown

Description

When a work item is created, updated, or assigned through the external REST API
(/api/v1/...), no in-app notification and no email are sent to the assignees
and subscribers. The same actions in the web app send them correctly, and SMTP
works (OTP and web-app notification emails arrive), so the notification pipeline
itself is fine.

Root cause: the notification fan-out is gated by the notification flag passed
to the issue_activity background task, which defaults to notification=False
(apps/api/plane/bgtasks/issue_activities_task.py). The external API issue
create and update endpoints in apps/api/plane/api/views/issue.py call
issue_activity.delay(...) without notification=True (and without origin),
so notifications.delay(...) is never scheduled. The web app views
(apps/api/plane/app/views/issue/base.py) pass notification=True and
origin=base_host(request=request, is_app=True), which is why the web app
notifies. In the same API file the attachment and relation endpoints already
pass notification=True; only issue create/update did not.

Fix: pass notification=True and origin=base_host(request=request, is_app=True)
to the issue_activity.delay(...) calls for issue create and update/assign, the
same way the web app views do. base_host is already imported in the file and is
already used by the sibling model_activity.delay(...) calls in the same methods.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Improvement (change that would cause existing functionality to not work as expected)
  • Code refactoring
  • Performance improvements
  • Documentation update

Screenshots and Media (if applicable)

N/A

Test Scenarios

Added a contract test file apps/api/plane/tests/contract/api/test_issues.py
(class TestIssueNotificationContract, marked @pytest.mark.contract). Each test
patches plane.api.views.issue.issue_activity and asserts the dispatched activity
has notification=True:

  1. test_create_issue_triggers_notificationPOST /api/v1/.../issues/ returns
    201 and dispatches issue_activity.delay once with type="issue.activity.created"
    and notification=True.
  2. test_update_issue_triggers_notificationPATCH /api/v1/.../issues/{id}/
    (rename) returns 200 and dispatches issue_activity.delay once with
    type="issue.activity.updated" and notification=True.
  3. test_assign_issue_triggers_notificationPATCH /api/v1/.../issues/{id}/
    (assign to a project member) returns 200 and dispatches issue_activity.delay
    once with type="issue.activity.updated" and notification=True.

The tests fail before the change (the notification kwarg is absent) and pass
after it. Ran them against Postgres, Redis and RabbitMQ: 3 passed. Also ran
ruff (rules E, F per apps/api/pyproject.toml) and ruff format on the
changed files: no issues.

References

Fixes #9306

Summary by CodeRabbit

  • Bug Fixes
    • Issue creation and updates now consistently trigger notifications, including when assigning or editing an issue.
    • Improved issue activity tracking so updates are recorded with the correct context.

@CLAassistant

CLAassistant commented Jun 24, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@coderabbitai

coderabbitai Bot commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

The API issue create, update, and assignee paths now pass notification=True and origin=base_host(...) into issue_activity.delay(...). A new contract test module exercises create, rename, and assign requests and checks that the task is dispatched with notifications enabled.

Changes

Issue API Notification Fix

Layer / File(s) Summary
Add notification=True and origin to issue_activity.delay calls
apps/api/plane/api/views/issue.py
IssueListCreateAPIEndpoint.post, IssueDetailAPIEndpoint.put, and IssueDetailAPIEndpoint.patch now pass notification=True and origin=base_host(...) into issue_activity.delay(...) for issue create and update activity events.
Contract tests for notification dispatch
apps/api/plane/tests/contract/api/test_issue_notifications.py
New fixtures create a project, an existing issue, and an assignee user; the contract tests patch issue_activity and verify create, rename, and assignee requests dispatch the task once with notification=True.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

I nibbled the bug from the issue trail,
And hopped notification=True into the mail.
Create and update now dance just right,
With task calls thumping through day and night.
🐇 A carrot-bright cheer for the API warren!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the bug fix for missing API notifications and emails.
Description check ✅ Passed The description follows the template and includes the change summary, type, tests, screenshots, and reference.
Linked Issues check ✅ Passed The code changes match #9306 by adding notification parameters to API issue activity calls and covering create/update/assign with tests.
Out of Scope Changes check ✅ Passed The added contract tests are aligned with the fix and no unrelated changes are evident.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@wildsurfer

Copy link
Copy Markdown
Author

I assume the coderabbitai Bot is overthinking here. I don't see any necessity in unit tests as there is no logic to isolate.

@dheeru0198 @pablohashescobar

@sangeethailango

Copy link
Copy Markdown
Member

Hi @wildsurfer, Thank you for your contribution. The changes are looking good. Just one small change. could you rename the test file to test_issue_notifications.py instead of test_issues.py, since these tests are specifically for notifications?

Thanks.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
apps/api/plane/tests/contract/api/test_issue_notifications.py (1)

116-135: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Optionally assert the assignment actually persisted.

The create/update tests verify the side effect (issue exists / renamed) before checking dispatch, but the assign test only checks status and the notification kwargs. Adding an assertion that the assignee is attached would make the test resilient to a regression where the response is 200 yet the assignment silently doesn't persist.

♻️ Proposed assertion
         assert response.status_code == status.HTTP_200_OK
+        create_issue.refresh_from_db()
+        assert create_issue.assignees.filter(id=assignee_user.id).exists()

         mock_issue_activity.delay.assert_called_once()
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/api/plane/tests/contract/api/test_issue_notifications.py` around lines
116 - 135, The assign-issue test only verifies the notification dispatch and
HTTP status, so it should also confirm the assignment persisted on the issue. In
test_assign_issue_triggers_notification, after the api_key_client.patch call and
before checking issue_activity.delay, assert the issue returned by create_issue
has the assignee_user attached (using the issue/assignees relationship on the
issue model) so a 200 response cannot hide a failed assignment update.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@apps/api/plane/tests/contract/api/test_issue_notifications.py`:
- Around line 116-135: The assign-issue test only verifies the notification
dispatch and HTTP status, so it should also confirm the assignment persisted on
the issue. In test_assign_issue_triggers_notification, after the
api_key_client.patch call and before checking issue_activity.delay, assert the
issue returned by create_issue has the assignee_user attached (using the
issue/assignees relationship on the issue model) so a 200 response cannot hide a
failed assignment update.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3fefc8d0-6670-4ce9-a6c8-df32328192be

📥 Commits

Reviewing files that changed from the base of the PR and between 1e8f363 and 0755f94.

📒 Files selected for processing (2)
  • apps/api/plane/api/views/issue.py
  • apps/api/plane/tests/contract/api/test_issue_notifications.py

@wildsurfer

Copy link
Copy Markdown
Author

@sangeethailango done ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

🐛 Bug: Issues created or updated via REST API send no notifications or emails

3 participants