USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

FLOW: Agile Planning Workflow

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

• Agile Approach
  • Projects: Admin the Projects: Add issues, etc
  • Planning Horizon: Control how far into the future, degree of certainty v uncertainty
  • Sprint Planning: Day to Plan each Sprint, prepare the project and auxillary activities for dev, build and test flow
  • Backlog Manage: Refine the Backlog: Product|Icebox -> Epic Log -> Sprint Log
  • Sprints: List the sprints
  • Labels: Define the Labels / Filters

ADR

PROJECT: Y-Statement

Approach:

PROJECT:

• Use Case: The Developer of 1
• Constraint: Team of 1
• Roles: Developer is the Project Manager, Scrum (Agile) Facilitator, and Developer
• Consequence: A slimmed/paired down agile, and scrum, methodologies to fit the `developer of 1' use case/constraint for agile process.
• Trade off: compromised and not full methods applied.

Planning Horizon

• Limit: Maximum of 3 weeks.
• Plan: New horizon each Monday
  • 1st Week: Greatest Detail | Most Certainty
  • 2nd Week: Developing Detail | Certain/Uncertain
  • 3rd Week: Least Detail | Greater Uncertainty

Sprint Planning

PROJECT:

• Plan Day: 1st Day of the Sprint Iteration: Monday
• Template: 00 SPRINT: Plan & Report

Sprint Backlog

PROJECT: Milestone per Epic / Sprint is the Backlog | Division of Effort

• Types: Features, Components, Stories, Test Cases, Acceptance
• Product Backlog: #Icebox
  • Early defined, more info needed, greatest uncertainty, higher complexity
    • Label: #ProductLog
• Epic Backlog:
  • Defined by associating with known system design, ui design, integration & build plan, testing planning
    • Naming: Give the Epic a name
    • Label: #EpicLog
    • Split the Product Backlog into Epic aligned milestones
    • Planning: Beyond the Panning Horizon
    • Burn Down by moving into Sprint#
    • Has an associated long-lived branch by same name.
• Sprint Backlog:
  • Highest level of detail, most certainty, lowest complexity, most atomic
    • Per sprint, split the Epic Backlog into each associated sprint.
    • Naming: Give the Sprint a name
    • #SprintLog

Sprints

• #3 SPRINT :: 01 [5 Days] : "The First Config" : - W/S: 23-JUL-10 | W/E: JUL-14
• #4 SPRINT :: 02 [5 Days] : "The Arch n Deploy" : - W/S: 23-JUL-17 | W/E: JUL-21 #DESIGN
• #5 SPRINT :: 03 [5 Days] : "Agile n Test" : - W/S: 23-JUL-24 | W/E: JUL-28

Sprint Labels

• Kind: Group by type
  • Kind: Sprint Agile Kind: Activity | Sprint
  • Plan : Sprint Planning Activity: Sprint Plan
• Horizon:
  • Plan : Horizon Planning Horizon: 3 Weeks
• Per Sprint
  • Sprint 01 : The First Config PLAN: Sprint: Repo & Project Setup and Configure
  • Sprint 02 : Arch n Deploy PLAN: Sprint: Architecture (System, Infra) & Deploy Design
  • Sprint 03 : Agile & Test PLAN: Sprint: TBC
• Calendar W/E: End of the Sprint Week
  • e.g. W/E: Jul 14 Sprint 01: Enď: The First Config
  • e.g. W/E: Jul 21 Sprint 02: Enď: Arch n Deploy
  • e.g. W/E: Jul 28 Sprint 03: Enď: Early Due | Target Deadline

FLOW: To code the authentication token for a Github account and GitHub API, using PyGitHub to access and login from a django app (custom code) and via a django view.

Document: Custom Tutorial | API Generated Tutorial | Proof of Concept Assertion

- This is sample code, and proof of concept. 
- Has yet to be implemented.
- Is research and scoping.

Sources

• Link: To code the authentication token for a Github account and GitHub API, using PyGitHub to access and login from a django app (custom code) and via a django view., Perplexity.Ai

Tutorial

Here is a stepwise tutorial and checklist to code the authentication token for Github and GitHub API, using PyGithub to access and login from a Django app (custom code) and via a Django view:

1. Install PyGithub using pip.
   • You can do this by running the following command in your terminal: pip install PyGithub.
2. Import the necessary modules in your Django app.
   • You will need to import the Github class from the github module, which is part of the PyGithub library.
   • You can do this by adding the following line to the top of your Python file: from github import Github.
3. Create a Github instance.
   • You can do this by calling the Github() constructor and passing in your authentication token as a string
   • For example, if your token is abc123, you can create a Github instance like this: g = Github("abc123").
4. Use the Github instance to access the API.
   • Once you have created a Github instance, you can use it to access the API and perform various operations.
   • For example, you can get a list of repositories for a user by calling the get_user() method and then calling the get_repos() method on the resulting user object.
5. Use the Github instance in a Django view.
   • To use the Github instance in a Django view, you can create a new view function and add the code from step 4 to it
6. Add authentication to your Django app.
   • To add authentication to your Django app, you will need to create a custom authentication backend.
   • You can do this by subclassing the django.contrib.auth.backends.ModelBackend class and overriding the authenticate() method.
7. Add the authentication backend to your Django settings.
   • To use the custom authentication backend, you will need to add it to your Django settings.
8. Use the custom authentication backend in a Django view.
   • To use the custom authentication backend in a Django view, you can call the authenticate() function from the django.contrib.auth module.

Example

• Use the GitHub instance to access the API:
  • This code will print the names of all repositories belonging to the authenticated user.

  g = Github("abc123")
  user = g.get_user()
  repos = user.get_repos()
  for repo in repos:
      print(repo.name)

• Use the GitHub instance in a Django view.:
  • This code
    • Creates a new view function called my_view() that creates a Github instance,
    • Gets a list of repositories for the authenticated user, and
    • Then passes the list of repositories to a template called my_template.html.

  from django.shortcuts import render
  from github import Github
  
  def my_view(request):
      g = Github("abc123")
      user = g.get_user()
      repos = user.get_repos()
      context = {'repos': repos}
      return render(request, 'my_template.html', context)

• Add authentication to your Django app:
• This code
  • Creates a custom authentication backend called GithubBackend that
  • Authenticates users using a Github access token.
  • The access token is passed in as the password argument.

  from django.contrib.auth.backends import ModelBackend
  from github import Github
  
  class GithubBackend(ModelBackend):
      def authenticate(self, request, username=None, password=None, **kwargs):
          try:
              g = Github(password)
              user = g.get_user()
              return user
          except:
              return None

• Add the authentication backend to your Django settings:
  • Can do this by adding the following line to your settings file:
  • Replace path.to with the actual path to your GithubBackend class.

  AUTHENTICATION_BACKENDS = ['path.to.GithubBackend']

• Use the custom authentication backend in a Django view:
  • This code
    • Creates a new view function called my_view() that
    • Authenticates users using a GitHub access token submitted via a POST request.
  • If the authentication is successful, the
    • User is logged in and redirected to a success page.
  • If the authentication fails, the
    • User is redirected to a failure page.
  • If the request method is not POST, the
    • User is shown a login page.

  from django.contrib.auth import authenticate, login
  from django.shortcuts import render
  
  def my_view(request):
      if request.method == 'POST':
          token = request.POST.get('token')
          user = authenticate(request, password=token)
          if user is not None:
              login(request, user)
              return render(request, 'success.html')
          else:
              return render(request, 'failure.html')
      else:
          return render(request, 'login.html')

Checklist:

• Install PyGithub using pip.
• Import the Github class from the github module.
• Create a Github instance using your authentication token.
• Use the Github instance to access the API.
• Create a new view function and add the code from step 4 to it.
• Create a custom authentication backend that authenticates users using a GitHub access token.
• Add the custom authentication backend to your Django settings.
• Use the custom authentication backend in a Django view.

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

[DEFINE](): Inspect, Refine and Define GitHub API as a Candidate Datasource for Dash & Do GitHub.

PROJECT | SOLUTION: Concept | Idea Capture | Discovery

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

Idea

Use GitHub API to define and scope the core and critical DataSource 
For Dash and Do GitHub Manager, 
As well as permissible and authorizable actions and limitations from GitHub LLC.

Context and Problem

The GitHub API is massive, 
And has fair to many applications program interfaces 
Than what is needed for the project, 
So this context is to investing time 
- to research, 
- to refine and 
- to define 
a) what is possible, 
b) what is not possible and 
c) what is permissible by GitHub

Theme | Initiative | Epic | Story

Theme

Inspect the GitHub API

Initiative

Define the constraints, scope and capabilities of the GItHub API 
As key data source and dependency 
For this project within 1-2 weeks 
And plan out the user stories and features as an output from this initiative, 

So that we can, as an outcome, decide to
- move forward with our original conception or 
- must redraw a new one 
- based on more information and 
- less based on assumptions

While sticking to the real-world domain of GitHub as the target domain 
For Developer as a the key target audience.`

ADR: Any Decision Records

The following a key design decision and selection options in employing GitHub API at the highest level.

• ADR000X: Select the GitHub API Technology: REST or GraphQL
• ADR000X: Select the SDK method for accessing GitHub API: GitHub CLI, OctoKit Libraries, or 3rd Party Libraries
• ADR000X: Use GitHub API CORS for Ajax Requests

Epic

To Be defined and listed here

Features

To Be defined and listed here

• Has an accessible landing page
• Has an independent Account Registration
• Has an independent Account Login
• Has an independent Password Reset
• Maybe has 2FA authentication (NINTH)
• Has GitHub Account Integration
• Has GitHub Account Social Login

User Use Cases

• User to login to their account using GitHub using a social account integration
• User to integrate their account with one or more GitHub social accounts
• User to disconnect their account with one or more GitHub social accounts
• User disconnected account with one or more GitHub social accounts has their data removed or archived.
• User can list and view all their repositories in one view or in a multi select combo box.

