[Feature] Project Definition

[amenity]

As a Project Team Member, I want to create a new project so that I can track this work through the Mobility Project Database.

In-scope:

• Multi-step process involving inputting project details (name, description, etc.), identifying a project owner and associated staff, and mapping a project's geometry.
• Required fields

Out-of-scope:

• Templating features that may dictate "New Project" requirements (e.g. identifying what fields are required for a new project to be entered or not)
• Mapping specific geometries tied to implementation (i.e. facility or component geometries)

Resources:

• Wireframe

Data Model: Brackets = relational data source Parentheses = additional context/questions Asterisks = required field for entry

Main entity: moped_project Data to display:

• *Project Name
• *Project Description
• Start Date (default to current date? May not be necessary to show)
• *Fiscal Year (auto-fill with current FY)
• Current Status [moped_project.current_status > moped_status.status_name]
• Current Phase [moped_project.current_phase > moped_phases.phase_name]
• Project Priority [moped_project.project_importance > moped_priority.priority_level]
• CIP?
• eCapris ID (if it is a CIP — required)

Additional Notes:

[amenity]

Notes from 8/25 Sprint Review:

• Project names are very messy; standardization could be powerful
• At the same time, projects are named by all sorts of entities and we don't have the authority to change the name
• This is especially important when it comes to reporting (didn't catch the precise reason why 🙃 )...

[zappfyllc]

@leslie is researching React Hook Form and will prototype this form. We can add to Kickstand but think it's a good starting place for any UI code.

[amenity]

@zappfyllc Setting up React Hook Form for the prototype sounds great. Just want to note that we haven't yet determined whether the "New Project" process belongs in a wizard or not. 🧙‍♀️ ✨

[zappfyllc]

• [x] Wireframes (are we deciding that this blocks any work below?)
• [x] Database work (creating tables, columns, triggers, relationships, etc.)
• [ ] GraphQL work (queries, mutations, etc.)
• [ ] React work (React Hook Form, MaterialUI)
• [ ] Kickstand tie-in? (How do we handle this? Can we have someone responsible for moving what appear to be reusable components to Kickstand and then updating Moped code to import and “re-use” those components), don't let Storybook inhibit development
• [ ] Additional API work (external APIs, anything stored not in Hasura-instantiated Postgres
• [ ] Miscellaneous Technical Issues