Merge pull request #237 from nsidc/spelling

Spelling fixes

.pre-commit-config.yaml

@@ -13,11 +13,21 @@ repos:
     rev: "v4.4.0"
     hooks:
       - id: "check-added-large-files"
+      - id: "check-case-conflict"
+      - id: "check-executables-have-shebangs"
+      - id: "check-shebang-scripts-are-executable"
+      - id: "check-merge-conflict"
+      - id: "check-symlinks"
+      - id: "destroyed-symlinks"
       - id: "check-vcs-permalinks"
+      - id: "check-json"
+      - id: "check-toml"
       - id: "check-yaml"
         # Without --unsafe, !reset in compose YAML triggers error
         args: ["--unsafe"]
       - id: "end-of-file-fixer"
+      - id: "mixed-line-ending"
+      - id: "trailing-whitespace"
 
   - repo: "https://github.com/astral-sh/ruff-pre-commit"
     rev: "v0.1.7"
@@ -48,6 +58,12 @@ repos:
         args:
           - "--verbose"
 
+  - repo: "https://github.com/codespell-project/codespell"
+    rev: "v2.2.4"
+    hooks:
+      - id: "codespell"
+        exclude: ".codespellignore"
+
   #  TODO: Enable vulture
   # - repo: "https://github.com/jendrikseipp/vulture"
   #   rev: "v2.7"

CHANGELOG.md

@@ -45,7 +45,7 @@
 * Add sankey diagram display to survey page
 
 
-### Login user experience enhancements 
+### Login user experience enhancements
 
 * Display banner when not logged in.
 * New login page with button to let user know we're using Google SSO.
@@ -129,13 +129,13 @@
 
 ## v0.4.0 (2023-09-13)
 
-* Stop using current_user and use true value for created_by on surveys page 
+* Stop using current_user and use true value for created_by on surveys page
 * Display version on webapp
-* Combine common response object database fields 
-* Show respondents on survey page 
+* Combine common response object database fields
+* Show respondents on survey page
 * Install bootstrap and update UI
-* Update response link to be clickable 
-* Implement X-forwarded-proxy 
+* Update response link to be clickable
+* Implement X-forwarded-proxy
 
 
 ## v0.3.0 (2023-08-17)
@@ -153,7 +153,7 @@
 
 * Create user list view
 * Allow role changes by admin
-* Add analyst and respondent roles 
+* Add analyst and respondent roles
 * Redirect to homepage after login
 * Alter views based on roles
 

compose.dev.yml

@@ -56,9 +56,8 @@ services:
       # USAON_BENEFIT_TOOL_GOOGLE_CLIENT_ID: "${USAON_BENEFIT_TOOL_GOOGLE_CLIENT_ID:?USAON_BENEFIT_TOOL_GOOGLE_CLIENT_ID must be set}"
       # USAON_BENEFIT_TOOL_GOOGLE_CLIENT_SECRET: "${USAON_BENEFIT_TOOL_GOOGLE_CLIENT_SECRET:?USAON_BENEFIT_TOOL_GOOGLE_CLIENT_SECRET must be set}"
 
-      # Allow http in dev; TODO: Do we need this? Why? Login is
-      # disabled in dev. Maybe as a fallback for actually testing
-      # login behavior?
+      # Allow http when doing OAuth in dev; useful if testing login behavior!
+      # Alternately, pass `--cert=adhoc` to the flask dev server :)
       #     https://flask-dance.readthedocs.io/en/v0.8.0/quickstarts/google.html#code
       # OAUTHLIB_INSECURE_TRANSPORT: "1"
     secrets: !reset []
@@ -71,7 +70,7 @@ services:
     depends_on:
       db-volume-prep:
         condition: "service_completed_successfully"
-    image: *db-image 
+    image: *db-image
     container_name: "usaon-benefit-tool-db"
     command: ["postgres", "-c", "log_statement=none"]
     volumes:
@@ -86,7 +85,7 @@ services:
     # Ensure database volume directories have the correct permissions before
     # starting the database
     entrypoint: ["sh", "-c", 'mkdir -p /data/postgresql && chown -R dbuser:dbuser /data/postgresql']
-    volumes: 
+    volumes:
       - "./_db:/data:rw"
 
   adminer:

doc/how-to/development.md

@@ -22,7 +22,7 @@ export USAON_BENEFIT_TOOL_DB_PASSWORD=...
 ```
 
 > :memo: these can be put in a `.env` file so that all variables are assigned. This file
-> is part of `.gitignore` so that no secrets are committed to github. 
+> is part of `.gitignore` so that no secrets are committed to github.
 
 ### Start the service
 

doc/reference/data_model.md

@@ -5,7 +5,7 @@ erDiagram
 survey {
     uuid id PK
     int response_id FK
-    str title 
+    str title
     str created_by FK
     datetime created_timestamp
     str notes "nullable"
@@ -80,7 +80,7 @@ response_observing_system_data_product {
 response_data_product {
     int id PK
     int response_id FK
-    
+
     str name
     int satisfaction_rating "0-100"
 }

doc/reference/glossary.md

@@ -1,6 +1,6 @@
 # Glossary
 
-* `Survey`: A solicitation for input from a `Respondent`. 
+* `Survey`: A solicitation for input from a `Respondent`.
 * `Response`: A completed or in progress response to a survey. A survey has exactly one response.
 * `Library`: The collection of all `responses`.
 * `Registry`: The collection of available `survey objects` for use in `responses`.
@@ -21,13 +21,13 @@ support `analysis` and also to ease data entry for `Respondents`, over time.
 
 `Respondents` may add new `applications`, `data products`, and `observing systems` to the `registry`.
 
-There is a generic `Registered Survey Object` structure that applies to Applications, 
-Data Product, and Observing Systems. There is a separate structure to register 
+There is a generic `Registered Survey Object` structure that applies to Applications,
+Data Product, and Observing Systems. There is a separate structure to register
 `Societal Benefit Area objects`.
 
 Ongoing efforts are being made to align this data structure with best practices and partner organization
-structures (e.g. Polar Observing Assets working group, Arctic Data Center, Federated 
-Search crew) with the goal to be able to import or sync items in the registry 
+structures (e.g. Polar Observing Assets working group, Arctic Data Center, Federated
+Search crew) with the goal to be able to import or sync items in the registry
 from an external source.
 
 
@@ -36,7 +36,7 @@ from an external source.
 * `Object Type`: Type of Object - `Observing System`, `Data Product`, or `Application`.
    (_Multiplicity: 1..1; Format: Pick from Observing System, Data Product, or Application_)
 * `Short Name`: Short name/description of the object, which would be displayed in the analysis to save space.
-   Preferably in the format [Organization acronym] [name], e.g. USGS Streamgage Network.
+   Preferably in the format [Organization acronym] [name], e.g. USGS stream gauge network.
    (_Multiplicity: 1..1; Format: Text_)
 * `Full Name`: Full name of the object. In the case where the full name is brief, this may be the same as the `short name`.
    Preferably in the format [Organization acronym] [name], e.g. USGS Groundwater and Streamflow Information Program.
@@ -57,12 +57,13 @@ from an external source.
 * `Contact Email`: The email address for a point of contact for the object. (_Multiplicity: 0..1; Format: Email_)
 * `Tags`: Please add three or more tags to indicate thematic- or geographic- information about this object to
   aid in analysis and discovery. (_Multiplicity: 0..n; Format: Text_)
-   * This is a user-defined field that admins can and will edit. It creates additional flexibility in 
-  the analyis, for example allowing for a regionally- or thematically-focused `analysis`.
-   * For the early phase of this tool, the description above encourages users to include multiple tags, but the 
-    software does not require it.
+   * This is a user-defined field that admins can and will edit. It creates additional
+     flexibility in the analysis, for example allowing for a regionally- or
+     thematically-focused `analysis`.
+   * For the early phase of this tool, the description above encourages users to include
+     multiple tags, but the software does not require it.
 * `Version`: Match the version identification system used by the observing system, data product, or application managers.
-   This field allows the `analyses` to reflect change over time. 
+   This field allows the `analyses` to reflect change over time.
    (_Multiplicity: 0..n; Format: Text_)
 * `Persistent Identifier`: A standard way to refer back to the object's source, usually a DOI
    (_Multiplicity: 0..n; Format: Text_)
@@ -83,19 +84,19 @@ from an external source.
 
   _NOTE_ We intend to do `current state` and `desired state` `analyses`. In a `desired state`
   `analysis`, the `real` field allows us to `desired state` (hypothetical) objects. For instance,
-  the USGS stream gage network if funding increased and there were X number of additional gages.
+  the USGS stream gauge network if funding increased and there were X number of additional gauges.
   This allows us to trace the impact of changes on the entire network. Related to the survey `type`.
 
 
 ## Rated Instance of an Object
 
-The rating answers two questions - how important is a particular `Observing System`, 
-`Data Product`, or `Application` and how well does it perform. It is reflected in the 
-`analysis` by the thickness and color of the link connecting two `survey objects`. For 
-instance: Imagine a satelite (`observing system`) that is very important to a sea ice 
-`data product` but performs poorly because of persistent Arctic cloud cover and high 
-latency (`gaps`. Those would be linked by a thick (high `criticality`) red (low 
-`performance`) line. 
+The rating answers two questions - how important is a particular `Observing System`,
+`Data Product`, or `Application` and how well does it perform. It is reflected in the
+`analysis` by the thickness and color of the link connecting two `survey objects`. For
+instance: Imagine a satellite (`observing system`) that is very important to a sea ice
+`data product` but performs poorly because of persistent Arctic cloud cover and high
+latency (`gaps`. Those would be linked by a thick (high `criticality`) red (low
+`performance`) line.
 
 
 ```mermaid