App Use Cases

• The app can programmatically fetch and get/read the correct GitHub API
• The app can programmatically fetch and get a user authorisation token
• The app can programmatically fetch, get, and successfully authorised and access a user account with an user's authorisation token
• The app can programmatically fetch, get, and handle known API errors
• The app can programmatically fetch, get, and handle known HTTP errors or HTTP errors

Stories

Dev Stories

User Stories

Research

Sources

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

[DEFINE]: System (Software, Container, Component) Design

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

Focus on ...

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

Next Steps

• Add to Product Backlog: Milestone
• Add to Projects
• Define as an Epic? Yes Readme Driven Development
• Refine into a #EpicLog, or #SpringLog
• Assigned to Sprint: #4

Idea

• System & C4 Container design depends on defining the PaaS and DaaS services, accounts, configuration and workflows.

- Define the System Design
- Define the Container Design
- Define the Deployment Design
- Choose the PaaS - ADR
- Choose the DaaS - ADR
- Choose the Deployment / Release Flow
- 

Research

Sources

Readme

• Header: README 7 Architecture ❓✔
• Tags: Design, Architecture
• Notes: Using C4 Models,
• Effort:
  • 7.1 Method | Approach
  • 7. 2 System Design (C4 Model)
    • 7.2.1 GitHub - Developer - Account System
    • 7.2.2 GitHub Account - Developer - Own Web App [Dash & Do GH Manager]
    • 7.2.3 GitHub API - Developer - Own Web App [Dash & Do GH Manager]
    • 7.2.4 Own Web App [Dash & Do GH Manager] - Cloud Hosting Database-as-a-Service (App)
    • 7.2.5 Own Web App [Dash & Do GH Manager] - Cloud Hosting Platform-as-a-Service (App)
  • 7.3 Container Design (C4 Model)
    • 7.3.1 Web Application User Account & Profile
    • 7.3.2 Web Application Dash(board) Single Page Application
    • 7.3.3 Web Application Do(Repo tasks) Single Page Application
  • 7.4 Component Design (C4 Model)
• Link to file: https://github.com/iPoetDev/dash-and-do-github/blob/main/docs/readme/README%207%20Architecture%20%E2%9D%93%E2%9C%94.md

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

[DEFINE](): Inspect and Refine: 12 Factor App as Methodology for defining software as a service (i.e. web apps) as needed.

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

Idea

• Architecture: 12 Factor Methodology
• Theme: Defining approach to Software as a Service delivery

As a developer, 
investigate if the declarative format and having clean contracts is
suitable for deployments to cloud platforms 
and to mimimise divergence between development and production 
by enabling continuous deployment for maximum agility.

Audience:

• Any developer building applications which run as a service
• Ops engineers who deploy or manage such applications.

Research

Sources

• https://12factor.net/
• https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology
• Heroku defined in 2011
• The twelve factors are however cited as a baseline from which to adapt or extend ("Beyond the Twelve-Factor App - Exploring the DNA of Highly Scalable, Resilient Cloud Applications". O'Reilly)

Select Attributes of 12 Factor Apps

1. Select the Factors that are just enough fit/right size for the assessment criteria
2. Scope the Factors that are just beyond the right size for the asssement criteria
3. Exclude the Factor that are excessively beyond the scope of the assessment criteria

Platform (Software) as a Service

• Context: Django Web App
• Hosting: Heroku Cloud PaaS HostingPlatform
• Reference: Twelve-Factor Methodology Applied to a Django App

1. Selected / Required
   • I. Codebase : One codebase tracked in revision control, many deploys
   • II. Dependencies: Explicitly declare and isolate dependencies
   • III. Config: Store config in the environment
   • IV. Backing services: Treat backing services as attached resources
   • [XII. Admin processes] (https://12factor.net/admin-processes): Run admin/management tasks as one-off processes
2. Scope In/Out? or Once Off
   • V. Build, release, run: Strictly separate build and run stages
   • X. Dev/prod parity: Keep development, staging, and production as similar as possible
   • XI. Logs: Treat logs as event streams
3. Exclude/Implicit Design for Django Context:
   • No links
   • VI. Processes
   • VII. Port binding
   • VIII. Concurrency
   • IX. Disposability

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

USER STORY STATEMENT: As a Developer, I want to set and assure Code Quality as a Standard,

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY: As a Developer, I want to set and assure Code Quality as a Standard so that code that is committed is without error, follows conventions, and finally does not leak secrets or cause insecure unauthorised access so ultimately it does not less the overall user experience via error or loss of integrity.

As a: As a Developer, 
I/We want: to set and assure Code Quality as a Standard
So That: I commit code that ...
   a) is without error and 
   b) follows conventions, and finally 
   c) does not leak secrets or cause insecure unauthorised access

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

FLOW: Is DoD F.I.N.I.S.H.E.D.?

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

• Functional: Is the effort equals intended purpose and meets Acceptance Criteria?
• Integrated: It works with no disruptions to other process?
• No Known Issues: Are all known concerns/exceptions related to release are addressed?
• Inspected: Has been inspected by all peers/stakeholders for quality?
• Supportable: Is maintainable for future changes, support, and operations?
• Honors Standards: Can meet all relevant quality standards, compliance, and guidelines?
• Essential Documentation: Has required internal documentation and user guides?
• Deployment Ready: Has completed release preparations and is ready to release?

[DEFINE](): Readme Section: 15.0: Deploy

Readme Docs

• docs/readme: https://github.com/iPoetDev/dash-and-do-github/blob/main/docs/readme/README%2015%20Deploy%20%E2%9D%93%E2%9C%94.md
• Readme.md Section: 15.0

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

Acceptance

Given: the Assessment Criteria Learning Objective, Deploy a Full-Stack Web application
And: the sub-criteria of LO.6.1 (Pass), LO.6.3 (Pass), 
When: the Deployment is described in the Readme 
And: the Final Version is deployed to a Cloud based platform
Then: The Requirement for the Learning Object is finalised 
And: The Final Application is gone live at https://dash-and-do-github.heroku.com

Assessment Criteria:

• LO6 Deploy a Full-Stack Web application using an MVC framework and related contemporary technologies to a cloud-based platform
  • 6.1.P: Deploy a final version of the Full-Stack application code to a cloud-based hosting platform and test to ensure it matches the development version
  • 6.3: Document the deployment process in a README file in English

Research

Sources

• Heroku Docs

Readme

• Headers:
  • Deployment, Commit Flow, GitHub Deployment Flow, Heroku Integrations, App Web URI
• Tags:
  • Host | Cloud | PaaS | Web App | Branching Strategy | Commit Plan | Review & Merge Gates | Release Strategy |
  • Host | Cloud | PaaS | DB Service | Host | Cloud | PaaS | Web App | Deployment Setup |
  • Git Configuration | Keep a Changelog | Commit Messages | Git Commit History | Commit Message Style & Format | Log | Notable Changes | Human Readable | Semantic Versioning
  • Cloud Hosting | Platform as a Service | Database as a Service
  • Managed Database | Relational Database Manage Services | Database as a Service | Datastore Configuration | Data Schema | Data Model
  • Live App | App Name | By-Line
• Notes:

Editorial

• Include
• Edit
• Exclude

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

FLOW: Django Deployment Checklist - Local Script | IDE Config | Pre-commit

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

Checklist: Django Deployments

• Source: https://docs.djangoproject.com/en/4.2/howto/deployment/checklist/
• Run manage.py check --deploy
• Local scripting too

Options

• Create local scripts and add to PyCharm/WebStorm Run Configurations
• Create local scripts and configure pre-commit as the script runner
• Do Both of the above
• Or run as pre-defined pre-commit?

Scope

• Lint with Flake 8 or Ruff (swap as needed), for django files
• Django Tests
• Dry Run Django Migrations
• Dry Run Static Files check
• Run Security Checks with Bandit

AI Prompt

AI Prompt: Perplexity.ai

For:                         Django deployment checks prior to deployment/remote push
In the context of:    writing pre-commit hooks, i.e  the python Library, 
Inspect this:            URL document: https://docs.djangoproject.com/en/4.2/howto/deployment/checklist/
As a:                        pre-commit hook developer, 
Write up:                 as many pre-commit hooks from this checklist, 
And include:           associated bash shell scripts or dependencies, as necessary1

Answer

As a pre-commit hook developer, you can implement several pre-commit hooks based on the Django deployment checklist provided in the URL you mentioned. Here are some examples of pre-commit hooks along with their associated bash shell scripts or dependencies:

Linting with Flake8:

Bash script:

#!/bin/bash
flake8 --exclude=migrations .

Dependencies: Flake8 (pip install flake8)

Running Django tests:

• Dependencies: Django (pip install django)
• Install Bash script:
• Configure PyCharm/WebStorm
• Defined a Local Pre-commit

#!/bin/bash
python manage.py test

Checking for migrations:

• Dependencies: Django (pip install django)
• Install Bash script:
• Configure PyCharm/WebStorm
• Defined a Local Pre-commit

#!/bin/bash
python manage.py makemigrations --check --dry-run

Checking for static files:

• Dependencies: Django (pip install django)
• Install Bash script:
• Configure PyCharm/WebStorm
• Defined a Local Pre-commit

#!/bin/bash
python manage.py collectstatic --dry-run --noinput

Running security checks with Bandit:

• Dependencies: Bandit (pip install bandit)
• Install Bash script:
• Configure PyCharm/WebStorm
• Has a pre-commit version?

#!/bin/bash
bandit -r .

• Pre-commit: github.com/PyCQA/bandit
• Pre-commit configured: Yes

[DEFINE](): Wiki as Appendices, Criteria Checklist, Side Notes

PROJECT | SOLUTION: Document Driven Effort

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Wiki: Appendices
  • Home
  • Table of Contents
  • DEVELOPER: Experience, Author notes,
  • SOLUTIONS:
  • ACADEMIC: Criteria: Pass, Merit, Distinct
  • Sidebar, Footer
