Handling next steps following QField project creation

[ramyaragupathy]

Now that we have the QField project creation working via Field TM, adding the user acceptance criteria for basic project setup workflow.

After Project Creation:

• Don’t redirect to QField Cloud.
• Stay inside Field TM. Show project detail page (like ODK/WebForms).

Within the project page:

• Add Open in QField Cloud button somewhere - could work on the left panel

Explore projects page:

• Add project mapping type badges on cards (top-right)
• Tooltip to show created for ODK usage
• Include a category filter: Mapping app (All / QField / ODK / WebForms

Why do we do this?

Keeps users oriented inside Field TM, provides clear next steps to open/manage projects in respective apps, and improve visual clarity on Explore across all project mapping app types.

[linear]

TECH-816

[ramyaragupathy]

cc @manjitapandey @NSUWAL123

[spwoodcock]

The reason for the redirect is because the project details page will be broken / probably not show geoms.

FieldTM is not a QField project viewer, but simply a creator. Projects should be managed entirely in QFieldCloud and not shown on the FieldTM projects page at all (we should probably filter them out on the /projects endpoint that is rendered on the home page)

[ramyaragupathy]

Thanks, Sam.

From a user workflow perspective, I think completely filtering these projects out of the FieldTM experience causes more confusion:

Why FieldTM should still show QField projects (at a minimum):

• Users just created the project in Field TM, they expect to see it in the same place as their other projects.
• Removing it from Explore makes it feel like setup is incomplete or something has failed.
• We are pushing for Field TM to be the entry point for QField project creation. Discoverability should remain within the tool that created it.
• We may later attach Field TM specific artifacts, even if mapping lives in QField Cloud.
• Explore proejcts page should ideally show everything the user is working on, regardless of mapping backend.

So instead of hiding QField projects entirely, my suggestion is to:

• Show QField projects in FieldTM
• Make them clearly labeled & read-only
• Provide one-click “Open/Manage in QField Cloud”
• Provide graceful fallback handling while geoms are provisioning
• Later, enrich with metadata and project-level context as needed

[spwoodcock]

Agree that's the ideal workflow - it's a lot of work - we need to redesign the project creation workflow to have specific flows for that: QField, ODK, FieldTM, etc.

The user should be presented with different options for each flow.

Then the final projects created will be different. We also need to redesign the project details page to display differently, depending on the mapping app chosen.

In order for this to all work nicely within a single FieldTM system, we need a big refactor of both the backend and frontend.

[ramyaragupathy]

Ok, I understand the long-term vision will require more changes.

In the meantime, the minimum expectation is that:

• the project remains visible in Field TM after creation,
• with a clear way to open it in QField Cloud.

We can evolve the rest incrementally as we refine the overall workflow.

[ramyaragupathy]

Also for clarity, could please outline what is that we offer currently via the Field TM setup for QField project?
Summarising my understanding, please correct

Project creation via Field TM:

• Upload XLSForm + basic metadata
• Fetch OSM data and create task grids
• Provision project in QField Cloud
• Imagery layer support? (unclear if MBTiles upload is fully handled yet)

Project management:

• Task/layer modifications → done directly via QField Cloud or QField Sync, not supported through Field TM
• Field TM admin roles still apply, but mapping-side assignments handled in QField Cloud

Data + submissions:

• Data captured and stored in QField Cloud
• Field TM submissions dashboard not yet integrated for QField workflows (right?)

[spwoodcock]

Project creation via Field TM:

• Upload XLSForm + basic metadata ✅
• Fetch OSM data and create task grids ✅
• Provision project in QField Cloud ✅
• Imagery layer support? (unclear if MBTiles upload is fully handled yet) ❌ nothing there yet, but I would recommend just opening QGIS and generating the base imagery, then adding to the project and syncing

Project management:

• Task/layer modifications → done directly via QField Cloud or QField Sync, not supported through Field TM ❌ Not there yet. Plan to do this by configuring the task layers with an attribute and adding a small UI element to lock / unlock tasks
• Field TM admin roles still apply, but mapping-side assignments handled in QField Cloud ❌ (QFieldCloud has roles. We could try to manage this from FieldTM, but I think a better option is to do this in QFieldCloud).

Data + submissions:

• Data captured and stored in QField Cloud ❌ (no link to FieldTM yet)
• Field TM submissions dashboard not yet integrated for QField workflows (right?) ❌ (I don't think we should do this)

---

That's the state of what is implemented currently.

As for what we should implement going forward, that's a different story, and I think we should discuss.

[spwoodcock]

Key next steps for QField IMO:

• Continue where I left off configuring styles and symbology for QField:

  field-tm/qfield/project_gen_svc.py

  Line 402 in f49de06

  def configure_task_layer_style(task_layer: "qgis.core.QgsLayer", log: logging.Logger) -> None:

• Working with the QField team to handle user login better. We have discussed a QRCode based sharing approach, that generates a user automatically for the person who scans, then opens the project.
• Creating a QField plugin to manage the task layer statuses - task locking,unlocking,completion.
  • QField plugins are simple by design, although the syntax is weird being QML + JavaScript. Example: https://github.com/hotosm/drone-tm/tree/dev/src/qfield-plugin
• Improvements to the data collection flow in QField, including Back/Next buttons in the attribute collection pane.
• Loading QField project with a layer already selected for editing (underway by QField team I think).
• Documenting how to setup / configure projects:
  • Generating baselayers via built in QGIS utils
  • Configuring the font size in QField app settings (manual, one time) - useful for filling out attributes

[NSUWAL123]

I think a good middle ground would be to display all projects on the Explore Projects page regardless of the field_mapping_app selected. Then, when a user selects a project, they could be redirected to the appropriate platform based on its field mapping app:
QField → QField Cloud
ODK → ODK Central
FieldTM → Project Details Page
This approach ensures that all projects remain discoverable in one place while maintaining the correct redirection flow depending on the field mapping app configuration, and I guess it would be technically feasible as well since we could have a redirect URL field on the DB.

However, having a Project Details Page for tools other than FieldTM doesn’t seem feasible. This is because there are API calls like /statuses (specific to ODK) and /entities (which returns entities stored in our own database). Implementing a details page for these tools would either require duplicating data within the FieldTM database, leading to redundancy, or building tool-specific frontend and backend implementations, which would complicate maintainability and scalability as we integrate more tools in the future.

[ramyaragupathy]

Just to clarify, Field TM already has a Project Details Page for ODK right, while ODK Central is still the source of truth for data storage and form handling.

We surface metadata, boundaries, submission status, and a link to manage data without duplicating the entire ODK experience.

My expectation for QField is a minimal approach:

• keep projects visible in Explore
• surface basic project information
• provide one clear link to manage the mapping workflow in QField Cloud
• at present do not provide links to submission dashboard, disable anything related to manage or task assignment

That keeps Field TM consistent as the discovery and entry point for field projects, regardless of the mapping backend.

[ramyaragupathy]

I would suggest starting with the listing of QField projects in the explore section with a clear option to open the project in QField cloud.