Fix unit type with a suffix on create/edit of a unit

[huss]

Description

Summary

The desired behavior is:

When a site/admin adds a suffix unit, it will be a unit of of type unit with the desired suffix. When OED adds units based on a unit added by the site/admin, it will be of type suffix with a blank suffix.

It seems issue #1019 was wrong by restricting units to have a type of suffix if they have a suffix. This should be allowed and required.

Actions taken

Changes:

• The code from PR Fixes to suffix type when creating or editing units. #1040 that implemented issue Units of type suffix should have a suffix #1019 needed to be revised so sites/admins inputted units can have a suffix and type unit. It is unclear it should ever be of type meter so that will not be allowed.
• It is an open question if one should be allowed to make it of type suffix. If it is allowed then it would also need to be displayable and that is currently blocked by the UI. It seems a site really should use the standard mechanism to create the unit with type unit and a suffix and have OED create the actual suffix unit during its processing. Given all of this, OED will not allow this until someone comes up with a good usage since it would probably be a mistake in usage. If it is ever done then it needs to have warnings on the UI pages.

Overall this means the unit UI has been modified to enforce that the type is unit and not suffix when there is a suffix for a unit. This addresses both items above.

Information found

The above information/actions are based on information found and analysis of that information. What follows is that information in greater detail to preserve the record and to explain what is above.

Design doc

• The OED design doc on resource generalization has:
  • "suffix. Are units created by OED as part of analyzing suffix units (such as CO2)" for one of the three types of OED units.
  • The examples with kg CO2 has it with a suffix of CO2 and type of unit. The table of final units shows the suffix type for the added units but there is no suffix ('').
  • It states: "Note a type_of_unit of suffix is different than a unit with a suffix string.". The OED creation of the suffix unit based on the site creating a unit with a suffix has the pseudocode new Unit(... Unit.type.suffix, "", showing the type of suffix with a blank suffix.
  • It defines: "Only units in the units table that are of type unit or suffix (so not meter) can be a graphic unit." This clearly indicates that any unit of type suffix is graphable. OED fixes this up by making the input unit with a suffix be undisplayable after it adds the new suffix units. Thus, the new ones are graphable but not the original unit with a suffix is not.
  • It warns: "An admin should never have a unit that has a suffix but cannot get to another unit as it will be hidden without another unit created." The revised UI automatically sets a site/admin created unit with a suffix to displayable none. This is also done during processing of that unit so it is somewhat duplicated but a good safety check in case a unit is added in another way. Thus, this is no longer an issue for normal usage.

Code

• The standard OED test data is created in src/server/data/automatedTestingData.js and set in specialUnitsGeneral where kg CO₂ has typeOfUnit: Unit.unitType.UNIT, suffix: 'CO₂'. Thus, the unit type is unit but there is a suffix. This is consistent with the design document.
• PR Fixes to suffix type when creating or editing units. #1040 (based on issue Units of type suffix should have a suffix #1019) from 11/7/23 changed the input of units so if there is a suffix (!= '') then the type of unit must be suffix. If not, it automatically changes on save so this is the case. This is done in src/client/app/components/unit/CreateUnitModalComponent.tsx in handleSaveChanges() where is has typeOfUnit: (state.typeOfUnit != UnitType.suffix && state.suffix != '') ? UnitType.suffix : state.typeOfUnit. This means you cannot enter a unit that mirrors the OED test data and is inconsistent with the design document since it should be of type unit not suffix.
• PR Implementing cik visual graph #1382 from 11/21/24 added visualization of units that included suffix capabilities (the original version was more limited from PR Add VisualUnitsComponent #1328). In src/client/app/components/visual-unit/CreateVisualUnitComponent.tsx in a useEffect it has d.suffix && d.typeOfUnit === 'unit' ? colorSchema('suffix.input') : colorSchema(d.typeOfUnit)) so it colors a unit as suffix input if it has a suffix and it is of type unit. This is consistent with the test data and design document.
  • The test data shows pink (suffix input) because it matches the first part of the conditional given it is of type unit and has a suffix.
  • Any UI added ones are orange (suffix analyzed) because it matches the second part of the conditional because it is of type suffix and it has a suffix. In this case the type of unit is suffix and that is orange in the visualization. The visualization does match the design document but the UI entered unit does not and confuses the code into thinking it was an analyzed unit because it if of type suffix.
• This work was done about 3/18/22 (other changes for the non-suffix conditions came later). When src/server/services/graph/redoCik.js runs it calls src/server/services/graph/handleSuffixUnits.js which gets the units to process via Unit.getSuffix(conn) that calls src/server/sql/unit/get_suffix.sql which returns units which match SELECT * FROM units WHERE suffix != '' so it is any unit type but must have a suffix. It then skips considering new OED created units (the special suffix processing) using if (destinationUnit.typeOfUnit === Unit.unitType.SUFFIX || destinationUnit.displayable === Unit.displayableType.NONE) {. If this input unit with a suffix was previously processed then the OED added units are of type suffix. These will be found during the graph path checking but will be skipped by the first part of this if statement. The second part makes sure that if it isn't visible then it isn't done (I think but not careful about that). Note any data currently input via the UI for create/edit of units still passes the check since it has a suffix and it does not matter if it is of type suffix for the unit. It will be processed and OED will find a linked unit to create new suffix units from.

Type of change

• Note merging this changes the database configuration.
• This change requires a documentation update

Checklist

• I have followed the OED pull request ideas
• I have removed text in ( ) from the issue request
• You acknowledge that every person contributing to this work has signed the OED Contributing License Agreement and each author is listed in the Description section. This checkbox is required.
• By submitting this PR I agree to the OED AI policy specified below and acknowledge that I followed its terms in this submission. This checkbox is required.

Limitations

This PR is built on top of PR #1693 since it was found during review of that code. There are many files listed as changed that are from that PR. This PR will need to wait until that is merged and then only 3 files should have modest changes.

AI Disclosure

List all AI tools used including version(s). You can submit without the versions but OED may request further information before accepting the PR.

None used.

If used, describe how each AI tool was used including giving the prompts used. You can submit without the prompts but OED may request further information before accepting the PR.

NA

List of GitHub IDs for anyone working on or contributing to this PR that you cannot certify has followed this policy. Any conttributors not listed are being certified by you to have complied with the terms of the OED AI policy shown below.

None

OED AI policy

Given the expanding usage of AI and review of submissions to OED, OED is developing an AI policy. OED is working on a more general solution but for now OED has this AI policy and each submission is required to:

• Disclose of all AI tools used including version.
• Disclose how each AI tool was used including giving the prompts used.
• By checking the AI policy checkbox above, you certify that you have the copyright to the submitted work. Given recent court cases, this will require that less than 50% of the code and documentation came from AI. Less is even better. Every AI system you use must be checked that they provide you with copyright to this work that is compatible with the OED project MPL license.
• By checking the AI policy checkbox above, you certify that you have personally reviewed all code and properly tested it. Thus, you are taking personal responsibility for the quality of the submission by guaranteeing you carefully reviewed every aspect in detail.
  If more than one person is involved in a request, then each person on the team needs to certify and provide the information above. If you don't list anyone else in the section above on unknown compliance with this policy then you must have personal knowledge that the other team members provided you with the necessary information and you are faithfully providing or indicate the answers only apply for yourself or a given list of authors (by GitHub ID).

Other items may be added in the future. It is also open to change given input, new information or changes in the AI sphere and you can make comments/suggestions to the OED project.

[huss]

The PR is being closed since it is replaced by PR #1729. That PR covers more items and is no longer tied to another PR. The changes in the PR were updated in that PR but carried over.