@@ -115,43 +116,43 @@ pertain to rated instances, _not_ `registry` definitions.
 * `Link`: Defines which `survey objects` are connected. The rating is applied to that `link`.
 * `Criticality rating`: 0-10 rating of the criticality of an input to an output,
   e.g. criticality of an `observing system` to a `data product`. This answers the question:
-  On a scale of 1-10, how much would the loss of this input impact the performance of your 
+  On a scale of 1-10, how much would the loss of this input impact the performance of your
   `data product` or `application` (1 - very little impact; 10 - complete loss of performance).
 * `Criticality rationale`: Text description answering the question: What accounts for this
    criticality rating? If there is a close equivalent product, why do you prefer this one?
-* `Performance rating`: 0-100 rating of the performance of the subject. Answers the question: 
+* `Performance rating`: 0-100 rating of the performance of the subject. Answers the question:
    What is your satisfaction with this input? (0=No performance, 100 = perfect)
 * `Performance rationale`: Text description answering the question: What accounts for this
    performance rating? Include any journal articles, statements or contextual observations
    that might help us to understand your rating.
 * `Gaps`: If the rating is less than "ideal" what improvements are needed.
 * `Variable or Attribute`: If an `observing system` or `data product` contains many
   observable properties or variables, this allows a `respondent` to specify
-  which field they used. 
+  which field they used.
 * `Rated by`: Link to the `respondent` who provided this rating.
 
-The `node color` of an `observing system` or a `data product` is defined in this 
+The `node color` of an `observing system` or a `data product` is defined in this
 document: https://docs.google.com/presentation/d/1RmEGcPkC3_9o3qeAndv0QvAcdZwFIHC-/edit#slide=id.g1e651286dde_0_54
 The `node color` of an `application` is rated separately based on the application performance
-compared to the `application performance criteria`. 
+compared to the `application performance criteria`.
 
-While only a  small number of respondents will provide responses on `Observing Systems` through 
-`Applications`, a larger number of respondents (up to ~20)  will evaluate the relationships between 
+While only a  small number of respondents will provide responses on `Observing Systems` through
+`Applications`, a larger number of respondents (up to ~20)  will evaluate the relationships between
 `Applications` and `Societal Benefit Areas`. For now, we expect users to follow instructions, but
-eventually, we may want to apply restrictions so that the right people can only fill out the right 
+eventually, we may want to apply restrictions so that the right people can only fill out the right
 parts.
 
 
 ## Surveys
 
 * `ID`: Computer generated identifier
 * `Title`: Unique name of survey
-* `Description`: Narrative description of the survey topic 
-* `Tags`: This is a user-defined field that admins can and will edit. It creates additional flexibility in 
-  the analyis, for example allowing for a regionally- or thematically-focused `analysis`.
+* `Description`: Narrative description of the survey topic
+* `Tags`: This is a user-defined field that admins can and will edit. It creates additional flexibility in
+  the analysis, for example allowing for a regionally- or thematically-focused `analysis`.
 * `Respondents`: List of `respondents` with edit-access
 * `Description`: Narrative description of the survey topic; may be displayed as a prompt
-  to the user. 
+  to the user.
 * `Status`: WIP, Published, Closed, Archived? Should we have dedicated date fields, e.g.
   `opened_date`, `published_date`, etc.
 ```mermaid
@@ -176,9 +177,9 @@ flowchart LR
 ```
 * `Private`: Can this survey be viewed by non-registered members? (Or should it be
   restricted to individuals?)
-  
+
 #### Fields not yet supported / need to discuss more:
