-
Notifications
You must be signed in to change notification settings - Fork 4
Extensions & Reusability
This platform is open source and the code can be reused in the correct situations. What should be kept in mind is the General Pipeline and the Configuration points. Given that we are a custom application, it should be easy for us to add / disable pieces for forked versions of the app, or add / remove steps in the General Pipeline. The better long-term solution will be to move core pieces into engines, and have configurations that can be assembled piecemeal for different applications.
User selects an address
User selects a permit type (that is enabled for that jurisdiction)
This drives the right requirement form
The requirement form has logic to add requirements based on different conditions
The requirement form has has logic pull data from other sources (Automated Compliance)
The requirement form has customizations per jurisdiction
Multiple collaborators can work on the form
The form is submitted
Reviewers can comment on revisions to be made and send them back to the user to address before accepting it
On acceptance, API calls are made to push the application to other systems
Permit Types (A combination of work & density)
RequirementTemplates are configured per permit type
Jurisdictions have
customizable info page
customizable energy step code settings
individual ability to administer reviewers / review managers
customizable API settings for data export
RequirementsTemplate Customization occurs per permit type and per jurisdiction
The goal of the reuse cases below is to explore what may be possible in re-imagining how to re-purpose or extend the current platform. Note that for some of the use cases it would be helpful if there is a backend resource well-versed in Ruby on Rails to get very productive customizations.
The initial details here are some assumptions made based on what we currently know about the Permit Connect program, but clarification with Shane Mantle would be best to know relevancy.
There could be two ways permit connect could re-use the work done by building permit:
We could simply modify the current system to kick off a connection to the PermitConnect BC.
We could create a second instance of the system customized for housing navigators to use and have the current system kick off a connection into the other system. What may be good with this approach is that it will help even the housing navigators systemize and track progress. They can also segment their reviews into its own tracks.
Proposed pipeline
At the submission of permit. Depending on the area and the nature of the house, determine if certain provincial permits are required (example: is it close to a highway, etc.)
Submission can trigger an assignment of a housing navigator if conditions are met where . This can be handled via an e-mail to PermitConnectBC OR an API call to another system.
On revision, potentially housing navigators could be reviewers for certain items.
Configuration point changes
UPDATE: Either a contact inbox for PermitConnect or an ability to have an API call to insert a request / get started on provincial permits.
Code customization changes
NEW: add automated compliance for identifying provincial permit conditions
NEW: add logic to decide when provincial permits apply
For now we will describe the PermitConnect instance of the system to be PermitConnect Hub to distinguish it from the building permit system.
The PermitConnect Hub is configured with ways to determine the different types of permits that may be required.
At the submission of permit. Depending on the area and the nature of the house, it can call the PermitConnect Hub to determine what is required.
Upon submission from the building permit system, the PermitConnect Hub receives and kicks off an application if it is determined that at least one permit is required from the provincial level.
Auto compliance functionality fills in all data base don fields from the building permit system. If it’s complete it submits it, if ti is not it will let the builder know it’s not complete.
Builder submits details for provincial permits.
Reviewers can review information relevant to their permit types and send feedback.
Upon submission from user, it kicks off an API to send the information to the right government system.
UPDATE : update to either one permit type for all permits OR track each permit required as a separate application.
UPDATE: set up requirement blocks for provincial permits
UPDATE: Main page content configuration
UPDATE: Help Setup
UPDATE ON BUILDING PERMIT SYSTEM: Create a webhook against the PermitConnect Hub and vice versa to get updates from each other
NEW: add automated compliance for identifying provincial permit conditions
NEW: add logic to decide when provincial permits apply
NEW: add ability to configure provincial permits
NEW: each provincial permit knows the conditions in which it needs to be triggered by automation. If it is not, the housing navigator can update the details.
UPDATE: Api outputs should not be based on jurisdiction, but instead based on the provincial permits triggered
REMOVE/DISABLE: jurisdiction info pages are not required.
UPDATE: reviewers / review managers are not linked to jurisdictions, they are the housing navigator team
The following details are assumptions based on discussions with Brett Auger on what they require. The key terminology is that they are not applying for Permits, but instead filling an Application for grants/credits/rebates. Some key business details:
Reviewers are an external contracting firm
Regions drive which credits/rebates are available
Some cities can also have individual rebates and there are different provincial / federal ones that apply to different regions
A user applying for energy savings picks the address of their house
Through the selection of an address it pulls out a form for you to fill in key details.
After filling in the key details a submission is made.
Potentially upon completion, it can infer which applications you qualify for already.
A review is done by the Energy Savings approval team.
Revisions required can be sent back to the user.
Upon completion, the application wil generate ‘applications’ against different services at local, provincial, or federal level.
UPDATE: no concept of permit per jurisdiction, there is only one requirement form
UPDATE: you want a different set of requirement blocks for these savings.
NEW: configure rebates in the system, this includes what qualification criteria is for rebates.
UPDATE: Main page content configuration
UPDATE: Help Setup
UPDATE: 1 template type instead of many permit types.
UPDATE: workflow for location selector does not require picking a permit type.
NEW: concepts of regions needs to be added.
NEW: concept of a Rebate (or similar) object is created. These need to be modified by the super admin.
NEW: Each Rebate has an info page, like the current jurisdiction info pages.
NEW: Each rebate can be configured to apply to different regions or local jurisdictions
NEW: Each rebate knows which requirement blocks are relevant to it.
UPDATE: reviewers / review managers are not linked to jurisdictions, they are external teams of reviewers
REMOVE/DISABLE: jurisdiction info pages are not required.
NEW: Add automated compliance service to extract data from BC SERVICES CARD after login
UPDATE: API should be driven on a per rebate basis → kick off the process to either mail somebody or start another process. If there is some way to know the status, even better. We can reutilize the mapper so the right fields are mapped to another system.
UPDATE: Instead of downloading just a completed application, it should do that as well as have the number of rebates they qualify for.
REMOVE/DISABLE: collaborators, this is not required.
UPDATE: Ui for administration of Rebates and regions