Digital Lock On

Appearance

Managing Worksites ​

Overview ​

This requirement covers the creation and management of worksites within projects. Worksites are specific locations where work activities occur and where Site Protectors establish protection for worker access.

User Story ​

As an administrator, I want to create and manage worksites within projects so that Site Protectors can establish protection at specific work locations and manage worker access effectively.

Business Rules ​

  • Worksites must be associated with an existing project
  • Worksites can be created and updated in the admin system
  • Multiple worksites can exist within a single project
  • Worksite names must be unique within their parent project
  • Site limits must be clearly defined for each worksite
  • Changes to worksite details do not affect existing users
  • Worksites inherit project context and timeline

Acceptance Criteria ​

Successful Worksite Creation ​

  • [ ] Admin can create a new worksite within an existing project
  • [ ] Worksite record is created in the admin system
  • [ ] Worksite information is synchronised to the Digital Lock On platform
  • [ ] Worksite appears in worksite listings within the admin system
  • [ ] Worksite is available for Site Protector assignment
  • [ ] Worksite can be activated by RPOs for multi-worksite PWAs

Required Worksite Data ​

  • [ ] Worksite name (required) - unique identifier within the project
  • [ ] Project association (required) - parent project reference
  • [ ] Site limits (required) - physical boundaries of the worksite
  • [ ] Work type (required) - type of work activities planned
  • [ ] Worksite status (required) - current status of the worksite
  • [ ] Expected start date (required) - planned worksite activation date
  • [ ] Expected end date (required) - planned worksite completion date

Site Limits Definition ​

  • [ ] Kilometer markers (e.g., "45.2km to 47.8km")
  • [ ] Platform references (e.g., "Platform 1 to Platform 3")
  • [ ] Signal references (e.g., "Signal A to Signal D")
  • [ ] GPS coordinates (optional) - precise location coordinates
  • [ ] Track references (optional) - specific track identifiers

Optional Worksite Data ​

  • [ ] Safety requirements (optional) - specific safety considerations
  • [ ] Equipment requirements (optional) - required equipment for work
  • [ ] Access requirements (optional) - special access considerations
  • [ ] Environmental conditions (optional) - weather or environmental factors
  • [ ] Emergency contacts (optional) - site-specific emergency information

Worksite Management Operations ​

  • [ ] Admin can update worksite details
  • [ ] Admin can modify site limits
  • [ ] Admin can change worksite status
  • [ ] Admin can reassign worksite to different project
  • [ ] Admin can extend or modify worksite timeline
  • [ ] Admin can add or remove safety requirements

Validation Requirements ​

  • [ ] Worksite name uniqueness within project is enforced
  • [ ] Parent project exists and is valid
  • [ ] Site limits are properly formatted and complete
  • [ ] Work type is from predefined work type list
  • [ ] Worksite status is from predefined status list
  • [ ] Date ranges are valid and within project timeline
  • [ ] Required fields are provided before creation

Error Handling ​

  • [ ] Clear error message when worksite name already exists in project
  • [ ] Clear error message for invalid project reference
  • [ ] Clear error message for invalid site limits format
  • [ ] Clear error message for invalid work type
  • [ ] Clear error message for invalid worksite status
  • [ ] Clear error message for date ranges outside project timeline
  • [ ] Clear error message if synchronisation to Digital Lock On platform fails

Dependencies ​

  • Projects must exist before worksites can be created
  • Digital Lock On platform worksite management API must be available
  • Work type and status definitions must be consistent between systems
  • Site limit formatting standards must be established

Implementation Notes ​

  • Worksite IDs should be automatically generated (UUID or similar)
  • Consider using worksite codes that reference parent project (e.g., "PROJ-2024-001-WS-A")
  • Worksite synchronisation should be near real-time to ensure availability
  • Site limits should support multiple format types for flexibility
  • Consider worksite templates for common work types
  • Implement validation to ensure site limits don't overlap inappropriately

Notes ​

  • Worksites are where actual work activities and lock-on processes occur
  • Site Protectors will be assigned to worksites to establish protection
  • Worksite deletion should be handled carefully if work has already occurred
  • Audit trail for worksite creation and updates will be addressed in a future decision
  • Integration with mapping systems may be considered for future enhancements

Internal use only