Reorg some procedures.

documents/plant/Reactor/I&C Systems/Plant Control System/index.yaml

@@ -1,4 +1,4 @@
-- name: Reactor plant control system
+name: Reactor plant control system
 params:
   - name: Quantity
     val: 1

documents/procedures/administration/document_management.rst

@@ -1,101 +0,0 @@
-Records and Document Management Procedure
------------------------------------------
-
-This procedure governs the creation, maintenance, and retention of
-:term:`Records <Record>` and :term:`Documents <Document>`. 
-
-.. impl:: Define processes for lifetime records
-    :links: R_GDC_01_04
-
-.. impl:: Define processes for Document Control
-    :links: R_APPB_45
-
-.. impl:: Define processes for Quality Records
-    :links: R_APPB_79
-
-
-.. _rmdc-systems:
-
-Systems
-^^^^^^^
-
-Documents and records are managed in the following systems.
-
-.. datatemplate:yaml:: 
-    :source: /_data/it-systems.yaml
-
-    {{ make_list_table_from_mappings(
-        [('Name', 'name'), ('Use case(s)', 'use-cases'), ('Location', 'location')],
-        data['rmdc-systems'],
-        title='RMDC Systems',
-        ) }}
-
-.. _rmdc-origination: 
-
-Origination
-^^^^^^^^^^^
-New records and new or revised documents are originated as invoked by other procedures
-and processes. The following steps shall be taken at such times:
-
-* **Originator** shall specify key data defining the new record/document, including:
-    * Required:
-        * Title --- a single-line description of what the record/document is
-        * Record/document type --- This determines template, review, and
-          retention rules. Should be from :ref:`rmdc-doctypes`
-        * Originating organization --- the organization or group assigned primary authorship. 
-          Internally-generated records/documents shall be contained on the :ref:`org-chart`, while
-          others should be the name and department of external entities.
-    * Optional
-        * Keywords --- words or phrases to assist in future searches/lookups
-
-
-.. impl:: Require document index to be updated upon origination
-    of any new document or record
-    :links: R_APPB_83
-
-    Updating the index at the point of creation is a robust
-    way to ensure compliance that each document/record will always
-    be discoverable and retrievable.
-
-.. _rmdc-doctypes: 
-
-Record/Document Types
-^^^^^^^^^^^^^^^^^^^^^
-One of the following record/document types should be assigned to each
-record/document.  The types are generally associated with specific forms or
-templates that include the expected content/sections, and are often created to
-satisfy the needs of a lower-level procedure.
-
-.. impl:: Define numerous Record/Document types
-
-    There is a timeless debate about having too many vs. too few doc types.
-    Additional types are added to support more mature procedure sets, but then
-    people start to struggle to know what type they should use, leading to
-    cleanup efforts, followed by management declarations to reduce the number of
-    types.
-
-    A good solution to this problem is to be very explicit in your procedural 
-    culture. Ensure that whenever a record or document is being originated, that
-    each staff member has the relevant procedure open and is following it
-    precisely.  Ensure that the procedures are rigorous and precise about which
-    record/document types should be generated in each scenario. When a procedure
-    is written, ensure that any new record/document types are added to the list
-    of known types.
-
-    .. warning:: Don't make one rec/doc type for each individual checklist or form
-        in each procedure though. Those can all be forms. Or maybe do make them 
-        all form subtypes? Could be nice to really have specific evidence.
-        Need easy way to make auto-generated forms per procedure then.
-
-.. datatemplate:yaml:: 
-    :source: doc-types.yaml
-
-    {{ make_list_table_from_mappings(
-        [('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use-cases'), 
-        ('Record', 'record'), ('Retention', 'retention')],
-        data,
-        title='Record/Document types',
-        ) }}
-
-See Also
-^^^^^^^^

documents/procedures/administration/index.rst

@@ -7,4 +7,5 @@ and the management of procedures themselves.
 .. toctree::
     :glob:
 
+    information_management/index
     * 

documents/procedures/administration/information_management/document_management.rst

