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