Feature: Job/Task Architecture

[richardklasens]

Pull Request: Task Architecture

Summary

This PR introduces a comprehensive Task-based workflow for AgOpenGPS, allowing operators to track work sessions (tasks) within fields. Tasks store coverage data separately, enabling multiple work sessions on the same field without overwriting previous data.

Key features:

• Create, resume, close, and finish tasks within fields
• Coverage data (sections, contour, recorded path) stored per task
• Backward compatibility: import legacy coverage when creating first task
• View-Only mode when no task is active (field open without writing coverage)
• Modern all-in-one UI for task and field management
• GPS fix quality indicators in status bar
• Field import from ISO-XML and KML files
• Enhanced field selection with distance and area display

---

Changes by Commit

1. 98a839aa - Add Job data model and file I/O for job-based work sessions

• Add CJob class with properties for job metadata (id, name, field, profile, work type, timestamps)
• Add JobFiles.cs with Load/Save/List operations for job directories
• Add CreateEmpty methods to ContourFiles and FlagsFiles for job initialization
• Jobs stored in Fields/{FieldName}/Jobs/{JobName}/ folders

2. 8200345b - Add CWorkType for customizable work types

• Add CWorkType class for work type definitions (id, name, icon)
• Add WorkTypes static manager with Load/Save/Add/Remove operations
• Default work types: Spraying, Seeding, Tillage, Harvest, Mowing, Fertilizing, Other
• Work types stored in WorkTypes.json in settings directory

3. c3822ced - Add job management forms

• FormStartWork: Main entry point with Resume/New/Open/Close buttons
• FormJobWizard: 3-step wizard for creating new jobs (Profile → Field → WorkType)
• FormResumeJob: List of active jobs to resume

4. bb19d3e4 - Refactor FormStartWork to all-in-one form

• Replace multi-form approach with single 1000x700 form containing switchable panels
• Main menu, Wizard Steps 1-3, Resume job list as embedded panels
• ViewMode enum for state management and panel visibility

5. 82caf59a - Remove obsolete FormJobWizard and FormResumeJob

• All functionality consolidated in FormStartWork

6. e153a6d9 - Add currentJob property to FormGPS

• Track the currently active job (work session) within a field

7. caded8ea - Add job-aware file operations

• Add GetJobDir() method to return job directory when currentJob is set
• Update file save/create operations to use job directory
• Add FileLoadJobData() to load job-specific coverage data
• Fallback to field directory when no job active (backward compatibility)

8. db22ec02 - Add HasLegacyCoverageData() for backward compatibility

• Detect legacy coverage data (Sections.txt in field root without Jobs folder)
• Enable UI to handle migration of legacy fields to job-based system

9. b87835f9 - Wire up FormStartWork to btnJobMenu_Click

• Replace FormJob with FormStartWork in job menu button handler

10. be2c9b57 - Restyle FormStartWork: borderless with modern UI

• Borderless form with colored border and draggable header
• Buttons with hover effects and subtle shadows
• Modern color scheme with styled section headers
• AgShare buttons with accent border styling

11. cf5eabff - Add Close Job and Finish Job buttons

• Close Job: saves job, clears currentJob, job stays in active list
• Finish Job: marks job as completed, won't appear in resume list
• Update button states based on currentJob
• Skip wizard steps when field already open

12. 3f32a652 - Update FormGPS resources

13. 2c6ab8f1 - Restructures field and job management UI

• Dedicated panel for opening fields (Local Storage / AgShare Cloud)
• Reorganized layout with separate tables for jobs and fields

14. ac7877ce - Add View-Only mode and job-aware coverage saving

• Coverage only saves when a job is active
• View-Only mode: field open without writing coverage
• Flags load from field level (shared across all jobs)

15. 62a6cade - Improve job management with coverage import

• CheckForExistingCoverage() detects legacy coverage in field root
• ShowImportDialog() for user choice on import
• ImportCoverageToJob() copies coverage to new job directory
• DeleteLegacyCoverage() cleans up after import
• Proper async saving with await on Close/Finish Job

