Read.me

Program runs on multiple containers using podman-dockercompose files and instances

Here is the application structure
p00003 (venv)
	-p00003django
		-DockerFile
		-.entrypoint.sh
		-JenkinsFile
		-main (app1 - projects)
		-accounts (app2 - apis for authentication and authorization)
		-project_management
		-requirements.txt
		-manage.py
	-p00003remix
		-DockerFile
		-JenkinsFile
		-requirements.txt
		-.entrypoint.sh
	-podman-compose.yml (provides hashicorp p00003vault, p00003postgres, p00003pgadmin, p00003couchDB, p00003nginx, p00003django (depends on p00003postgres_), and p00003remix (depends on p00003couchDB))


Data is persisted in NFS file structure to be provided. 

Program is wrapped with nginx static pages with reflex components embeded in it.


Application requires an email which will require confirmation through sending and confirming email. Once email is confirmed certificates and tokens will be generated and sent to safekeep to the first registered user. This user is also given full admin access to the application environment. I don't know how hashicorp works but there needs to be a possibility to regenerate the tokens they are misplaced or forgotten. But with each regeneration there needs to be an id that can't be changed so administrator knows that it was done. 



Django main application and apis it serves:
Djano main application is the user directory, project directory, and RBAC definitions directory.
First time admin login to the django application default landing page is the program configuration page which has following required fields to complete:
 -Company Name (only one company can exist but subsidieries can be created - 256 characters maximum)
 -First subsidiary name (organization unit responsible for administring the program - 256 characters maximum)
 -Three letter for initial subsidiary
 -Contact email address for issues (must have proper email form) which will be the email that will receive the login certificate for admin user
 -email address for registration (which replaces the default noone@nowhere.net - must have proper email form) 
 -Address NFS server (test button to make sure program can create a test folder, create a file in test folder, delete test file, and delete test folder. Test must be done with success at least once for submit button to become usuable - until that it should be grayed out)
submit button will submit the form. Once form is submitted following will happen:
 -Login for django environment will become certificate based
 -Will replace default registration email with one submitted in the nginx landing page
 -Will create initial database in postgresql for the subsidiary with three letter provided
 -Will set admin with certificate as default postgresql database administrator (this certificate will be used to exchange data with other containers)
 -Will create initial couchdb database for subsidieary and default project
 -Will set admin with certificate as couchdb default administrator (this certificate will be used to exhange data with other containers)
 -Initial landing page will switch to project dashboard displaying default project which will have project number made of three letters submitted and 0000001. For example if ABC is the three letter submitted project number will be ABC-0000001. More details on initial projects later.
 -Will apply initial project template to the django database (more on project templates later)
What users can see on the landing page will be based on their role but admin user can see and modify everything.
Clicking on the project will open a new web page served by nginx but uses nodejs container. This is project landing page. What can be done in project will be done through this react application which will use couchdb to manage its data.

Here is what project page will have:
It is a progressive web application page. It contains all the work packages. How work packages relate to each other is defined through template. 
Web application uses graphql to get all the data it needs from postgresql and couchdb. 
By default it contains all the work packages that come from default template. Template uses hashtaged object pairs with relation between them in curly braket.
Default template contains following lines at the start for subsidiary defined with letters ABC:
Vertices:
#WP0000001 {childof} #ABC0000001 
#T0000001 {childof} #WP0000001
#T0000002 {childof} #T0000001
#T0000002 {end-before-start} #T0000001
#T0000001-TaskName {field-of} #T0000001
#WP0000001-WorkPackageName {field-of} #WP0000001
List of relations:
{childof}
{depends-on}
{end-before-start}
{end-after-start}
{field-of}

CouchDB will store different fields which can accept pre-defined type of data for each hashtaged object. When defining a hashtag object user will be asked to provide type of data it should be. By default character. Provide pull down list of any type of data Couchdb can store that can be captured through the intake form.
All default initial hashtaged objects are CHAR type.
List of Vertices and list of relations are stored in CouchDB database for the project. List of relations is editable. Nodes for vertices are created through work package manager react application.
work package manager also is responsible for creating vertices. But nodes and relation they will use between two nodes must exist before use. That is vertice builder need to rely on existing searchable data.

Hashtaged objects need to be unique and they are not case sensitive.

Another react application shows the graph view based on vertices one or more relations (use filter to apply which relations to use to graph). Do not show unlinked nodes.