Function got_ya_id::apps::ids::views::lose_idt [−][src]
pub async fn lose_idt(pk: Path<i32>) -> Result<HttpResponse, Error>
Marks an Identifications is_found
status as
False.
INFO
This request was initially meant to be made by the owner of the Idt. However, it’s not reasonable, as just changing the found status does tell the owner where to find a re-lost Identification.
The alternative assumption was that posting a new
identification should allow the user to search for
closely matching fields on existing found
Idts.
In case this happens to be a relost Idt, an update
(to (maybe) its new location, and is_found
status)
would simply be done, instead of creating a new Idt
item all together.
This all seems an unnecessay fetch though. Reason? Seems like a fancy way to complicate the work of a user posting a found Idt.
An Identification whose is_found
is marked True
will be considered as good as deleted then, and should
in no direct way happen to be visible to the user
Url
/ids/lose/{key}
METHOD
POST