Fix/staging bugs #1810
Fix/staging bugs #1810
Conversation
github-actions
bot
added
bug
| @@ -232,7 +232,7 @@ export default function Dialog({ taskId, feature }: dialogPropType) { | |||
| ); | |||
|
|
|||
| if (isMobile) { | |||
| document.location.href = `odkcollect://form/${projectInfo.xform_id}`; | |||
| document.location.href = `odkcollect://form/${projectInfo.xform_id}?task_filter=${taskId}`; | |||
There was a problem hiding this comment.
This was actually removed intentionally, as I deemed the task_filter param to be unnecessary - it confused things I think!
The custom ODK Collect should be default, then backup users can just select the geom they are standing next too quite easily with geolocation
There was a problem hiding this comment.
@manjitapandey not sure if you agree, but I think it's ok for 'Go to ODK' to just open the unfilled form
There was a problem hiding this comment.
Currently, when users access ODK at the task level, they are presented with all the project's features, which may cause confusion as they likely expect to see only the features relevant to the specific task. Skipping the task-specific question might not be a good idea in this context.
There was a problem hiding this comment.
But should we actually even have that as a flow? The main one we should target is building selection, not task id selection.
From what I have seen actual mapping in practice is that the task id selection question is a source of confusion. Perhaps we should get some feedback from recent users.
I personally don't see it as much of an issue having the buildings loaded for users in the field. I agree it's difficult to select a building on a remote computer with no geolocation, but when in the field you are geolocated to show a dot next to the building to be mapped
What type of PR is this? (check all applicable)
Related Issue
Describe this PR