16. bcf69e4f - Add GPS fix quality icons and improve UI

• GPS fix quality icons (0-4, 8) on btnGPSData
• Age display in FormGPSData
• Replace lblFix with lblJobStatus for job status display
• Profile loading in wizard Step 1

17. 2b997917 - Refactor FormStartWork UI and add JobManager class

• tableJobs (3x2): Resume Last Job, Resume Job (List), Finish Job, New Job, Close Job, Export Jobs
• tableFields (2x2): Open Field, New Field, Close Field
• Add JobManager class for job lifecycle management
• Resume Last Job directly opens last job
• Hide Field section when job is active
• Form stays open after Close/Finish actions
• "+ New Field" button in wizard Step 2
• Auto-select last opened field
• FormKeyboard support with CenterParent positioning

18. 0e7e895d - Rename Job to Task throughout codebase

• Classes: CJob → CTask, JobManager → TaskManager, JobFiles → TaskFiles
• Properties: currentJob → currentTask, jobManager → taskManager
• UI elements: All buttons and labels renamed from "Job" to "Task"
• File structure: Jobs folder → Tasks folder
• 10 files changed, 770 insertions(+), 770 deletions(-)

19. 8400b01a - Close active task during application shutdown

• Add task closing logic to ShowSavingFormAndShutdown()
• Ensures current task is properly saved when application exits
• Calls CloseCurrentTask() after field data is saved
• Updates task metadata (end time, status) before app closes

20. 72023617 - Add Field panel and enhanced field list in FormStartWork

• Add Field panel with three options:
  • Create New Field (FormFieldDir)
  • From ISO-XML (FormFieldIsoXml)
  • From KML (FormFieldKML)
• Enhanced field selection in wizard Step 2:
  • Replace ListBox with ListView showing Field Name, Distance, Area columns
  • Bold header row with column labels
  • Sort by Name, Distance, or Area via Sort button
  • Distance calculated from current GPS position
  • Area calculated from boundary using shoelace algorithm
• UI improvements: Fixed column widths (520/200/150), 20pt font, auto-select last opened field

21. c24fcd80 - Fix race condition when saving field data before switching tasks/fields

• Fix P1 race condition bug in FileSaveEverythingBeforeClosingField()
• Three methods were calling save fire-and-forget, allowing concurrent execution with operations that change currentTask/currentFieldDirectory
• Could cause coverage data to be saved to wrong folder or not saved at all
• Changed btnOpenFieldLocal_Click, btnAddFieldNew_Click, and DoResumeTask to properly await save operation

---

File Structure

Fields/
└── {FieldName}/
    ├── Field.txt
    ├── Boundary.txt
    ├── Flags.txt          (shared across tasks)
    ├── Elevation.txt
    └── Tasks/
        └── {TaskName}/
            ├── Task.txt       (task metadata)
            ├── Sections.txt   (coverage)
            ├── Contour.txt
            └── RecPath.txt

---

New Classes

Class	Purpose
CTask	Task data model with metadata
TaskFiles	Task file I/O operations
CWorkType	Work type definition
WorkTypes	Work type manager
TaskManager	Task lifecycle management

---

UI Changes

• FormStartWork: All-in-one task management form with:
  • Task management: Resume Last Task, Resume Task, New Task, Close Task, Finish Task, Export Tasks
  • Field management: Open Field, Add Field (New/ISO-XML/KML), Close Field
  • Enhanced field selection with ListView showing distance and area
  • Sort fields by Name, Distance, or Area
• GPS Fix Icons: Visual indicator of GPS quality (0-4, 8)
• Task Status Label: Shows current task in top bar
• FormKeyboard: Now opens centered on parent

---

Test Plan

Task Management

• Create new task in existing field
• Create new field + task in one flow
• Resume last task with Resume Last button
• Resume task from list with Resume Task button
• Close task (should stay in active list)
• Finish task (should not appear in resume list)
• Import legacy coverage when creating first task
• Verify coverage saves to task directory
• Verify View-Only mode (no coverage save when no task)
• Test task closes properly on application shutdown