• Proofing
• Editorial

Idea

Copy/Port the prior effort from https://github.com/iPoetDev/P4Template/wiki

Research

Sources

Wiki

• Wiki
  • Home
  • Table of Contents
  • DEVELOPER
  • SOLUTIONS
  • ACADEMIC
  • Side Bar
  • Footer

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:As a 12 Factor App Developer, I must explicitly declare all isolated dependencies, via a dependency declaration manifest and dependency isolation tooling, so that the web services' dependency specification is uniformly applied from development through to production, across many deploys from one code base.

In the context of: The 12 Factor App Methodology
As a: As a 12 Factor App Developer 
I/We: must explicitly declare all isolated dependencies
Via: a dependency declaration manifest and dependency isolation tooling
So That: the web services' dependency specification is uniformly applied from development through to production
  ... across many deploys from one Python 3.11 code base.  

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria: for a Python dependency declaration manifest

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given: we use PIP for python for the dependency declaration manifest completely and exactly ...
When: we define our `requirements.txt` and dependency versioning strategies (pinning or @latest)
Then: we should accept the story that we expect the web services' dependency specification is uniformly applied from development through to production.

Because we can then expect idempotent configuration and deployment from the right runtime and dependency manager (i.e. a Heroku buildpack) for a deterministic build command ..
From many deploy from one python code base.

Related

ADR-000? || EPIC-000? || FEATURE-000?

Acceptance Criteria: for a Python dependency isolation tool

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given: we use `venv` for python dependency in an app local virtual environment for bundling.
When: we deploy a Heroku Python Build pack and a runtime Python specification
Then: we should accept the story that we expect the web services' dependency specification is uniformly applied from development through to production.

Because we can then expect idempotent configuration and deployment from the right runtime and dependency manager (i.e. a Heroku buildpack) for a deterministic build command ..
From many deploy from one python code base.

Related

ADR-000? || EPIC-000? || FEATURE-000?

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

USER STORY STATEMENT: Inspect, Learn and Refine the GitHub API options.

User Case | Epic's Task | Enabler Task

STORY:

As a: developer,
I/We need: to inspect and refine the GitHub API for the solutions Use Case and Concept as a Candidate Datasource
  And: Read the GitHub API documentation to take notes.
So That/Because: 
- the GitHub API has fair to many applications program interfaces 
- has a steep learning curve 
- has a large documentation scope and depth, with many rules

Type of: Epic Task & Enabler Task

• Read the GitHub Document API: https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given: That the GitHub API documentation is inspected, 
When: The GitHub API is refined and defined enough to decide to proceed with this use case 
Then: We can proceed with the use case for the GitHub Dash and Do solution as a proof of concept.

Related

ADR-000? || EPIC-000? || FEATURE-000?

SPRINT #03 - Milestone: Agile Plan | Control

• Replace Milestone Id in link.
• Add Sprint Sequence Id in Title.
• Sprint 03 : Agile & Test |
  Sprint 03 : Agile & Test PLAN: Sprint: TBC

Kind: Sprint Agile Kind: Activity | Sprint
Plan : Horizon Planning Horizon: 3 Weeks : 3 Weeks

Spint Backlog

Add Planned Issues Below

VIEWS: Replace Project ID in link,

• Project ID: (21): https://github.com/users/iPoetDev/projects/21

|

• #.
• #.

Sprint Plan | Report

• Backlog:
• Epic: " "
  Kind: Epic
• Features:
  Kind: Feature
  • :
  • :
• Stories:
  Kind: Story
  • :
  • :
• Acceptance:
  Kind: Accept
  • :
  • :
• Progress:
  • Plan:
  • Started:
  • Not Completed:
  • Completed:
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

FLOW: Deploy Flow

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

App Initialise

Common Configuration

• Login to Heroku
• Create a new App, name and select Europe region, do not add to pipeline
• Deployment Method: GitHub, connect to iPoetDev, and add dash-and-do-github repository
• Automatic Deploys: Linked to the Heroku trunk branch., and enable.
  • Await until CI have completed, is deployable and branch tests have passed. ⛔ Costs incurred.
• Manual Deploy: useful if you want to redeploy a branch repeatedly.
• Snapshot the new app settings
• Buildpacks: Use to install dependencies, and configure environment
  • NodeJs: version v
    • Requirements:
  • Python: version v
    • Requirements:
• Investigate if custom buildpacks for ... a) cost and b) are needed, and c) configuration requirements
  • Heroku-Django
  • Django

Pipeline Define & Strategy

• Create two Pipelines
  • Create a Development Pipeline with one build stage:
    1. Development:
       • Intent: Initial stages, high churn, rough and error prone.
  • Create a Release Pipeline with two build stages:
    1. Integrate: Staging: Review
       • Intent: Review, Check, User Acceptance Testing and higher quality.
    2. Live: Production - Submission Quality
       • Intent: Submission quality, User Accepted,
• Add an app per a stage in a pipeline
  1. dash-and-do-dev: Development App: dash-and-do
  2. dash-and-do-release: Staging App: dash-and-do-integrate
  3. dash-and-do-release: Production App: dash-and-do-github
• Connect multiple apps together and promote code
  • Connected pipelines, with GitHub i.e. Connected to iPoetDev/dash-and-do-github by iPoetDev iPoetDev
    • dash-and-do-dev/dev (app) automatically deploys from github/heroku-dev branch
    • dash-and-do-dev/integrate (app) automatically deploys from github/heroku-integrate branch
    • dash-and-do-dev/production (app) automatically deploys from github/heroku-prod branch
  • Can enable review apps#
    • Review apps only for dash-and-do-dev pipeline.
  • Create apps, new builds for each new pull requests to each of these GitHub Branches
    • PR & Merge into github/heroku-dev => Build the dash-and-do-dev pipeline's Development App: dash-and-do
    • PR & Merge into github/heroku-integrate => Build the dash-and-do-release pipeline's Staging App: dash-and-do-integrate
    • PR & Merge into github/heroku-prod => Build the dash-and-do-release pipeline's Production App: dash-and-do-github

Continuous Integration and Deployment

• Bare bones
• Two Pipes, with Dev being a dead-end, disposeable, and iterable
• Review apps on the dev pipe
• Extra work to move code between dev trunk, integration trunks and heroku's 3 trunks - Think about effort v performance?

• https://elements.heroku.com/buildpacks/heroku/django-heroku
• https://elements.heroku.com/buildpacks/django/django

USER STORY STATEMENT:

User Story | Enabler Task

STORY: As a 12 Factor App Developer, I want to store Config in the Environment

In the context of Resource Management, Best Practice Secrets, and Per-Deploy Cannonical Values
As a: As a 12 Factor App Developer, 
I/We want: to store an application's Config in the Environment
Where: it is likely to vary between `deploys` (staging, production, developer environments, etc)
So to: allow a single codebase to be deployed into different environments without change/customization.

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

12 Factor App Definition: Config

An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:

• Resource handles to the database, Memcached, and other backing services
• Credentials to external services such as Amazon S3 or Twitter
• Per-deploy values such as the canonical hostname for the deploy

Constraint and Concerns

It is a violation of twelve-factor, which requires strict separation of config from code.

• Apps sometimes store config as constants in the code.
• Config varies substantially across deploys, code does not.

ADR-Y: Why Statement for Choosing a model approach to manage/consume Configuration in the Environment.

In the context of selecting, managing and consuming configuration values in the Environment
Facing the concerns of storing config, as hardcoded values, in code, and the associated loss of confidentiality, integrity, and availability (i.e. application compromise)

We decided to store config in environmental variables (i.e. *env vars*, *ConfigVars*) without grouping across different environments,
  - So that these `env vars` independently managed for each deploy
And neglected, as alternatives, using secret vault managers and config files (i.e. *.env*)  and other config mechanism ..
To achieve, in full or in part, 
  i) to be language and OS- agnostic
 ii) compliantly without compromising any credentials or the application CIA.
iii) scaling up smoothly as the app naturally expands into more deploys over its lifetime.
Accepting that `Cost` | `Effort` | `Trade Off` 
 - ?
 - ?

Acceptance Criteria: For Connection Strings to Backing Services

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

Acceptance Criteria: Credentials/Secrets to External Services

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

Acceptance Criteria: Target Environment Specifications

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

• 12 Factor Config: https://12factor.net/config
• Twelve-Factor Methodology Applied to a Django App: Config

REFINE DO App :: Single Page Architecture: Do | Action | Tasker: A single page, multi component, single pane of glass (SPOG) for GitHub Repository Bulk Actions.

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept

• Research

• Agile Planning

  • ADR
  • Epic
  • Feature
  • Components
  • Stories
    • 🔢 Options
      • 👍🏽 Benefits
      • 👎🏽 Trade-Offs
      • ⛏️ Uses: Components
  • Acceptance
    • 🧪 Test Case:
    • 🎯 Test State:
  • Assessment

• Readme

  • Writing
  • Diagramming

• Proofing

• Editorial

• DEFINE document acts as internal Product/Feature/Component Definition Document and a statement of effort and Idea capture and specification.

Idea

Research

Sources

Agile Planning

ADR: Any Decision Records | Requirements

Epic

