mirror of
https://github.com/zulip/zulip.git
synced 2025-11-04 05:53:43 +00:00
dcbb2a78ca
JsonableError has two major benefits over json_error: * It can be raised from anywhere in the codebase, rather than being a return value, which is much more convenient for refactoring, as one doesn't potentially need to change error handling style when extracting a bit of view code to a function. * It is guaranteed to contain the `code` property, which is helpful for API consistency. Various stragglers are not updated because JsonableError requires subclassing in order to specify custom data or HTTP status codes.
22 lines
765 B
Python
22 lines
765 B
Python
from django.http import HttpRequest, HttpResponse
|
|
from django.utils.translation import gettext as _
|
|
|
|
from zerver.decorator import human_users_only
|
|
from zerver.lib.actions import do_mark_hotspot_as_read
|
|
from zerver.lib.exceptions import JsonableError
|
|
from zerver.lib.hotspots import ALL_HOTSPOTS
|
|
from zerver.lib.request import REQ, has_request_variables
|
|
from zerver.lib.response import json_success
|
|
from zerver.models import UserProfile
|
|
|
|
|
|
@human_users_only
|
|
@has_request_variables
|
|
def mark_hotspot_as_read(
|
|
request: HttpRequest, user: UserProfile, hotspot: str = REQ()
|
|
) -> HttpResponse:
|
|
if hotspot not in ALL_HOTSPOTS:
|
|
raise JsonableError(_("Unknown hotspot: {}").format(hotspot))
|
|
do_mark_hotspot_as_read(user, hotspot)
|
|
return json_success()
|