Merge lp:~james-w/python-oops/record-published-explicitly into lp:python-oops
Status: | Rejected |
---|---|
Rejected by: | James Westby |
Proposed branch: | lp:~james-w/python-oops/record-published-explicitly |
Merge into: | lp:python-oops |
Diff against target: |
125 lines (+39/-11) 4 files modified
oops/config.py (+4/-3) oops/publishers.py (+1/-1) oops/tests/test_config.py (+25/-3) oops/tests/test_publishers.py (+9/-4) |
To merge this branch: | bzr merge lp:~james-w/python-oops/record-published-explicitly |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Collins (community) | Needs Fixing | ||
j.c.sackett (community) | Approve | ||
Review via email: mp+109239@code.launchpad.net |
Commit message
Change to explicitly track published state.
If the state is tracked by the presence of the id then a report can't come
with a pre-generated id.
This prevents applications that know an oops will be generated, but don't
have access to the generation, from reporting the oops id to anyone.
Description of the change
Hi,
In discussions around the fact that Django can't easily tell anyone
what the id is for the oops they just encountered Rob said that the
best way to handle it was probably to have django allocate the oops id.
That works great, and the publishers will just use it. The only drawback
is that it means that publish_only_new will never trigger its publisher
any more, because of the double meaning of the id in the report.
Applications that do this could avoid publish_only_new, at the cost of
duplicating all oopses and then de-duplicating them later.
Instead I propose to track the published state more explicitly in the
oops, which this branch does.
Thanks,
James
Unmerged revisions
- 30. By James Westby
-
Check for the published key in publish_new_only.
- 29. By James Westby
-
Set a published key in the report to indicate when it has been published.
Looks good.
Thanks, James.