• `EPIC NAME:

Categorisation:

Related | Added Context

Related Epics

GitHub Integration:

Feature

• Feature

In Focus

• Home Page URL/Domain: Users can

Components

• [ ]

Stories

A Flow Label for the feature: Feature.

• Verify Registration User Story: As a ... I want to ... so that ... and ...
  • Option: Option Name:
    • 👍🏽 Benefit:
    • 👎🏽 Trade Off:
    • ⛏️ Uses:

      ---

A Flow Label for the feature: Feature.

• Verify Registration User Story: As a ... I want to ... so that ... and ...
  • Option: Option Name:
    • 👍🏽 Benefit:
    • 👎🏽 Trade Off:
    • ⛏️ Uses:

      ---

Acceptance

• User Criteria: Flow: In the scenario of .... , then the expected outcome for a ... and .... .
  • UA Test: As a user, I should be able to action/outcome on the Dash and Do GitHub web app.

    ---

• User Criteria: Flow: In the scenario of .... , then the expected outcome for a ... and .... .
  • UA Test: As a user, I should be able to action/outcome on the Dash and Do GitHub web app.

    ---

Assessment Criteria

Meets the following

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit

SPRINT # 7 - Milestone: EPIC #4: FEATURE: "Release: v0.5: Core Web App & User Accounts"

Issue: #64

Kind: Sprint Agile Kind: Activity | Sprint > Plan : Horizon Planning Horizon: 3 Weeks : 4 Weeks

• Horizon Start: 23-Jul-31 (Mon)
• Horizon End: 23-Sep-03 (Sun)

Sprint 07

• Week Start: 23-Aug-21
• Week End: 23-Aug-28

Spint Backlog

Add Planned Issues/tasks (outline only) below:

1. Draw the UI/UX on paper
2. Draw the UI/UX in digital media
3. Create the UI in code as a whole page unit
4. Extract the Django template includes per component/design + functional unit into own files
5. Apply the Design to master template (``page.html) and update the includes once the over all design (CSS, tailwind) is complete.

Workflow

• See #97

Sprint Commits

• ui + feat (design,build,code): index.html Mock Up/UI Skeleton/Structure

Sprint Impediment

The following impediment is impacting the execution of the current epic and is shifting more sprints into the epic and sprint planning and thus increasing the planning horizon.

• #95

UI/UX Plan | Report

• HTML Layout for base master template page
  • Semantics
    • Header
    • Main Content
    • Footer
  • Navigation
    • Top Nav
    • Sidebar
    • Footer
  • Design Blocks
    • Hero Slider
    • Sidebar Nav Blocks

Sprint Plan | Report

• Epic: "04: Release: v0.5: Core Web App & User Accounts" Design, Build, Test, Integrate, Deploy, Accept, Release "
  Kind: Epic
• Features:
  Kind: Feature
  • Page (Wireframe)
    • Index Page : index.html
    • Verification Page: verify.html
  • Unauthorised User: Public Page Block's + Design Blocks
    • Brand Identity
    • Public Top Nav (Right) & Drop down menu
      • Login Form
    • No Sidebar Nav
    • Hero Slider
    • User Forms
    • Contact Form
    • Footer
  • Authorised User: Private Page Components + Design Blocks
    • Brand Identity
    • Private Top Nav (Right) & Drop down menu
      • Account Menu
    • Sidebar Nav & Nav Groups
    • Hero Slider
    • Account Cards
    • Contact Form
    • Footer
  • Forms :
    • Sign Up Form
    • Login Form
    • Contact Form
    • ?? Reset Form
  • Signup Verification Flow
    • Email verification
  • Form Messages: Notifications#
• Features (2)
  • #98
  • #99
  • #100
  • #101
  • #102
  • #103
  • #104
• Stories:
  Kind: Story
  • #81
  • #54
  • #83
  • #66
  • #68
  • #69
  • #70
  • #73
  • #71
  • #84
  • #85
• Acceptance:
  Kind: Accept
  • None yet.
• Progress:
  • Started:
  • Not Completed:
  • Completed:
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

[DEFINE](): High Level Deployment Flow

PROJECT | SOLUTION: Deployment

• Ideation, Concept
• Research
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

Idea

Desig,m develop, practice and implement a deployment workflow

Research

Sources

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

SPRINT # 9?? - Release: v0.5: Core Web App & User Accounts

Issue: #65: SPRINT PLAN: 09 [7 Days]: Release: v0.5: “Core + Accounts: Integrate, Test, Deploy”
Kind: Sprint Agile Kind: Activity | Sprint > Plan : Horizon Planning Horizon: 3 Weeks : 5 Weeks

• Horizon Start: July 31
• Horizon End: Sep 16

• Week Start: 23-Sep-11
• Week End: 23-Sep-16

Sprint Objectives

• Integration of Front End + Backend Logic/development
• Post Implementation Testing (not TDD?)
  • Given am uncertain and learning testing, deciding to do testing after 1st concept code implementation
• Developer Decisions / ADRs;
  • ADR000X: Unit Testing or Integration Testing or Lean TDD
  • ADD000X: Python Testing
  • ADR000X JavaScript Testing
• UI Testing
• User Acceptance Testing
• Documentation: Readme
• Deployment the v0.5 Live App (Heroku)

Spint Backlog

Add Planned Issues Below

VIEWS: Replace Project ID in link,

• #.
• #.

Sprint Plan | Report

• Epic: " "
  Kind: Epic
• Features:
  Kind: Feature
  • :
  • :
• Stories:
  Kind: Story
  • :
  • :
• Acceptance:
  Kind: Accept
  • :
  • :
• Progress:
  • Started:
  • Not Completed:
  • Completed:
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

FLOW: Integration Checks, Integration Quality, Integration Valid, Linting

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

• Criteria:
• Complete? ❓✔

Goals

• Prevent broken code from being uploaded to the default branch (usually main) as well as to the deploy-flow branches (Heroku-*)
• Help establish coding best practices across multiple languages
• Build guidelines for code layout and format
• Automate the process to help streamline code reviews

GitHub Action | Workflow

• Source: https://github.com/super-linter/super-linter
• Marketplace: https://github.com/marketplace/actions/super-linter
  • Target Linters
    • CSS | stylelint
    • HTML | HTMLHint
    • JavaScript | ESLint
    • Python : PyLint | Flake8 -> See if ruff has an Workflow
• Config
  • Create Tokens with correct scopes
  • Target Config files (see below)
• Actions
  • On Push: Ignore * -> Done locally and with pre-commit
  • On Pull Requests -> main, heroku-* , i.e the integration trunk (review gate), and deployment trunks (release gate)

Repository

Project Root

- /dash-and-do-github
  - /.github
  - /docs
  - .editorconfig                                               # EditorConfig: IDE Code and Whitespace Quality
  - .gitignore                                                  # Git: Exclude Files to Remote & Secrets 
  - .eslintrc.js                                                # ESLint: JS Quality
  - .stylelintrc.json                                           # StyleLint: CSS Quality
  - package.json                                                # NPM: Dependencies Config
  - package.json.lock                                           # NPM: Packaging
  - README.md                                                   # Readme
  - .prettierignore                                             # Prettier: Ignore files
  - pyproject.toml                                              # Python Libraries config, inc Ruff for Linting
  - .htmlhintrc                                                 # HTMLHint: HTML Quality
  - LICENSE                                                     # Licence
  - .pre-commit-config.yml                                      # Pre-commit Hooks
  - .prettier.yaml                                              # Prettier: Code Formatting

1. CI Action:

Developer Experience, Code Quality, DX Tooling, IDE Integrations, CLI Checks

• HTMLHint - HTML Correctness -> .htmlhintrc
  • Uses pre-commits: See Issue | Doc:
  • Uses (this) CI Action
• Stylelinerc - CSS Correctness -> stylelintrc.json
  • Dependencies: Shared Configs -> package.json
  • Uses pre-commits: See Issue | Doc:
  • Uses (this) CI Action
• Eslint - JavaScript Correctness -> eslintrc.js
  • Dependencies: Shared Configs -> package.json
  • Uses pre-commits: See Issue | Doc:
  • Uses (this) CI Action

HTML Checks | CI Action

CI Workflow

1. .
2. .

CSS Checks | CI Action

CI Workflow

1. .
2. .

JavaScript | CI Action

CI Workflow

1. .
2. .

Sources

Docs

• Marketplace: https://github.com/marketplace/actions/super-linter
• GitHub: https://github.com/super-linter/super-linter
• Perplexity AI: https://www.perplexity.ai/search/05137f79-80cb-4766-bdd3-84326ace61e5?s=c

Guides

• CSS stylelint
• JavaScript ESLint
• HTML HTMLHint

USER STORY STATEMENT: Architecture - System & Sub System/Container Level

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a: Developer
I/We want: to design a system and sub system level design ...
So That/Because: so the system/web app can be a) explained to others and b) document these in the readme ...

Type of: Epic Task 

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

Reference:

• User Story: The smallest decomposition of an effort or requirement that is part of a larger epic
• As a: type of user | user type | role | group of users
• I/We want: A task's goal | outcome | benefit | {disbenefit to be avoided}
• So That / Because: The reason | why this is needed/desired.

Method

• A User story must/should be atomic and non-decomposable as possible, i.e. a simple statement.
• Story should describe a need that can be satisfied by introducing a new feature or
  changing an existing feature.
• Stories identify what someone wants to accomplish with your product and why.
• Story splitting is the practice of breaking big pieces of work down into smaller, deliverable
  pieces of work.

[DEFINE](): A User Registration, Login System for a User Profile and Data Model

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept
• Research
• Agile Planning
  • ADR: Any Decision Records / Requirements
  • Epic:
  • Feature:
  • Components:
  • Stories
  • Acceptance
    • UAC Test case:
• Readme
  • Writing
  • Diagramming
• Proofing
• Editorial

• This DEFINE issue is the overall Product/Component Definition Document (Or Requirement Work Specification) that lists and summaries the Component & Deliverables to be scoped for the statement of effort.

Idea

In the context of learning from other's prior art efforts,
As a developer, I want to understand the steps and features 
To design and develop a Django component (a Django app) 
 - For a User Registration & Login System.
 - For a User Profile that is a User controlled and is CRUD data model driven
 - For Account security controls and recovery
 - For an Administrators to CRUD Users

Research

Sources

• Perplexity.AI: What Sources and Tutorials are to add a GitHub Login to a Django Web App
• GitHub.com: Django registration and login system
• Dev.To: Django Registration/Login App Series Articles

Agile Planning

ADR: Any Decision Records

Related Decisions | Requirements

• ADR000X: Select a Django package for Data Drive Forms.
• ADR000X: Select a Django package for standard Authentication, Authorisation and Role Based Access backend and processes.
• ADR000X: Select a Django package for social Authentication for GitHub Account integration/backends
• ADR000X: Select a Django package for password validation & hashing (grouped of related choices).
• ADR000X: Select a Django Session Engines

Epic

Key Epic Story | Theme | Requirement

• GitHub Integration: For new Developers who have GitHub accounts, who want to integrate their GitHub account and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and secures a social login with GitHub as an Identity provider, so it protects these next two following epics, and associated features (see below).

Related | Added Context

GitHub Repositories Reporting: For new Developers who have GitHub accounts, who want to have a dashboard overview of their GitHub account, and repositories in bulk, and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and a report on the state of their repositories at a single glance.
GitHub Repositories Tasks: For new Developers who have GitHub accounts, who want to have an bulk activity manager of their GitHub repositories, and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and tasks to update the state of their repositories at a single action or in as few minimal steps as possible over a number of repositories.

===================================================================

Feature

Source: https://github.com/earthcomfy/Django-registration-and-login-system#basic-features-of-the-app

In Focus:

• Register – Users can register and create a new profile
• Login - Registered users can login using username and password
• User Profile - Once logged in, users can create and update additional information such as avatar and bio in the profile page
• Update Profile – Users can update their information such as username, email, password, avatar and bio
• Remember me – Cookie Option, users don’t have to provide credentials every time they hit the site
• Forgot Password – Users can easily retrieve their password if they forget it
• Admin Panel – admin can CRUD users

Above text is a direct extract from Hana Belay (GitHub @earthcomfy) Readme. See Sources above.

Related

#49 - See the Features for the Social Account Integration

===================================================================

Components

• Django Libraries (Once ADR are recorded).
  • [ ]
• Django Authentication
• Django Session Engines
• Django Templates
• Django Forms
• Data Models
  • Django User Profile
  • (Optional) Django User Custom Model
• Django Admin Panel
• Django Settings
• Environmental Variables
• Managed DBaaS

===================================================================

Story

Registration User Flow for the feature: Register.

• #54
• #66
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Core Login User Flow for the feature: Login

• #83
• #67
• #68
• #84
• #85
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Forgot Login User Flow for the feature: Forgot Password.

• #69
• #70
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sessions User Flow for the feature: Remember me feature.

• #71
• #73
• #74
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Account User Flow for the features of i) User Profile and ii) Update Profiles.

• #75
• #76
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Account User Flow for the features of i) User Profile and ii) Update Profiles.

• #77
• #78
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Admin Account User Flow for the feature: Admin Panel

• #79
• #80

===================================================================

User Acceptance

Summary | See Individual or Groups UAC and UAT issues. | Happy Path Testing

• Registration User Flow: In the scenario of user registration of unknown or new users to the site with the intent to create a new account, then the expected outcome for a new user is to successfully register with the app/web service, and to have received a verification email to confirm the account.
  • UA Test: As a user, I should be able to register a new account on the Dash and Do GitHub web app.

    ---

• Core Login User Flow: In the scenario of user login and authorisation of known existing users of the site, previous verified and registered, then the expected outcome for a verified known user is to successfully access with the service and to access their own user profile (i.e. the user account).
  • UA Test: As a user, I should be able to login my own account on the Dash and Do GitHub web app.

    ---

• Forgot Login User Flow: In the scenario of forgotten user login and unable to authorisation of known existing users of the site, then the expected outcome of a forgotten password is the successful retrieval of a forgotten password link, and then the successful reset of a new password associated with the correct user and then confirmation that the user can use the new password to access their account again.
  • UA Test: As a user, I should be able to reset a password to my own account on the Dash and Do GitHub web app.

    ---

• Session Management User Flow: In the scenario of the session and user state-based web access control and permissions, then the user should be able to stay logged in once logged in and authenticated and use the remember the user on return visits and until the cookie value is cleared or the account is timed out.
  • UA Test: As a user, I should be able to leave and review the web between session, and not have re-login/re-authenticate to my account on the Dash and Do GitHub web app.

    ---

• Account User Flow: In the scenario of an authenticated and authorised service user wanting to manage and control their account, then the user can access and read their profile and then make additions, edits to fields of their profile as well as delete or remove data.
  • UA Test: As a user, I should be able to access and read my own account's profile page on the Dash and Do GItHub web app.
  • UA Test: As a user, I should be able to edit and update my own account's profile page on the Dash and Do GItHub web app.

    ---

• Delete Account User Flow In the scenario of an authenticated service user wanting to delete their account, then the user should be allowed to delete their account and be warned that this account is permanent as well as get a confirmation that their account was deleted.
  • UA Test: As a user, I should be able to delete and remote my own account's profile data on the Dash and Do GitHub web app.

  ---

• Admin User Flow`: In the scenario of an administrator of all Dash and Do GitHub web app users, the the admin user should be able to create, view, list, edit, remove existing user profiles and or modify specific limited user fields.
  • UA Test: As an admin user, I should be able to CRUD all users' profile on the Dash and Do GitHub web app.

