Description
User story
As a user who is creating a parking report
I want to accept revealing my address by GPS on a map
So that authorities can find where the parking report is taking place
Business context
In order to submit a report with enough information for authorities to eventually take action, the localization of the user is necessary. Without this information, it would be difficult to identify where the car is parked, even with car plate information. In order to know the car location, we need to ask for their permission to use GPS.
A clear and concise description about the business context
Describe alternatives you've considered
Offering the user a field to type their address.
In scope
Show button "Permitir uso da localização".
Associate the button with the API Google Maps to show the car position.
Out of scope
Showing the address data on the screen as a map (#183).
Obtaining confirmation from the user regarding their address (#208).
Acceptance Criteria
-
1. Obtaining authorization and delegating to API Google Maps
Given the user has already selected a parking photo,
When the user clicks on "Permitir uso da localização",
Then Multei app shows the text "Obtendo localização" and the maps with location. -
2. Persist coordinates on database
Given the user has already allowed the permission,
When the user clicks on the 'Finalizar' button,
Then Multei app should update the coordinates on database using the uuid
And mark the parking report as completed (field timestamp completed_at) -
3. Handle error on complete the parking report
Given the user has already clicked on the 'Finalizar Button',
When some error happens,
Then they should find a message 'Algo não deu certo! Por favor, tente novamente.'
And they should be able to update location and click on the 'Finalizar' again
Checklist do kickoff
- A análise da história está concluída?
- QA (ou pessoa que assumiu o papel de QA) revisou a análise?
- A história está completa com todos os detalhes e as informações relevantes?
(Ex.: Contexto, Escopo, Fora de Escopo, Critérios de aceite, etc); - O valor de negócio da história está bem entendido? (se aplicável)
- Esta história não tem dependência de outras histórias futuras?
- Não existem dívidas técnicas (débitos técnicos) relacionadas a história;
- Há protótipos de telas para essa história (se aplicável)
- Há detalhes na história de mensagens de erro e outros feedbacks para o usuário (se aplicável)
- Há mensagens de ajuda ou outros textos definidos na história (se aplicável)
- A história está em um tamanho adequado
- Existe feature toggle para a feature (se aplicável)
Checklist do deskcheck
- Há testes unitários que validem a implementação? (se aplicável)
- As alterações de código passaram em todas as pipelines
- A história foi executada manualmente
- A história não trouxe regressões ou impacto negativo a outras implementações
- Todos os critérios de aceite foram cobertos
- A história não precisa de feedback ou correção
- Foi testada uma jornada completa do usuário através da história (se aplicável)