Story/000123/sprint planning (#152)

* paste story text

* paste story text

* sprint planning

* added filtering for projectId

* refactor to support bff

* more work on plan view bff code

* added points metric related fields

* invertable icon

* collapse icon in place

* added sprint backlog items resource

* UI for adding sprint backlog items

* doc updates

* architecture notes added

* fix script issue

* basic sprint backlog insert in place

* changed name of sprintbacklog

* added endpoint to move item into sprint

* fix compilation issues

* doc updates

* removed console.logs

* fixed "last sprint item move to sprint" bug

* fix add pbi issue- projectid was null

* partial implementation of sprint item delete

* implemented "move" handler

* updated action naming

* add:sprint action with data - no UI yet

* added POST sprint handler

* remove unnecessary sprint.displayindex field

* fix storybook issues

* add sprint panel (not working yet)

* fix for sprintpanel issue

* refactor to creatre sprint card

* implemented endpoint to delete sprint

* updated to @atoll/shared@0.20.0

* update package-lock

Co-authored-by: Kevin <kevinbe71@gmail.com>

.github/CONTRIBUTING.md

@@ -0,0 +1,2 @@
+Make sure that you've read README.md and CODE_STANDARDS.md before contributing new code.  These documents are living documents so
+make sure you're familiar with the most recent changes.

.storybook/preview-head.html

@@ -58,6 +58,14 @@
         height: 7.6rem;
     }
 
+    .item-menu-panel {
+        width: 7.2rem;
+    }
+
+    .item-menu-panel.caret-right-top {
+        width: 7.7rem;
+    }
+
 </style>
 <script>
     function getThemeAttribute() {
@@ -87,6 +95,8 @@
                 '--normal-divider-color': '#f4f4f4',
                 '--normal-light-border-color': '#ccc',
                 '--normal-active-page-color': '#ddd',
+                '--normal-error-pen-color': '#fff',
+                '--normal-error-page-color': '#900',
                 '--normal-form-page-color': '#d0d0d0',
                 '--normal-input-page-color': 'white',
                 '--normal-focus-page-color': '#eee',
@@ -113,6 +123,8 @@
                 '--normal-divider-color': '#0b0b0b',
                 '--normal-light-border-color': '#333',
                 '--normal-active-page-color': '#555',
+                '--normal-error-page-color': '#900',
+                '--normal-error-pen-color': '#fff',
                 '--normal-form-page-color': '#606060',
                 '--normal-input-page-color': '#222',
                 '--normal-input-page-disabled-color': '#444',

.storybook/preview-head.template.html

@@ -58,6 +58,14 @@
         height: 7.6rem;
     }
 