===================================================================

Assessment Criteria

Meets the following

• 4.03: PASS & MERIT: Access, Authentication & Authorisations
  • 3.1: Apply role-based login and registration functionality
  • 3.2: The current login state is reflected to the user
  • 3.3: Users should not be permitted to access restricted content and to access the functionality.

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

[REFINE: Web App Landing Page, Forms & Impressum: A Hero Container, Home URL, & Registration for Dash & Do GitHub](#55)

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept

• Research

• Agile Planning

  • ADR
  • Epic
  • Feature
  • Components
  • Stories
    • 🔢 Options
      • 👍🏽 Benefits
      • 👎🏽 Trade-Offs
      • ⛏️ Uses: Components
  • Acceptance
    • 🧪 Test Case:
    • 🎯 Test State:
  • Assessment

• Readme

  • Writing
  • Diagramming

• Proofing

• Editorial

• DEFINE document acts as internal Product/Feature/Component Definition Document and a statement of effort and Idea capture and specification.

Idea

A single landing (home) page (as a single page architecture)
  - web service URL (Domain)
  - with an in-page navigation (jump, header, floating, footer).
- that has a hero section on the top third;
- that has a call to action on the middle third
  - and offers the service registration or login form, 
  - with GitHub Integration
- that has an informative about on the lower third 
  - and contact form section.

Research

Sources

• Perplexity. Ai, 2023-Aug-01, "What sources and or tutorials are there to host multiple forms on a single page as home page and call to actions using HTMX and Django templates"

Agile Planning

ADR: Any Decision Records | Requirements

Epic

• Web App Singe Home Page: For Software Developers as GitHub Users ... Who want to review, report and do bulk activity on their GitHub Account; Our Dash and Do GitHub Manager website/web app Is a helpful website home page That provides home page for the service, useful in place (no reload) registration & login form, and offers integration with GitHub via social accounts As Well As an informative About & Contact [Page | Section] On a single web page.

Categorisation: Front End, Web Client, HTML Page, Web/HTML Forms

Related | Added Context

GitHub Integration: For new Developers who have GitHub accounts, who want to integrate their GitHub account and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and secures a social login with GitHub as an Identity provider, so it protects these next two following epics, and associated features (see below).
- See the Define: Issue #53
GitHub Repositories Reporting: For new Developers who have GitHub accounts, who want to have a dashboard overview of their GitHub account, and repositories in bulk, and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and a report on the state of their repositories at a single glance.
GitHub Repositories Tasks: For new Developers who have GitHub accounts, who want to have an bulk activity manager of their GitHub repositories, and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and tasks to update the state of their repositories at a single action or in as few minimal steps as possible over a number of repositories.

Feature

• Feature

In Focus

• Home Page URL/Domain: Users can find and locate the web service using the URL/brand ID
• Hero Section: Users can get an immediate impression about the brand Id of the web service
  • Hero Banner
  • Branding.
• A Call to Action Form Section with
  • Registration Form: New User can start the registration via a form.
  • Login Form: Existing Users can login via form.
  • Password Reset Form: Existing User can reset their password via a form.
    • Password Reset confirmation popover/confirmation.
• An Impressa Section
  • A Contact Form: Users can contact the web service owner and developer.

Components

• HTMX
• HTML Forms
• Django Forms/Formsets (Dynamic?)
• CSS Utility Framework
• Images
• JavaScript Client Framework
• Django Authentication,
• Django CSRF
• Django Messages/Email
• Django Validators,
• Django Sessions,
• Django Messages (Status),
• Django Templates
• Django URLs

Stories

Landing Page: Home for the feature: Home Page and Domain

• #81
• #82

Registration User Flow for the feature: Register.

• #54
  • Option: Embedded HTMX New Registration Form: in a Single Page Architectural / AJAX pattern.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • ⛏️ Uses: Django Form(sets), Django Authentication, Django Validators, Django CSRF, Django Messages (Email), Django Sessions, Django Messages (Status), HTMX, Django Template
• #66
  • Option: Separate New Registrant Confirmation Page: with/without page redirect to login form.
    • 👍🏽 Benefit: Ease implementation.
    • 👎🏽 Trade Off: User has to click and navigated to login form unless an automated redirect employed.
    • 👎🏽 Trade Off: A separate HTML Page for design, build, test and deploy
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs
  • Option: Embedded New Registrant Confirmation Message with redirect to Login Form:
    • 👍🏽 Benefit: Improved User Experience, Reduces additional page need.
    • 👎🏽 Trade Off: Additional challenge and complexity to have in page response.
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs

      ---

Core Login User Flow for the feature: Login

• #67
  • Option: Embedded HTMX Login Form: in a Single Page Architectural / AJAX pattern.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Form(sets), Django Authentication, Django Validators, Django CSRF, Django Messages (Email), Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs
• #68
  • Option: Embedded Confirmation Message on Login Form:
    • 👍🏽 Benefit: Expect ease of implementation.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs

      ---

Forgot Login User Flow for the feature: Forgot Password.

• #69
  • Option: Embedded HTMX Reset Form: in a Single Page Architectural / AJAX pattern.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Form(sets), Django Authentication, Django Validators, Django CSRF, Django Messages (Email), Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs
• #70
  • Option: Embedded Forgot Password Confirmation Message with redirect to Login Form:
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs

      ---

Sessions User Flow for the feature: Remember me feature.

• #71
  • Option: Embedded Currently Logged In Confirmation Message Following Enabled Remember Me checkbox:
    • 👍🏽 Benefit: Improved user feedback with Confirmation in-page.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs
  • Option: Embedded Currently Logged Out Confirmation Message with redirect to Login Form/Signed Out:
    • 👍🏽 Benefit: Improved user feedback with Confirmation in-page.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Sessions, Django Messages (Status), HTMX, Django Template, Django URLs

      ---

Contact Form User Flow for the feature: Contact Form

• #72
  • Option: Embedded HTMX Reset Form: in a Single Page Architectural / AJAX pattern.
    • 👍🏽 Benefit: Single page architectural pattern allows for no page refresh.
    • 👎🏽 Trade Off:
    • ⛏️ Uses: Django Form(sets), Django Authentication, Django Validators, Django CSRF, Django Messages (Email), Django URLs

Acceptance

• Registration User Flow: In the scenario of user registration of unknown or new users to the site with the intent to create a new account, then the expected outcome for a new user is to successfully register with the app/web service, and to have received a verification email to confirm the account.
  • UA Test: As a user, I should be able to register a new account on the Dash and Do GitHub web app.

    ---

• Core Login User Flow: In the scenario of user login and authorisation of known existing users of the site, previous verified and registered, then the expected outcome for a verified known user is to successfully access with the service and to access their own user profile (i.e. the user account).
  • UA Test: As a user, I should be able to login my own account on the Dash and Do GitHub web app.

    ---

• Forgot Login User Flow: In the scenario of forgotten user login and unable to authorisation of known existing users of the site, then the expected outcome of a forgotten password is the successful retrieval of a forgotten password link, and then the successful reset of a new password associated with the correct user and then confirmation that the user can use the new password to access their account again.
  • UA Test: As a user, I should be able to reset a password to my own account on the Dash and Do GitHub web app.

    ---

• Session Management User Flow: In the scenario of the session and user state-based web access control and permissions, then the user should be able to stay logged in once logged in and authenticated and use the remember the user on return visits and until the cookie value is cleared or the account is timed out.
  • UA Test: As a user, I should be able to leave and review the web between session, and not have re-login/re-authenticate to my account on the Dash and Do GitHub web app.

    ---

• Contact Form User Flow: In the scenario of a user wanting to contact the website (owner), then the user should be able to write a message in a contact form so to send a message to the website (owner).
  • UA Test: As a user, I should be able to send a message to the Dash and Do GitHub web app.

    ---

Assessment Criteria

Meets the following

• 4.03: PASS & MERIT: Access, Authentication & Authorisations
  • 3.1: Apply role-based login and registration functionality
  • 3.2: The current login state is reflected to the user

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit
• Exclude

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY: As a 12 Factor App Developer, I must explicitly declare all isolated dependencies, via a dependency declaration manifest and dependency isolation tooling, so that the web services' dependency specification is uniformly applied from development through to production, across many deploys from one code base.

In the context of: The 12 Factor App Methodology
As a: As a 12 Factor App Developer 
I/We: must explicitly declare all isolated dependencies for JavaScript
Via: a dependency declaration manifest and dependency isolation tooling
So That: the web services' dependency specification is uniformly applied from development through to production
  ... across many deploys from one JavaScript/Node code base.  

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria: for a Python dependency declaration manifest

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given: we use `npm`, for `JavaScript`/`NodeJs`, for the dependency declaration manifest management completely and exactly ...
When: we define our `package,json` and dependency versioning strategies (pinning or @latest)
Then: we should accept the story that we expect the web services' dependency specification is uniformly applied from development through to production.

Because we can then expect idempotent configuration and deployment from the right runtime and dependency manager (i.e. a Heroku buildpack) for a deterministic build command ..
From many deploy from one python code base.

Related

ADR-000? || EPIC-000? || FEATURE-000?

Acceptance Criteria: for a Python dependency isolation tool

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given: we use `npm` for python dependency in an app local virtual environment for bundling.
When: we deploy a Heroku `NodeJs` Build pack
Then: we should accept the story that we expect the web services' dependency specification is uniformly applied from development through to production.

Because we can then expect idempotent configuration and deployment from the right runtime and dependency manager (i.e. a Heroku buildpack) for a deterministic build command ..
From many deploy from one python code base.

Related

ADR-000? || EPIC-000? || FEATURE-000?

SPRINT - Milestone: Agile Plan | Control

• Replace Milestone Id in link.
• Add Sprint Sequence Id in Title.
• Copy Sprint label per sprint.
  Sprint 02 : Arch n Deploy PLAN: Sprint: Architecture (System, Infra) & Deploy Design

Kind: Sprint Agile Kind: Activity | Sprint
Plan : Horizon Planning Horizon: 3 Weeks : 3 Weeks

• Note: I extended the Sprint 2 activities into Sprint 3 to account for
  1. Pace of learning and Uncertainty
  2. Personal capacity reasons.

Spint Backlog

Add Planned Issues Below

VIEWS: Replace Project ID in link,

• Project: 21 AGILE - PLANNER
  |

Backlog: Agile & Planner

• EpicLog | Sprint Log: Milestone 2 AGILE Plan | Control

Sprint Plan | Report

• Backlog: Agile - Planner
  Backlog: Agile & Planner

  • #7
  • #14
  • #19
  • #20
  • #21
  • #23
  • #24
  • #25

• Epic: " The Arch & Deploy "
  Kind: Epic

• Features:
  Kind: Feature

  • N/a :
  • n/a :

• Stories:
  Kind: Story

  • #18
  • #25
  • #26
  • #27
  • #28
  • #29
  • #30
  • #31

• Acceptance: The following have reached Accepted for UAC
  Kind: Accept

  • :
  • :

• Progress:

  • Planned: 1
  • Started:
  • Not Completed:
  • Completed:
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

FLOW: Setup | Configuration of Project Repository

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

FLOW: Architecture Design Flow

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

• Uses C4 Model
  • ADR-Y on C4Model and that design approach
• Design the following
  • System Context Diagrams: External Systems, Relationships with Proposed Internal Systems
  • Container Diagrams (Software Systems):
  • Component Designs
• Add to Section 7.0 Architecture (Docs/Readme)
• Upload the images with named files
• Check the image files
• Add to Commit with

proj (document,readme): __

Intent: Architecture, 7.0 Readme, Diagrams/Models
Tag: project,  readme, documentation
Sprint: 02: Ends 23-7-21
Changelog: 2023-07-17 v00.00.001:01
- add:
  - .
- update:
  - .
- note:
  - .

---
Agilelog:
- epic:

---
AssesmentLog
- pass: 
- merit:
- distinct:

SPRINT - Milestone: Agile Plan | Control

• Replace Milestone Id in link.
• Add Sprint Sequence Id in Title.
• Copy Sprint label per sprint.

Kind: Sprint Agile Kind: Activity | Sprint
Plan : Horizon Planning Horizon: 3 Weeks : 3 Weeks

Spint Backlog

Add Planned Issues Below

VIEWS: Replace Project ID in link,

• Project ID: (21): https://github.com/users/iPoetDev/projects/21

|
Backlog: Agile & Planner

• #.
• #.

Sprint Plan | Report

• Backlog:
  Backlog: Agile & Planner
• Epic: " The First Config " Repository, Project, Agile workflow setup, refinement, effort
  Kind: Epic
• Features:
  Kind: Feature
  • #12 Code Quality & Assurance (Code Standards, Formating)
• Stories:
  Kind: Story
  • As a developer, I want:
    • To assure code quality in my IDE and Whitespace correctness:
    • To assure code quality in my HTML format and lint correctness:
    • To assure code quality in my CSS format and lint correctness:
    • To assure code quality in my JavaScript format and lint correctness:
    • To validate code syntax in my HTML correctness using W3C Validator, but remembe to manually check as well
• Acceptance:
  Kind: Accept
  • Without code to test, I assert that the following configuration files are accepted:
    • .editorconfig:
    • .prettier - code formating
    • .htmlhint and separately w3c-html-validator
    • .stylelint + plugin: stylelinet-csstree-validator
    • eslint + sharable config: standardjs
    • standardjs
• Progress:
  • Plan: 8
  • Started: 8
  • Not Completed:
  • Completed: 8
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

FLOW:1st Run/Time GitHub API Get Request Workflow

Document: Tooling/Implementation Workflow

Idea

In the context of
I, as a developer, 
Need to establish the workflow and steps to take 
To make 1st time access request to my GitHub Account
And securely access the API with a Status 200 OK.

Next, I, as a developer, 
Need to establish the data schema I want to retrieve
So that I can make a model/ideal request pattern 
and to have expected response and payload based on the same expectation
And have a Status 200 Ok. 

Research

SOURCE: Co-Piloted and Generated by Perplexity.AI

Link:

• Write the User acceptance criteria for this idea, and user story (copied the effort into the prompt)
• [Give the above Stories and UAC/UAT, write a tutorial and a checklist (i.e. a how to) for using APIDog to authenticate with a specific user GitHub Account[(https://www.perplexity.ai/search/130fda77-0397-4d83-ac3f-a295ac752bc0?s=c)

Workflow

Follow these steps to build a checklist/recipe and how to, to

1 Access the iPoetDev Account

Story

As a API user, 
I want to access my iPoetDev GitHub Account by an 3rd party (APIDog) tool
so that I can test and mock the proper authentication and authorisation flow with Github.com.iPoetDev 

UAC/UAT

Given that I am an API user,
When I access my iPoetDev GitHub Account using the APIDog tool,
Then I should be able to successfully authenticate and authorize the access and receive a response with a Status 200 OK.

Checklist

• Register an OAuth App:
• Decide on Access Permissions
• Decide on Access Token Type
  • Personal Access Token
  • OAuth Access Token
• Obtain an Access Token
• Decide on which GitHub API to authenticate against.
• Authenticate with APIDog
• Test Authentication
  • Arrange different scenarios using different endpoints for authentication
  • Arrange different scenarios using different endpoints for authorisations
  • Act by Testing Authentication flow
  • Act by Testing Authorisation flow
• Mock Authentication
  • Assert by simulating different authentication scenarios.
  • Assert by simulating different authorisation scenarios

How to

TUTORIAL: Version 1 (AI Generated)

Tutorial: How to Authenticate with a Specific User GitHub Account using APIDog

Here is a step-by-step tutorial on how to authenticate with a specific user GitHub Account using APIDog:

• Noted: If API Dog can be authenticated, then my inference, so can a web app.
• This is the 1st integration test/proof of concept.

1. Register an OAuth App:
   Before you can authenticate with a specific user GitHub Account, you need to register an OAuth app. This will provide you with a Client ID and Client Secret that you will use for authentication.
   Follow the steps below:

   • Go to the GitHub Developer Settings page.
   • Click on "OAuth Apps" in the left sidebar.
   • Click on the "New OAuth App" button.
   • Fill out the required information for your app, including the Authorization callback URL.
   • Click on the "Register application" button.
   • Take note of the generated Client ID and Client Secret.
   • Keep the Client Secret secure and do not share it.

2. Obtain an Access Token:
   To authenticate with a specific user GitHub Account, you need to obtain an access token.
   There are different ways to obtain an access token, depending on your use case:

   • Personal Access Token:

     • If you want to use the GitHub REST API for personal use, you can create a personal access token.
       Follow the steps below:
       • Go to the GitHub Settings page.
       • Click on "Developer settings" in the left sidebar.
       • Click on "Personal access tokens".
       • Click on the "Generate new token" button.
       • Give your token a descriptive name and select the desired scopes.
       • Click on the "Generate token" button.
       • Take note of the generated personal access token. Treat it like a password and keep it secure.

   • OAuth App Access Token:

     • If you want to authenticate with a specific user GitHub Account using an OAuth app,
     • Can obtain an access token using the Client ID and Client Secret.
       Follow the steps below:
     • Make a POST request to the GitHub API endpoint https://github.com/login/oauth/access_token with the following parameters:
       • client_id: Your OAuth app's Client ID.
       • client_secret: Your OAuth app's Client Secret.
       • code: The authorization code obtained from the user's authentication process.
       • redirect_uri: The same Authorization callback URL used during app registration.
     • The API response will include an access token. Take note of the access token for further use.

3. Authenticate with APIDog:
   Now that you have obtained an access token, you can use APIDog to authenticate with a specific user GitHub Account. Follow the steps below:

   • Open APIDog and navigate to the authentication settings.
   • Choose the authentication method based on the type of access token you obtained:
     • If you obtained a personal access token, select "Personal Access Token" and enter the token.
     • If you obtained an OAuth app access token, select "OAuth App" and enter the access token.

4. Test and Mock Authentication:

• With APIDog authenticated with your specific user GitHub Account, you can now test and mock the authentication and authorization flow.
• Use the available endpoints and features in APIDog to simulate different scenarios and ensure the proper functioning of your authentication implementation.

USER STORY STATEMENT:

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY:

As a:
I/We want:
So That/Because:

Type of: Epic Task  |  Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

SPRINT # 5 - Milestone: EPIC #4: FEATURE: "Release: v0.5: Core Web App & User Accounts"

Issue: #63: [SPRINT] :: 05 [5 Days]: Release: v0.5: “Core + Accounts: C4 Models to Data Models: Logical Design & Structure”
Kind: Sprint Agile Kind: Activity | Sprint > Plan : Horizon Planning Horizon: 3 Weeks : 3 Weeks

• Week Start: 23-Aug-7
• Week End: 23-Aug-11 or 13

Sprint Objectives

• Conceptual Modelling: C4 Container to Component Diagrams
• Data (Physical) Modelling: ERD Diagrams and Component Dependencies
• Logical Modelling/Structure: Code and App definitions and Constraints
• First Run Activities for Django
  • First Django welcome page
  • First Admin Site
  • First User Profile Model
  • First Migration
  • Refinements and iterations
  • Initial Releasable Product
    • Local: v0.0.9

Additional

Push to following Sprint #64

• Initial Releasable Product: v0.1.0: Remote / Heroku ??
• First UI (barebones): Url, Forms and Templates ??
• First Social Account Integration (or move to Sprint 7?)

Spint Backlog

Add Planned Issues Below

VIEWS: Replace Project ID in link,

• [ ]

|

• #.
• #.

Sprint Plan | Report

• Define:

  • Core: #55
  • Accounts: #53

• Epic: " "
  Kind: Epic

  • CORE: Web App Singe Home Page: For Software Developers as GitHub Users ... Who want to review, report and do bulk activity on their GitHub Account; Our Dash and Do GitHub Manager website/web app Is a helpful website home page That provides home page for the service, useful in place (no reload) registration & login form, and offers integration with GitHub via social accounts As Well As an informative About & Contact [Page | Section] On a single web page.
  • ACCOUNTS: GitHub Integration: For new Developers who have GitHub accounts, who want to integrate their GitHub account and have this securely managed by OUR Dash & Do GitHub Manager as a helpful resource as a single pane of glass view that provides information and secures a social login with GitHub as an Identity provider, so it protects these next two following epics, and associated features (see below).

• Related Sprints

  • #63
  • #64
  • #65

• Features:
  Kind: Feature

  • CORE:
    • Home Page URL/Domain: Users can find and locate the web service using the URL/brand ID
      • Hero Section: Users can get an immediate impression about the brand Id of the web service
      • Hero Banner
      • Branding.
    • A Call to Action Form Section with
      • Registration Form: New User can start the registration via a form.
      • Login Form: Existing Users can login via form.
      • Password Reset Form: Existing User can reset their password via a form.
      • Password Reset confirmation popover/confirmation.
    • An Impressa Section
      • A Contact Form: Users can contact the web service owner and developer.
  • ACCOUNTS:
    • Register – Users can register and create a new profile
    • Login - Registered users can login using username and password
    • User Profile - Once logged in, users can create and update additional information such as avatar and bio in the profile page
    • Update Profile – Users can update their information such as username, email, password, avatar and bio
    • Remember me – Cookie Option, users don’t have to provide credentials every time they hit the site
    • Forgot Password – Users can easily retrieve their password if they forget it
    • Admin Panel – admin can CRUD users

• Stories:
  Kind: Story

  • #54
  • :

• Acceptance:
  Kind: Accept

  Summary: Short Form

  • Registration User Flow: Be able to register a use? UAT: Passing | UAT: Failing
  • Core Login User Flow: Be able to log in? UAT: Passing | UAT: Failing
  • Forgot Login User Flow: Be able to Reset Password? UAT: Passing | UAT: Failing
  • Session Management User Flow: Be able to stay logged in? UAT: Passing | UAT: Failing
  • Contact Form User Flow: Be able to send a contact message> UAT: Passing | UAT: Failing

• Progress:

  • Started:
  • Not Completed:
  • Completed:
  • Moved Next:

Sources

• https://zube.io/blog/agile-project-management-workflow-for-github-issues/

FLOW: Code Checks, Code Quality, Code Valid, Code Secrets

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

• Criteria:
• Complete? ❓✔

Repository

Project Root

- /dash-and-do-github
  - /.github
  - /docs
  - .gitleaksignore                                             # Optional ignore
  - CODEOWNERS                                                  # Common Standards Code & PR ownership
  - .editorconfig                                               # EditorConfig: IDE Code and Whitespace Quality
  - .gitignore                                                  # Git: Exclude Files to Remote & Secrets 
  - .eslintrc.js                                                # ESLint: JS Quality
  - .stylelintrc.json                                           # StyleLint: CSS Quality
  - package.json                                                # NPM: Dependencies Config
  - package.json.lock                                           # NPM: Packaging
  - README.md                                                   # Readme
  - .prettierignore                                             # Prettier: Ignore files
  - .gitleaks.toml                                                # Gitleaks config
  - pyproject.toml                                              # Python Libraries config, inc Ruff for Linting
  - .htmlhintrc                                                 # HTMLHint: HTML Quality
  - AUTHORS
  - CITATION
  - LICENSE                                                     # Licence
  - .pre-commit-config.yml                                      # Pre-commit Hooks
  - .prettier.yaml                                              # Prettier: Code Formatting

Flow

• Update the repo diagram
• Tag this repo in each relevant commit, => show up in the issue history
• Complete this before close as a final report

1. Linting:

Developer Experience, Code Quality, DX Tooling, IDE Integrations, CLI Checks

• Prettier - Code Style & Formating -> .prettierrc.yaml
• EditorConfig - IDE's Whitespace, Code Format/Style -> .editorconfig
• HTMLHint - HTML Correctness -> .htmlhintrc
• Stylelinerc - CSS Correctness -> stylelintrc.json
  • Dependencies: Shared Configs -> package.json
  • Uses pre-commits: See Issue | Doc:
• Eslint - JavaScript Correctness -> eslintrc.js
  • Dependencies: Shared Configs -> package.json
  • Uses pre-commits: See Issue | Doc:
• Ruff - Python Correctness -> pyproject.toml
  • Uses pre-commits
• GitIgnore - Secrets Filter & Exclusion -> .gitignore
  • Uses pre-commits: See Issue | Doc:

IDE Checks | Rules

Highlight Key Rules | Workflow

• IDE: Web Storm, PyCharm

1. Prettier:
2. EditorConfig

• Formats on Save,
• Checks on on Pre-commit

1. .
2. .

HTML Checks | Rules

Highlight Key Rules | Workflow

1. .
2. .

CSS Checks | Rules

Highlight Key Rules | Workflow

1. .
2. .

JavaScript | Rules

Highlight Key Rules | Workflow

1. .
2. .

Python | Rules

Highlight Key Rules | Workflow

1. .
2. .

Secrets | Rules

Highlight Key Rules | Workflow

1. .
2. .

Sources

Docs

• .

Guides

• .

USER STORY STATEMENT: As a 12 Factor App Developer, want a loosely coupled attachable Backing Service.

User Story | Epic's Task | Feature's Task|Story | Enabler Task

STORY: As a 12 Factor App Developer, want a Backing Service, i.e. a Relational Database, that is a loosely coupled attachable resource

In the Context of a Django Web App deployment with a backing service
As a: As a 12 Factor App Developer, 
I/We want: to handle the Backing service as an attached resource
that is accessed via a URL or other locator/credentials securely stored in the config.
So That: to deploy such a 12 Factor app, the backing service can be swapped out ... 
So That: As an attached resource be swapped without any changes to the Django app's code, 
In such a: way that indicated their loose coupling to the deploy they ate attached to. 
As such that these resources can be attached and detached from deploys at will.

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

FLOW: Static Assets into Production

Document: Developer Practice | Industry Practice | Developer Skills | Industry Conventions

CONFIGURATION: Production Checklist

List only Public | Well Known Configuration Steps

• Focus: Project Repository
• Focus: Build Integration
• Focus: Front-End Client
• Focus: Front-End Server
• Focus: Backing Services

Do not list harming or insecure confidential configurations that may pose a risk

• Production Check
  • PASSED Heroku-22 Stack
  • SKIPPED Eco Dynos:
    • No running dynos.
  • SKIPPED Dyno Redundancy:
    • No web processes.
  • SKIPPED Production Postgres Database:
    • No postgres database.
  • SKIPPED Postgres High Availability:
    • No postgres database.
  • FAILED App monitoring: Not using an app monitoring add-on.
    • Install a monitoring add-on such as
      • New Relic or
      • Librato to monitor your app's performance.
  • FAILED Log monitoring:
    • No logging add-on found.
    • Install a logging add-on to monitor and search your logs.
  • WARNING Custom Maintenance Pages.
    • Configure customized error and maintenance pages to match your app's branding.
  • SKIPPED Heroku SSL: Heroku SSL is not enabled.

[DEFINE](): Single Page Architecture: Dashboard: A single page, multi component, single pane of glass (SPOG) for GitHub Repository reporting and analytics.

PROJECT | SOLUTION: Concept | Idea Capture | Discovery | Document Driven Effort

• Ideation, Concept

• Research

• Agile Planning

  • ADR
  • Epic
  • Feature
  • Components
  • Stories
    • 🔢 Options
      • 👍🏽 Benefits
      • 👎🏽 Trade-Offs
      • ⛏️ Uses: Components
  • Acceptance
    • 🧪 Test Case:
    • 🎯 Test State:
  • Assessment

• Readme

  • Writing
  • Diagramming

• Proofing

• Editorial

• DEFINE document acts as internal Product/Feature/Component Definition Document and a statement of effort and Idea capture and specification.

Idea

Research

Sources

Agile Planning

ADR: Any Decision Records | Requirements

Epic

• `EPIC NAME:

Categorisation:

Related | Added Context

Related Epics

GitHub Integration:

Feature

• Feature

In Focus

• Home Page URL/Domain: Users can

Components

• [ ]

Stories

A Flow Label for the feature: Feature.

• Verify Registration User Story: As a ... I want to ... so that ... and ...
  • Option: Option Name:
    • 👍🏽 Benefit:
    • 👎🏽 Trade Off:
    • ⛏️ Uses:

      ---

A Flow Label for the feature: Feature.

• Verify Registration User Story: As a ... I want to ... so that ... and ...
  • Option: Option Name:
    • 👍🏽 Benefit:
    • 👎🏽 Trade Off:
    • ⛏️ Uses:

      ---

Acceptance

• User Criteria: Flow: In the scenario of .... , then the expected outcome for a ... and .... .
  • UA Test: As a user, I should be able to action/outcome on the Dash and Do GitHub web app.

    ---

• User Criteria: Flow: In the scenario of .... , then the expected outcome for a ... and .... .
  • UA Test: As a user, I should be able to action/outcome on the Dash and Do GitHub web app.

    ---

Assessment Criteria

Meets the following

Readme

• Header:
• Tags:
• Notes:

Proof

Grammar, Spelling, Diagram,

Editorial

• Include
• Edit

INDEX: List of Project Issues

INVENTORY:

DIRECT

Inventory | Workflows | Report

• #1 INDEX
• #2 FLOW
• #6 FLOW
• #12 FLOW
• #13 FLOW
• #14 FLOW, Deployment
• #19 FLOW, Architecture,
• #21 FLOW, Deployment, Configure
• #25 FLOW, Definition of Done, FINISHED Checklist
• #37 FLOW, Static Assets into Production
• #97 FLOW: UX to Django Template Design + TailwindCSS

DEFINE

Document | Readme

• #7 DEFINE: README
• #23 DEFINE: 15.0 DEPLOY: Review | Verify?
• #24 DEFINE: 12 Factor Methodology | Approach
• #32 DEFINE: Django End to End Build to Deploy Flow
• [?] #49 DEFINE: Inspect and Refine GitHub API | Revisit as Experience builds

REFINE

Agile Specifications & Requirements: From Idea to UAT

• #55 REFINE: CORE: App: Landing, Home, Sign Up Flows & Forms, SPA/MPA: Release Plan v0.5
• #53 REFINE: ACCOUNTS: App: User AAA Flows (Register, Login, Account): Release Plan: v.0.5
• #56 REFINE: DASH: App:
• #57 REFINE: DO (Tasker): App:

PLAN

Sprints | Plan | Flow | Report

• #3 SPRINT 1
• #4 SPRINT 2 / 3 (Two Weeks)
• #5 SPRINT 4
• #63 SPRINT 5
• #64 SPRINT 6
• #65 SPRINT 7
• 8
• 9
• 10

STORY

User Stories

Release: v0.5

• #81
• #82
• #54
• #66
• #67
• #68
• #69
• #70
• #71
• #83
• #84
• #85
• #73
• #74
• #75
• #76
• #77
• #78
• #79
• #80

Dev Stories

• #16 STORY, Code Standards
• #18 STORY, System Design
• #26 STORY, 12 Factor, (I) Codebase, Many Idempotent Deploys
• #27 STORY, 12 Factor, (II) Dependencies, Python 3.11
• #28 STORY, 12 Factor, (II) Dependencies, JavaScript/NodeJS 20.0
• #29 STORY, 12 Factor, (III) Backing Services, i.e. Relational Database
• #30 STORY, 12 Factor, (IV) Config, Environmental Variables, Connection Strings, Credentials/Secrets, Canonical Values
• #31 STORY, 12 Factor, XII), Admin Tasks, Django migrations, and manage scripts

FEATURES

• #98
• #99
• #100
• #101
• #102
• #103
• #104

DESIGN

BUILD

Fix

TEST

CHECK

• #20 CHECKLIST, Heroku Production

DEPLOY

USER STORY STATEMENT: As a 12 Factor App Developer, I must have one Codebase & many Deploys.

Developers (User) Story

STORY: As a 12 Factor App Developer, I must have one Codebase, that is tracked in revision control, with many deploys so that I can develop, test and run separate instances.

In the context of: The 12 Factor App methodology ...
As a: As a 12 Factor App Developer ...
We want: To have one `Codebase`, ...
That is: Tracked in revision control, ...
With many `deploys` 
i) So That: we can develop, test and run separate instances.
In Order to incrementally iterate, assure and deploy 
.... Different releasable versions to align with a Agile driven sprint methodology

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

USER STORY STATEMENT: As a 12 Factor App Developer, I need to run Admin Process (XII) tasks as one-off processes.

User Story | Enabler Task

STORY: As a 12 Factor App Developer, I need to run Admin Process (XII) tasks as once-off (standalone) processes in an identical environment as the regular long-running processes of the app so that these tasks can be run against the same release, using the same codebase, dependency isolation and config of that release.

In the Context of: 
  - Running administration scripts or management tasks in the same environment as the app runtime
As a: As a 12 Factor App Developer
I/We want: I need to run admin/management process tasks as once-off (standalone) processes
In the/an: identical environment as the regular long-running processes of the app, i.e. the `release`.
And: preferablly use a REPL shell environment that ships with the technologies involved.
Because: these tasks must  
  i) run against a release (V)
 ii) use the same codebase (I) .. run against that release (V)
iii) use the same config (III) .. run against that release (V)
iv) align with dependency isolotion (II) of the release
 v) across same deployed process types (VI)
vi) for once off scripts be easy to run in REPL shells.

Type of: Enabler Task

_{Copy to Readme} | _{Source: https://www.gla.ac.uk/media/Media_730149_smxx.pdf}

Defintion: Process Formation

The array of processes that are used to do the app’s regular business (such as handling web requests) as it runs.
i.e.:

• Running database migrations (e.g. manage.py migrate in Django)
• Running a console (also known as a REPL shell) to
  i) Run arbitrary code or
  ii) inspect the app’s models against the live database.
• Running one-time scripts committed into the app’s repo

Acceptance Criteria: Running Database Migration

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?

Acceptance Criteria:

• Link: UAC-000?
• Status: Proposed | Prepared | Pending | Tested | Accepted | Rejected | Superseded | Reverted
• Definition of Done: Pending | Complete

Given:
When:
Then:

Related

ADR-000? || EPIC-000? || FEATURE-000?