Field Management

• Add field via "Create New Field" option
• Import field from ISO-XML file
• Import field from KML file
• Sort field list by Name, Distance, and Area
• Verify distance calculation from GPS position
• Verify area calculation from boundary polygon
• Auto-select last opened field in wizard

Bug Fixes

• Verify no race condition when switching tasks/fields (coverage saves to correct folder)
• Test save completion before opening different field
• Test save completion before resuming different task

UI

• Verify GPS fix icons display correctly (0-4, 8)
• Test FormKeyboard centering on parent
• Verify Field section hides when task is active
• Form stays open after Close/Finish actions

[richardklasens]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[gunicsba]

Did we remove intentionally the Open from ISO-XML and KML options?
If the field is read-only (i.e. we always need a Task) then I think it would be better to call it "Add Field".

Not quite sure why the Open Local field is good, maybe n case we don't have AgShare the fact that we need 2 steps to open local fields is a bit excessive but it's a good way to advertise AgShare.

Btw It would be great to be able to mass import KML files later (i.e. if we organize them inside Google Earth then we should be able to import all the fields together in a loop. I have made a couple tools for farmers to download files for boundaries.)

ISOXML already contains multiple fields / AB lines / etc we should be able to generate all the fields from that

Add Task:
Bring back the Field Size and Distance columns? (And also the Sort by toggle button)

Task page:
here we could really use the ICONs it would make the translation a breeze.

Notes:
For the Operation it would be necessary (at least for us) to add some notes. For spraying we MUST document the chemicals used. Same is true for seeding / planting. So if we could add notes that would be great. It should remember the last note we had and offer that. So it could be next-next finish.
One more thing that I've encountered is when you have over 70 fields it's hard to remember what did you seed in them. So maybe we could have some kind of notes that are managed at the main folder and could be modified from the Task field?
How do I see this in practice:
During planting we decide to go with Wheat and Barley for example. I could add a Task: Planting (seeding) + notes: Syngenta
Falado 220kg/ha
For the Field Notes of Season 2026 I could add barley

This way in AgShare too we could have a quick and easy overview of what was planted for a given season. (and also the tasks for that plant)

Grandpa Option: Just create a New Field with the date + time + profile , and automatically display the A-B line picker (in fact if we have no AB lines we should probably have that menu opened it would save us a few phone calls)

This is a much better place to choose a profile. IMHO we should offer the option to pick a profile and create a new from the Machine selection screen. (and if we do this then after that profile is created we should open the settings page with the nozzles so they can easily modify the width)

I like that we no longer have the reception bars.

[gunicsba]

Would this also bring us the possibility to have the coverage displayed from a previous task? (or a task currently managed by another tractor that would appear as a flag moving once a minute or so)

[gunicsba]

Extra feedback from a hungarian tester:
Could we somehow list all the previous tasks for a given field? Currently it's not possible to see the previous operations.

Maybe it could fit under the Work Type Selection where the previous operations could be displayed (if they exists)
Also this could likely solve the "What did I plant there?" question if we could see the last 5 operations. ordered by date descending.

[richardklasens]

Extra feedback from a hungarian tester: Could we somehow list all the previous tasks for a given field? Currently it's not possible to see the previous operations.

Maybe it could fit under the Work Type Selection where the previous operations could be displayed (if they exists) Also this could likely solve the "What did I plant there?" question if we could see the last 5 operations. ordered by date descending.

Yes that is the Export Function which is disabled because it isnt implemented yet.

[richardklasens]

Would this also bring us the possibility to have the coverage displayed from a previous task? (or a task currently managed by another tractor that would appear as a flag moving once a minute or so)

Running jobs are active.. finished jobs are finished and unable to Unfinish since they are finished. Other then that it can be possible to put it under the current Job as a layer, just for visualization.

[richardklasens]

@codex please review again

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Pat-I]

About the file structure:

I wonder if it would be better to make an elevation.txt for each task. They are still only made if the user enable the option in the profile?