+    .item-menu-panel {
+        width: 7.2rem;
+    }
+
+    .item-menu-panel.caret-right-top {
+        width: 7.7rem;
+    }
+
 </style>
 <script>
     function getThemeAttribute() {

docs/ARCHITECTURE.md

@@ -1,11 +1,15 @@
-Architecture
-============
+Overview
+========
 
 This document provides high level guidance on the application's architecture.
 
 Restful API
 ===========
 
+NOTE: If you're looking for information about using the API "framework"
+  (i.e. code level details) then take a look at the
+  [ARCHITECTURE_API.md](ARCHITECTURE_API.md) document.
+
 Atoll's API should follow a true RESTful API pattern, including the use of HATEOAS.
 
 Use of HATEOAS
@@ -37,4 +41,42 @@ Note: "self" should not be used when the current request URI to return this item
   returned by navigating using that link.  It is useful because an "OPTIONS" call
   to that URI may return other HTTP verbs that can be used on that resource,
   for example, "PUT", "DELETE" or "PATCH".
-
+
+CSS
+===
+
+After testing a number of different CSS approaches, "CSS Modules" was chosen for
+the following reasons:
+1. It worked well with the various tooling (TSDX, Webpack, Typescript, etc.)
+2. It kept styling localized with the components (important for bundling and
+   performance loading the app as it grows).
+3. SSR support worked correctly (in particular "Styled Components" didn't work
+   well when NextJS was used- the Atoll project started off by using NextJS but
+   ran into other problems with it).
+
+Potential Candidates
+--------------------
+
+The CSS styling framework/tooling candidates that were researched included:
+1. Separate SASS files.
+2. Styled Components.
+3. CSS Modules.
+
+Theming
+=======
+
+To support theming it was decided that a "home grown" solution would work
+best.
+
+1. The "home grown" approach worked reliably with the "atoll-shared" module
+   approach.
+2. It also worked well with CSS Modules.
+
+Responsive Design
+=================
+
+To allow the app to be used on various devices the Atoll project leverages
+global CSS classes that include:
+1. "mobile" when a phone is detected.
+2. "os-*" classes are used to customize the UI for the Electron desktop
+   cient app.

docs/ARCHITECTURE_API.md

@@ -0,0 +1,39 @@
+Overview
+========
+
+This document explains the API framework that's implemented in Atoll.
+
+Files
+-----
+
+There are a few important files that encompass the API "framework":
+1. `apiMiddleware.ts`
+2. `apiOrchestrationMiddleware.ts`
+3. `apiBatchMiddleware.ts`
+
+Capabilities
+------------
+
+1. Support for stages of the API calling lifecycle:
+  - `request`
+  - `success`
+  - `failure`
+2. Queuing a batch of API calls that need to execute in sequence
+3. "Passthrough" functionality to ensure that meta information
+   is passed on from one action to another.
+
+Stages
+======
+
+(todo)
+
+Batch
+=====
+
+(todo)
+
+Passthrough
+===========
+
+(todo)
+

docs/CODE_STANDARDS.md

@@ -1,62 +1,43 @@
-Code Standards
-==============
-
-Modified Case Naming
---------------------
-
-Typically a combination of Pascal Case and Camel Case is used in
-TypeScript projects.  Atoll uses modified versions of both.  In
-the case where Pascal Case is normally used (for example, classes
-and interface names) we allow successive capitalized letters, for
-example, "HTML" instead of "Html".  An example of this is:
-`HTMLInputElement` (from the browser "Web API").
-
-Folder Naming
--------------
-
-**General**  
-
-1. Folder names should use lowercase letters.
-2. Folder names should use dashes to separate words.
-3. Folder names should not use underscores to separate words.
-
-**Component Folders**
-
-The components are organized using Atomic Design principles, so the following base folders should be used:
-- "atoms" = basic building block components
-- "molecules" = when smaller building blocks are combined they form molecules, for example, "backlog item card"
-- "organisms" = defining sections of the applicaton, for example, "top menu panel", "backlog item planning panel"
-- "templates"
-- "pages"
-
-NOTE: Do not assume that components belong in a upper level folder if they contain items at a lower level.  In a similar vein,
-  do not assume something belongs at the lower level because it doesn't contain anything from that level.  Use the guidelines
-  provided by Atomic Design itself.  It is best to think of this from the UI/UX designer's point of view instead of thinking
-  technically how the components are composed.  A good example of this is used above: "backlog item card" is a "molecule" but, when
-  this was written, it didn't use any "atoms" - but from a UI/UX perspective it does appear to have many smaller building blocks
-  that could potentially be atoms.
-
-**Interface Types**
-
-1. Don't precede interface types with any prefix
-   (for example, "I" for interface or "T" for type, as used in other code standards).
-2. Use the prefix "Base" for an interface that is at the root of the type hierarchy but typically isn't used directly by objects.
-3. Use the prefix "Standard" for an interface that is a lowest common denominator for objects that will extend it. 
-4. Avoid deeply nested hierarchies and instead try to combine other interfaces
-   (for example, StandardInvertibleComponentProps)
-5. Don't use the "Standard" interfaces as replacements for component property types
-   (for example, AppIconProps is an alias for StandardInvertibleComponentProps so that AppIcon has its own props type)  
-   _NOTE: This is done so that consumers of AppIcon aren't aware of StandardInvertibleComponentProps so that they can
-     evolve separately._
-6. Preserve acronym case in interface names (to follow Web API standards, for example, HTMLInputElement).
+Overview
+========
+
+This document contains everything but naming conventions, pleas refer
+to [CODE_STANDARDS_NAMING.md](CODE_STANDARDS_NAMING.md) for these details.
+
+File Purpose Comments
+=====================
+
+Unless it is very obvious what the file's responsibility it is, this should be very clearly defined at the top using this comment block:
+
+```
+/**
+ * Purpose: {defined purpose that makes it obvious what this file's
+     singular responsibility is (think of the "S" in "SOLID"
+     principles)}
+ * Reason to change: {this should help make it clear whether the
+     Single Responsibility Principle is being followed or not}
+ */
+```
+
+For example, at the top of apiOrchestrationMiddleware.ts:
+```
+/**
+ * Purpose: To determine when to make RESTful API calls based on actions that occur.
+ * Reason to change: When new RESTful API calls are needed.
+ */
+```
 
 Reducers
---------
+========
 
 Types related to the data structure that the reducer stores in the state tree should be exported from the reducer itself.
 
 Components
-----------
+==========
+
+Prefer React.FC components over the legacy style components.  Atoll started before functional components were widely used, so there
+may still be some code that does not use FC, but don't be tempted to use these as templates for new components- rewrite using FC
+instead.
 
 Use `React.FC<ComponentNameProps>` as the default component definition where `ComponentName` will be your actual component name,
 e.g. `MyButton`.
@@ -75,7 +56,7 @@ To combine the these two interfaces use:
 
 
 Switch Statements
------------------
+=================
 
 Case statements should always be enclosed in curly braces so that block scope is applied
 and variables within these blocks are scoped to the block.  This allows a variable name to
@@ -100,8 +81,25 @@ For example:
 ```
 
 Import Statements
+=================
+
+Overview
+--------
+
+1. Imports should contain most specific import path.
+2. Import statements should be grouped per "Import Sections" (see below).
+
+Import File Paths
 -----------------
 
+VS Code may provide options such as `module ".."` and
+`module "../reducers/rootReducer"`.  In this case
+`"../reducers/rootReducer"` should be chosen because it is
+the most specific path.
+
+Import Sections
+---------------
+
 Import statments should be grouped into the following commented sections (try
 to stick to this order as well):