the system remains primarily DEVICE based
at set points (maybe every point / maybe everyjob) the DEVICE will be tied to a CURRENT USER
Map display will display a query on the DEVICEs table (even though current device username is displayed)
All tracking/event data should be tagged with the 'User DatabaseID' and the 'Device DatabaseID' - to enable flexibility in future querys
Messages are sent to a Device (even though the recipient may be selected from a current username list)
Dashboard can remain device driven until change is requested
Query & Download should be username driven - it would be embarassing to have this displayed incorrectly
In order to aid this process we should implement sending the REAL DEVICE ID (just the 8 chars that DONT change) with every message.
Our DeviceID, should be refered to as the DeviceName in future to clarify discussions amongst ourselves
We agreed that TCC could be used as a user validation mechanism, and that having REAL DEVICE ID's would help this,
but that we wouldnt implement this until necessary - Wyn should investigate with Derrick if their is a 'bulk user account' upload option
We agreed that device COMPANY's relate directly to 'TCC Organisations'
Each COMPANY would have their own PSGPAGES Domain
Each COMPANY would have their own poster.php within that domain
Each COMPANY would have their own Database assisgned on PSGPAGES.COM
Each COMPANY must have a 'icapture' FileStore within TCC that can be used for sending&recieving JOBS/ATPs/MEDIA
Changes that can be done straight away without affecting system operation
Send the REALDEVICEID as the DEVICEID field - as well as DEVICENAME on all messages -
ASAP Option to 'Request Latest Feature Class Defintions' which will download from the 'TCC\<company>\icapture\atps' folder
Option to 'Update Server Feature Class Defintions' which will UPLOAD to the 'TCC\<company>\icapture\atps' folder (limited to users with ADMIN in their PASSWORD)
Option within the DataView to 'Navigate To Job' (navigates to first point within the Job) - i know this feels like it should be in JobManager - but will fit in with our future workflow if this can be initiated without going back to the JabManager - and it means they need to be in a specific job in order to navigate to it - useful for time keeping)
Changes that need to happen soon - but may affect current users
When Accepting a Job the 'newjob' data needs to be written out as a 'newjob' feature in the JOB file rather than just comments
Option within the JobManager to 'Edit JobCard' - this effectivly will 'Accept the current highlighted JOB/close the jobmanager/and fire the ATPeditor to edit the first point in the file' (may become default 'Accept' behaviour)
Photo should be send to the TCC\<company>\icapture\atps folder rather than psgpages (this should just be a config change in iCapture - but needs reflecting on fmLive)
THE ABOVE CHANGES SHOULD BE DONE NOW - BEFORE A ROME RELEASE
THE CHANGES BELOW SHOULD BE DEFERED FROM 'GOING LIVE' UNTIL ROME IS SIGNED OFF
03:58,{MSG}{FOID:1266321478}{GOTO:53.0678845078892,-2.5275421142578125}{ADDRESS:1 Red Lion Ln, Nantwich, Cheshire CW5 5, UK}{TYPE:message}{CLASS:task}{STATUS:open}{JOB:http://myconnectedsite.com/<company>/icapture/jobs/1234.JOB}go to the indian{ENDMSG}
To be implemented only when we have a confirmed order, or weve run out of things to do.
Multiple Job Types - the server can assign DIFFERENT job types
Assign a Single Incident as a Job → same procedure as assigning a task except the job will have a two records - a JOBCARD and a incident specific atp.
Assign a uploaded SHP file as an Job → same procedure, but SHP file will have to go via PP-server inorder to be converted into a JOB