@@ -0,0 +1,296 @@
+.. _rmdc-proc: 
+
+Records and Document Management Procedure
+=========================================
+This procedure governs the creation, intake, maintenance, authorization,
+distribution, and retention of :term:`Records <Record>` and :term:`Documents
+<Document>`.
+
+Purpose
+-------
+Systematic management of Records and Documents helps teams execute
+large, long-term, and complex projects in a coordinated fashion. 
+Furthermore, management of quality-related documents is required by
+regulations. This procedure implements the following requirements:
+
+.. impl:: Define processes for lifetime records
+    :links: R_GDC_01_04
+
+.. impl:: Define processes for Document Control
+    :links: R_APPB_45
+
+.. impl:: Define processes for Quality Records
+    :links: R_APPB_79
+
+Roles
+-----
+Roles involved in this procedure include:
+
+Originator
+  Person who authors a new or revised document
+
+Reviewer
+  Person who is assigned to review a submitted document, checking for quality
+  and content
+
+Approver
+  Person in the releasing organization who is authorized to mark a document as
+  Approved, thereby enabling its use across the project.
+
+Manager 
+  Person in any organization who is authorized to request document reservations
+
+RMDC Staff
+  Person responsible for receiving documents and administering :term:`RMDC` IT
+  systems such as the :term:`EDMS`
+
+Staff
+  Person in any organization who is authorized to access or submit project
+  documents/records
+
+Procedure
+---------
+
+.. _rmdc-access:
+
+Accessing a document/record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Internal project staff shall follow these steps when seeking documents or records
+to perform project work.
+
+* **Staff** navigates to the project :term:`EDMS` as defined in :ref:`rmdc-systems`
+* **Staff** searches EDMS for desired document/record by number, title, and/or other fields
+* **Staff** checks ``status`` field and ensures they choose a revision that is
+  approved for their current work task (generally this requires an APPROVED status).
+* **Staff** checks the ``usage`` field and ensures to choose a revision with a
+  usage marking that is appropriate for their current work task.
+* **Staff** accesses the file(s) via the EDMS download or access feature
+* If an expected Document/Record cannot be found, appears to have erroneous data, or
+  is not accessible, **Staff** contacts **RMDC Staff** for assistance
+
+
+.. _rmdc-origination: 
+
+Originating a new document/record
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+New records and new or revised documents are originated as invoked by other procedures
+and processes, or by third parties. The following steps shall be taken whenever a new
+document or record or document reservation is requested, created, or received:
+
+* **Staff** shall specify document data defining the new record/document in
+  accordance with the content rules listed in :py:class:`nrsk.models.Document`
+
+  * Required:
+    
+    * Title --- a single-line description of what the record/document is
+    * Record/document type --- This determines template, review, and
+      retention rules. Should be from :ref:`rmdc-doctypes`
+    * Originating organization --- the organization or group assigned primary authorship. 
+      Internally-generated records/documents shall be contained on the :ref:`org-chart`, while
+      others should be the name and department of external entities.
+
+  * Optional
+  
+    * Keywords --- words or phrases to assist in future searches/lookups
+
+
+.. impl:: Require document index to be updated upon origination
+    of any new document or record
+    :links: R_APPB_83
+
+    Updating the index at the point of creation is a robust
+    way to ensure compliance that each document/record will always
+    be discoverable and retrievable.
+
+
+Intake
+^^^^^^
+Upon receipt of Document/Records from an external party, the following process shall occur:
+
+* **Receiver** determines whether the Document/Record is eligible for 
+  entry into the Document Index.
+* **Receiver** inspects Document Index to ensure consistency with the Index and the 
+  received Document
+
+  * If the received document/record is not already listed in the Document Index, then
+    **Receiver** takes on the role of **Originator** and follows the process in 
+    :ref:`rmdc-origination`.
+  * If the data is incorrect or outdated, **Receiver** updates the data 
+  
+* **Receiver** uploads the received file(s) to the EDMS.
+* **Receiver** updates metadata in the Document Index, including the latest 
+  revision number, authors, received date, and location/URL in the EDMS
+* **Receiver** assigns acceptance review task to appropriate person based on 
+  the work breakdown structure that the document was produced under.
+* **Reviewer** views Document Index and downloads file(s) as listed
+* **Reviewer** inspects files and performs acceptance review as appropriate, potentially
+  generating a Review Record
+* **Reviewer** updates Document Index acceptance metadata field according to review
+* If the document/records are not accepted, **Reviewer** informs originating 
+  institution of deficiencies and requests update
+
+Document/Record data management
+-------------------------------
+
+.. _rmdc-doctypes: 
+
+Record/Document Types
+^^^^^^^^^^^^^^^^^^^^^
+One of the following record/document types should be assigned to each
+record/document.  The types are generally associated with specific forms or
+templates that include the expected content/sections, and are often created to
+satisfy the needs of a lower-level procedure.
+
+.. impl:: Define numerous Record/Document types
+
+    There is a timeless debate about having too many vs. too few doc types.
+    Additional types are added to support more mature procedure sets, but then
+    people start to struggle to know what type they should use, leading to
+    cleanup efforts, followed by management declarations to reduce the number of
+    types.
+
+    A good solution to this problem is to be very explicit in your procedural 
+    culture. Ensure that whenever a record or document is being originated, that
+    each staff member has the relevant procedure open and is following it
+    precisely.  Ensure that the procedures are rigorous and precise about which
+    record/document types should be generated in each scenario. When a procedure
+    is written, ensure that any new record/document types are added to the list
+    of known types.
+
+    .. warning:: Don't make one rec/doc type for each individual checklist or form
+        in each procedure though. Those can all be forms. Or maybe do make them 
+        all form subtypes? Could be nice to really have specific evidence.
+        Need easy way to make auto-generated forms per procedure then.
+
+.. datatemplate:yaml:: 
+    :source: /_data/doc-types.yaml
+
+    {{ make_list_table_from_mappings(
+        [('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use_cases'), 
+        ('Record', 'record'), ('Retention', 'retention')],
+        data,
+        title='Record/Document types',
+        ) }}
+
+
+Document Numbering
+^^^^^^^^^^^^^^^^^^
+
+Document numbers (or IDs) are human-usable codes that uniquely identify
+the document/record for purposes of cross-referencing and discussion.
+
+All projects may use |inst| corporate-level document numbering as appropriate
+in addition to the project-specific policies. Corporate number shall
+
+For corporate-level documents/records not associated with any specific project
+or system, the document numbers shall be of the form: ``AMS-{type}-00000``,
+where {type} is the document type abbreviation in all CAPS, and the number
+starts at 00001 and increments from there. When 100,000 or more numbers are
+needed, the number continues increasing.
+
+For project-level documents/records not associated with any specific system,
+numbers shall be of the same form, but with ``{AMS}}`` replaced with the 
+project abbreviation, e.g. ``TTP``. 
+
+Documents/records associated with a specific project and system shall have document
+numbers of the form: 
+
+``{proj}-{sys}-{type}-00000``
+
+where `{sys}` is the system abbreviation in all CAPS.
+
+Active projects and their abbreviations may be found in :ref:`projects`.
+
+
+.. _rmdc-doc-status:
+
+Document Statuses
+^^^^^^^^^^^^^^^^^
+Document Status indicates where a document or record is in its lifecycle, and
+determines if and how it may be used in design or operation.  Statuses fall into
+three top-level categories. These statuses are derived from
+:cite:p:`cloverDocumentControlRecords2010`.
+
+.. autoclass:: nrsk.models.Document.STATUS
+  :no-index:
+  :no-members:
+
+  * **Not Yet Approved** --- The following statuses apply to Documents that
+    generally shall not be used to support plant design or operations:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.RESERVED
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.IN_PROGRESS
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.IN_REVIEW
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.REJECTED
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.REFERENCE
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.NATIVE
+      :no-index:
+      :no-value:
+
+  * **Approved** --- The following statuses apply to active documents that allow
+    plant design or operations:
+  
+    .. autoattribute:: nrsk.models.Document.STATUS.APPROVED
+      :no-index:
+      :no-value:
+
+  * **No Longer Approved** --- The following statuses apply to documents
+    that are no longer approved for use other than reference:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.QUARANTINED
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.SUPERSEDED
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.REVISED
+      :no-index:
+      :no-value:
+   
+    .. autoattribute:: nrsk.models.Document.STATUS.VOIDED
+      :no-index:
+      :no-value:
+
+    .. autoattribute:: nrsk.models.Document.STATUS.CLOSED
+      :no-index:
+      :no-value:
+
+.. note:: These statuses are validated in the data dictionary
+  in :py:class:`~nrsk.models.Document`
+
+.. _rmdc-systems:
+
+Document/Record Management Systems
+----------------------------------
+
+Documents and records are managed in the following systems.
+
+.. datatemplate:yaml:: 
+    :source: /_data/it-systems.yaml
+
+    {{ make_list_table_from_mappings(
+        [('Name', 'name'), ('Use case(s)', 'use_cases'), ('Location', 'location')],
+        data['RMDC'],
+        title='RMDC Systems',
+        ) }}
+
+
+See Also
+--------