If you want an elevation profile you most likely want to know from which task it comes from anyway. Not counting be bad pts it could collect from multiple pass with different vehicles.

[richardklasens]

I wonder if it would be better to make an elevation.txt for each task. They are still only made if the user enable the option in the profile?

why should a elevation file belong to a task? Its field related?

[gunicsba]

Its field related?

Yes and no. I think we should log it both places.
Reason:
Elevation log is basically the raw GPS data points (I'm not even sure if we try to do roll correction there)
so doing a tillage at 87 degrees with a 3m different VS a 92 degree planting with a 6m wide implement will give you different data. If it's not roll corrected or you have a 10cm error in your antenna height between tractors that also shows.
Ideally if you merge multiple operations you can get a decimeter precision height map and the grid would become 1x1m or less.

Do we have a use-case for this? No.
Could we have later? Maybe.
would it hurt us to have copies of elevation log? No.

Should we upload this to AgShare? I'd say No. (lets keep the storage there minimal)

[gunicsba]

Testing review of the latest published version:

Many of the Input fields don't do the keyboard popup

Go Mode does nothing currently

If we switch profiles while in sim we end up with a field open where there's no way to enable sim. So we need to exit from AgOpenGPS, start it again, enable SIM then resume task.
Or we could switch the profile, hit cancel on the form and then reopen the task creation.

I think the Notes could be part of every operation.

Maybe the crop type should be from a list?

Sprayer operation we'll likely add the 250l/ha water + list of chemicals and their dosage in a note.

Previous Operations could display the profile maybe?
Or we should add the tool name in the notes for example we have like 6 tools to do Tillage? (shallow / deep / seedbed preparation, etc)

I found a list in isobus.net that might help us too:

0 - Non-specific system
1 - Tractor
2 - Primary Soil Tillage
3 - Secondary Soil Tillage
4 - Planters /Seeders
5 - Fertilizer
6 - Sprayers
7 - Harvesters
8 - Root Harvester
9 - Forage harvester
10 - Irrigation
11 - Transport / Trailers
12 - Farmyard Work
13 - Powered Auxilary Units
14 - Special Crops
15 - Municipal Work

For me the order of these would also make sense in this order:
Most of us seed / harvest at least once a year.
But we spray multiple times, do some kind of fertilizer application and tillage more than once.

So Spraying , Fertilizer, Tillage, Mowing/Harvest, Seeding/Planting, Other

If we shoot for 6 then it could be a nice 2x3 grid.

[richardklasens]

Many of the Input fields don't do the keyboard popup

Correct, it isn’t connected yet.

Go Mode does nothing currently

correct, it’s a place holder.

If we switch profiles while in sim we end up with a field open where there's no way to enable sim. So we need to exit from AgOpenGPS, start it again, enable SIM then resume task.
Or we could switch the profile, hit cancel on the form and then reopen the task creation.

I think we need to change the SIM enable to registry instead of settings.

[Pat-I]

why should a elevation file belong to a task? Its field related?

It's related to the task (It's related to the vehicle used).

If you keep it field related It's almost guaranteed to be a mess and unusable after some numbers of tasks:
How would you manage the multiple vehicle passes?
You would have no idea which pt come from which task.
Some with maybe incorrect height values?

If you eventually need elevation for some function in AOG, I would say take this from the task you select for "visual previous task" layer.

[gunicsba]

@richardklasens from the ISOBUS/ RATE controller perspective we could easily send the actual flow (seed etc) values and those could be stored alongside the job data. (Which means our isoxml exports will likely need changes too.)

The planter monitoring data could also be stored in a map.

Is this something we could do in the future?
Nothing blocks that right?

[richardklasens]

@richardklasens from the ISOBUS/ RATE controller perspective we could easily send the actual flow (seed etc) values and those could be stored alongside the job data. (Which means our isoxml exports will likely need changes too.)

The planter monitoring data could also be stored in a map.

Is this something we could do in the future? Nothing blocks that right?

Everything is possible yes, but lets finish this addition first. GOt a lot more work to do for AgShare to get rid of your 800+ fields ;-)