-* `Year`: Allows for repeated analyses to show change over time - (We currently have 
+* `Year`: Allows for repeated analyses to show change over time - (We currently have
 `created_timestamp` field which can show when it was originally created. Year seems too wide?)
 * `Type`: Surveys could be requesting information about the current state or desired
   state of `response objects`. For "desired state" surveys, we wouldn't be interested in
@@ -187,9 +188,9 @@ flowchart LR
 
 While most `surveys` will link observing systems, data products, applications, and societal benefit
 areas, some may simply allow for a data manager to link the `data product` to `observing systems`
-without any related `application`. Additionally, a group of up to ~20 `respondents` known as a 
-`societal benefit cohort` may provide ratings on how  1-3 specific `SBAs` relate to the 
-`application`. 
+without any related `application`. Additionally, a group of up to ~20 `respondents` known as a
+`societal benefit cohort` may provide ratings on how  1-3 specific `SBAs` relate to the
+`application`.
 
 
 
@@ -253,9 +254,9 @@ Fields/relationships:
 
 A user who is invited to register to provide a `response` to a `survey`. Admins will
 assign Surveys to Experts. Experts can contribute to multiple Surveys; Surveys can have
-many Experts. 
+many Experts.
 
-Experts may add new `applications`, `data products`, and `observing systems` to the 
+Experts may add new `applications`, `data products`, and `observing systems` to the
 `registry`, or may select existing `objects`.
 
 Fields/relationships:
@@ -304,7 +305,7 @@ Fields/relationships:
 * `Name`: Unique
 * `Description`
 * `Expert(s)`: Members of cohort
- 
+
 
 ## Analysis views
 

doc/tutorial/edit-app-markdown.md

@@ -18,7 +18,7 @@ Markdown previews!
 
 Markdown exists in two places for this app:
 
-1. In the documentation: This documetation is separate from the Benefit Tool
+1. In the documentation: This documentation is separate from the Benefit Tool
    application, mainly for use by developers and project managers.
    * Lives in
      [the `doc/` directory](https://github.com/nsidc/usaon-benefit-tool/tree/main/doc).
@@ -183,7 +183,7 @@ Double-check the "base" branch is set correctly. Usually, you want it to be `mai
 in my case I created my branch from another branch called
 `hazelshapiro-docs-addtutorial`.
 
-Enter a meaningfull Pull Request title, for example "Add new tutorial about contributing
+Enter a meaningful Pull Request title, for example "Add new tutorial about contributing
 documentation with GitHub.dev".
 
 Enter a useful description, for example discussing why you made the decisions you made

usaon_benefit_tool/constants/sba.py

@@ -75,7 +75,7 @@
             ' and ecosystem function',
             'Improve the understanding and function of habitats in the Arctic',
             'Improve understanding of the value proposition of ecosystem'
-            ' sevices in the Arctic',
+            ' services in the Arctic',
             'Maintain ecosystem quality, diversity, and extent to ensure the'
             ' delivery of ecosystem functions and services',
         ],
@@ -85,7 +85,7 @@
             'Enhance resilience to changes in Arctic climate and ecosystems'
             ' that affect access to food',
             'Ensure continued access to and viability of hunting, fishing,'
-            ' and gathering activ ities in the Arctic',
+            ' and gathering active ities in the Arctic',
             'Improve stewardship of fisheries and animal stocks in an'
             ' environmentally sustainable manner',
             'Improve understanding of land use on sustainable stewardship'
@@ -164,7 +164,7 @@
         ],
         'Public Health': [
             'Ensure access to health care and health promotion services',
-            'Improves acces to clean water and sanitation infastructure',
+            'Improves access to clean water and sanitation infastructure',
             'Improve early warning systems for impending public health emergencies',
             'Improve synthesis of health- and environmental health-related'
             ' knowledge across Arctic cultures',
@@ -312,7 +312,7 @@
             ' for Arctic resources',
             'Improve understanding of socioeconomic systems that impact the Arctic',
             'Improve understanding of the cryospheric and environmental'
-            ' processess in the Arctic on socioeconomic systems',
+            ' processes in the Arctic on socioeconomic systems',
         ],
     },
     'Terrestrial and Freshwater Ecosystems and Processes': {

usaon_benefit_tool/models/tables.py

@@ -64,7 +64,7 @@ def __io__(cls) -> IORelationship:
 
 
 class ResponseObjectFieldMixin:
-    """Provide shared fields between all relationship objects to reduce repition."""
+    """Provide shared fields between all relationship objects to reduce repetition."""
 
     short_name = Column(String(256), nullable=False)
     full_name = Column(String(256), nullable=True)

usaon_benefit_tool/routes/survey/relationships/observing_system_data_product.py

@@ -251,7 +251,7 @@ def delete_response_observing_system_data_product_relationship(
     )
     db.session.delete(response_observing_system_data_product)
     db.session.commit()
-    # TODO: figure out why this isnt working
+    # TODO: figure out why this isn't working
     # flash('You have deleted this relationship')
 
     return redirect(