documents/procedures/administration/information_management/index.rst

@@ -0,0 +1,9 @@
+*********************************
+Information Management Procedures
+*********************************
+
+.. toctree::
+
+    information_management_plan
+    document_management
+    

documents/procedures/administration/information_management/information_management_plan.rst

@@ -1,4 +1,3 @@
-
 Information Management Plan
 ===========================
 

src/nrsk/schedule/load_schedule.py

@@ -59,6 +59,14 @@ def create_task(parent, name, duration):
     """Make a planned task."""
     task = parent.addTask()
     task.setName(name)
+    if duration:
+        # apply duration in way that makes schedule solver solve for it
+
+        # Some tasks may not have durations but then will require appropriate
+        # predecessor links to become scheduled
+        # but then they'll need a work resource or else you'll get error:
+        # >>> Task has no duration value and no resource assignments with a work
+        #     value: [Task id=35 uniqueID=35 name=Pre-licensing activities]
         task.setDuration(duration)
         task.setActualDuration(Duration.getInstance(0, duration.getUnits()))
         task.setRemainingDuration(duration)
@@ -90,11 +98,12 @@ def load_from_yaml(fname: str = "schedule.yaml") -> ProjectFile:
                     summary, task_d.name, Duration.getInstance(0, TimeUnit.DAYS)
                 )
             else:
-                task = create_task(
+                duration = (
-                    summary,
+                    Duration.getInstance(task_d.duration.days, TimeUnit.DAYS)
-                    task_d.name,
+                    if task_d.duration
-                    Duration.getInstance(task_d.duration.days, TimeUnit.DAYS),
+                    else None
                 )
+                task = create_task(summary, task_d.name, duration)
             # track predecessors to build after all tasks exist
             if tid := task_d.id:
                 tasks_by_id[tid] = task