Closed Bug 1017268 Opened 10 years ago Closed 6 years ago

[User Story] With geolocation setting disabled on the device, when a user logs on to the FMD website, the user should be provided a visual indicating that the tracking functionality is disabled

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.1 --- affected

People

(Reporter: vkrishnamoorthy, Assigned: nchapman)

References

Details

(Whiteboard: [ucid:Services1, 2.0:p1, ft:services] [NPOTB])

User Story

This is a two part user story.

Precondition:
geoLocation is disabled on the device

Action:
User logs on to FMD website

User story:
Part 1 - User should be provided a visual indication that geoLocation is disabled on the device.
Part 2 - User should be provided a means to enable geoLocation on the device remotely

Attachments

(1 file)

As the geoLocation is disabled on the device, the tracking functionality will not work. When the user logs on to the FMD website, the website should provide this information to the user as well as the ability to enable geoLocation on the device remotely
Whiteboard: [ucid:Services1, 2.0:p1, ft:services]
A good starting point for this is Bryan Bell.
Assignee: nobody → bryan
Target Milestone: --- → 2.0 S3 (6june)
User Story: (updated)
Attached wires for enabling Geolocation on FMD website.
Currently, it looks like the Website is storing the last location of the device and displaying it on the map. When FMD is disabled, the gray 'pin' disappears, but the map displays the same location as when it was enabled.
feature-b2g: --- → 2.0
Summary: With geolocation setting disabled on the device, when a user logs on to the FMD website, the user should be provided a visual indicating that the tracking functionality is disabled → [User Story] With geolocation setting disabled on the device, when a user logs on to the FMD website, the user should be provided a visual indicating that the tracking functionality is disabled
Assignee: bryan → ggoncalves
Target Milestone: 2.0 S3 (6june) → 2.0 S5 (4july)
ok, ggp and I think we could use this one as the web-facing one.
Assignee: ggoncalves → bryan
Erin, looks like this won't be done during implementation phase of 2.0, in this case, we may need to remove feature-b2g:2.0 because feature-b2g:2.0 means the features we plan to land in 2.0(during implementation phase). What do you think?
Flags: needinfo?(elancaster)
Product confirmed they consider this a big vs. feature so I'll remove the flag.
feature-b2g: 2.0 → ---
Assignee: bryan → nchapman
blocking-b2g: --- → 2.0?
Flags: needinfo?(elancaster)
Target Milestone: 2.0 S5 (4july) → 2.0 S4 (20june)
Depends on: 1025193
Vishy: we discussed this in yesterday's meeting and I want to be sure it's understood that we have time for user story 1 but we just don't have time for user story 2. Need to defer #2 to 2.1.
Requesting approval to defer US 2 as seen in User Story
Flags: needinfo?(vkrishnamoorthy)
Given the risk, I agree we move this to 2.1 (Backlog as we do not have resources identified to work on FMD in 2.1).
Flags: needinfo?(vkrishnamoorthy)
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Backlog based on comment 9, feel free to put 2.1 for feature-b2g if it's targeted for that release.
blocking-b2g: 2.0? → backlog
Target Milestone: 2.0 S5 (4july) → ---
Blocks: 941258
blocking-b2g: backlog → 2.1+
feature-b2g: --- → 2.1
No longer blocks: 941258
This is a server side feature.
In that case, it sounds like perhaps bug 1053452 should be un-duped. (At least, that bug has a non-server-side component.)
See bug 1058330 for some security considerations involved in the client-side of this user story. We should work closely with the b2g folks to see if we can implement this without giving FMD the 'permissions' permission.
See Also: → 1058330
[Blocking Requested - why for this release]:
Just want to revisit to see if it's a release blocker. Erin, do you have any comments? Thank you. 

(In reply to Michael:mtreese from comment #13)
> This is a server side feature.

Thanks, Michael. 
So, it means, no codes will land to B2G, right? Just want to know if we need to mark this with feature-b2g. Thanks.
blocking-b2g: 2.1+ → 2.1?
feature-b2g: 2.1 → ---
Flags: needinfo?(elancaster)
removing for 2.1, new feature, server side fix, need to track this via github.  ni? Nick to cross post issue.
blocking-b2g: 2.1? → ---
Flags: needinfo?(nchapman)
Whiteboard: [ucid:Services1, 2.0:p1, ft:services] → [ucid:Services1, 2.0:p1, ft:services] [NPOTB]
Flags: needinfo?(elancaster)
Filed in GitHub as https://github.com/mozilla-services/FindMyDevice/issues/201
Flags: needinfo?(nchapman)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Whiteboard: [ucid:Services1, 2.0:p1, ft:services] [NPOTB] → [ucid:Services1, 2.0:p1, ft:services] [NPOTB][2.1-flame-test-run-3]
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Whiteboard: [ucid:Services1, 2.0:p1, ft:services] [NPOTB][2.1-flame-test-run-3] → [ucid:Services1, 2.0:p1, ft:services] [NPOTB]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: