Issue869 - Implemented Failure/Success Notifications to Edit/Create pages #1566

aduques · 2026-01-16T02:03:42Z

Description

These changes address Issue #869. These changes aim to reimplement the missing success and failure notifications across all of the available Edit/Create pages (excluding Maps and Admin Settings). The additions of these notifications do not intend to change the functionality of the edit/create pages, but instead help future developers understand if a request is successful or not. The messages on each of the notifications come from the predetermined messages listed on data.ts.

In this pull request:

showSuccessNotifications() and showFailureNotifications() are added to all edit/create pages and are all made to display a unique message based on the page.
Each success notification includes the predetermined message from data.ts + specific information of the object (meter, conversion, user, etc.) to help the developer identify what was specifically updated.
Each failure notification includes the predetermined message from data.ts + the specific error
Each file contains TODO DEBUG code that is used to force the error notification. This is only included for testing and is intended to be removed before merging.
The data.ts was slightly modified to include missing predetermined messages and to fix a small typo on one of the messages.
Success and Failure Notifications were added for the delete feature on the edit pages and includes some specific information of the involved object.

Motivation: After working on Issue #1191 and Issue #1517, I have noticed that there was inconsistency with the failure/success notifications across the edit/create pages. Some pages had it implemented with vague messages, while some did not have the notifications implemented at all. After discussing with the project maintainer, it was brought to my attention that there was an existing issue that had overlapping problems. As someone who is familiar with the edit/create pages, I wanted to take the opportunity to work on this issue.

Partly Addresses #869

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.

Limitations

As discussed in the comments of the Issue page, I was not sure whether or not the implemented notifications have the desired information. In addition, no progress was done on the PreferencesComponent.tsx (Admin Settings page) at the time of initially creating the pull request. I plan on addressing it after getting feedback on the other parts of the implementation.

To reiterate, this pull requests is intended to show the current progress and to improve once feedback is given.

Edit: In addition, I was not able to figure out how to test the failure notifications for the delete features on the edit pages.

…exclude maps and admin), added failure/success notifications to the delete feature on edit pages, slightly modified data.ts to include more messages that were needed for some notifications, added TODO DEBUG used to test failure

aduques · 2026-01-16T02:14:07Z

Below are the results of the failure/success notification in case if it helps to compare with for initial testing.

CreateUnitModalComponent.tsx
Success Message:”Successfully created a unit. "testupdatednew" (identifier: testupdatednew, type: unit)
Failure Message: Failed to create a unit."Error while inserting new unit: error: new row for relation "units" violates check constraint "units_sec_in_rate_check""
Note: The handleSaveChanges() does not have an “inputOk” check that validates the inputs. → No if else statement

EditUnitModalComponent.tsx
Success Message: Successfully edited unit. "testupdated23" (identifier: testupdatednew, type: unit)
Failure Message: Failed to edit unit."Unable to update unit"

PreferencesComponent.tsx
Success Message:
Failure Message:

NOTE: Left this one out, because I was unable to figure out how to test the failure notifications.

CreateMeterModalComponent.tsx
Success Message: Successfully created a meter."testmetersuccess2" (identifier: successidentifier, type: egauge)
Failure Message: Failed to create a meter with message: "error: new row for relation "meters" violates check constraint "meters_identifier_check" with detail Failing row contains (55, , , f, f, metasys, null, null, , , 0, f, f, 00:00:00, 23:59:59.999999, 0, 0, 1, increasing, f, 0, 1970-01-01 00:00:00+00:00, 1970-01-01 00:00:00+00:00, 1970-01-01 00:00:00, 21, 36, none, PT15M, -9.007199254740991e+15, 9.007199254740991e+15, 1970-01-01 00:00:00, 6970-01-01 00:00:00, 75, reject_all)."

EditMeterModalComponent.tsx
Success Message: Successfully edited meter."testedit" (identifier: testfailures3, type: egauge)
Failure Message: Failed to edit meter with message: "error: new row for relation "meters" violates check constraint "meters_identifier_check" with detail Failing row contains (54, , , f, f, egauge, null, null, , , 0, f, f, 00:00:00, 23:59:59.999999, 0, 0, 1, increasing, f, 0, 1970-01-01 00:00:00+00:00, 1970-01-01 00:00:00+00:00, 1970-01-01 00:00:00, 21, 20, none, PT15M, -9.007199254740991e+15, 9.007199254740991e+15, 1970-01-01 00:00:00, 6970-01-01 00:00:00, 75, reject_all)."

CreateUserModalComponent.tsx
Success Message: Successfully created the user: testingsuccess" (role: admin)
Failure Message: Failed to create the user: testfailurename Test error message

NOTE: The failure message from the Promise (the forced failure notification) is generic, but in actual use cases, the real error message should still appear. However, I am unable to figure out how to test the failure naturally as using the Promise was my work around.

EditUserModalComponent.tsx
Success Message: Successfully edited user: testsuccess" (role: admin)
Failure Message: Failed to edit user: testsuccess Test error message

ReadingsCSVUploadComponent.tsx
Success Message (when testing threeYearA.csv + Cos 23 Min kWh):

<h1>SUCCESS</h1><h2>It looks like the insert of the readings was a success.</h2><h3>However, note that the processing of the readings returned these warning(s):</h3><br>For meter Cos Sq kWh: Warning parsing Reading #1. Reading value gives 2 with warning message:<br>The current reading startTime is not after the previous reading's end time. Note this is treated only as a warning since readings may be sent out of order.<br>There is a gap in time between this reading and the previous reading that exceeds the allowed amount of 90000 seconds.<br>For reading #1 on meter Cos Sq kWh in pipeline: previous reading has value 1 start time 2020-04-15T17:00:00Z end time 2020-04-15T18:00:00Z and current reading has value 2 start time 2016-10-10T22:00:00Z end time 2016-10-10T23:00:00Z with timeSort increasing; duplications 1; cumulative false; cumulativeReset false; cumulativeResetStart 00:00:00; cumulativeResetEnd

Failure Message:

<h1>FAILURE</h1><h2>It looks like the insert of the readings had issues with some or all of the readings where the processing of the readings returned these warning(s)/error(s):</h2>For meter cà: Error parsing Reading #1 The start (start_timestamp) and/or end time (end_timestamp) provided did not parse into a valid date/time so all reading are rejected.<br>For reading #1 on meter cà in pipeline: previous reading has value 0 start time 1970-01-01T00:00:00Z end time 1970-01-01T00:00:00Z and current reading has value unknown start time Invalid date end time Invalid date with timeSort increasing; duplications 1; cumulative false; cumulativeReset false; cumulativeResetStart 00:00:00; cumulativeResetEnd 23:59:59.999999; lengthGap 0; lengthVariation 0; onlyEndTime false<br>

NOTE: Tested Failure by using the provided sampleReadings.csv.

MetersCSVUploadComponent.tsx
Success Message:

Failure Message:

<h1>FAILURE</h1>CSVPipelineError: Failed to upload meters due to internal OED Error: Meter name of "2" got database error of: invalid input syntax for type boolean: "2016-10-10 23:00:00"

NOTE: Tested Failure by using threeYearA.csv
NOTE: Was not able to find a sample csv for meters in the documentation to help test the success message.

CreateGroupModalComponent.tsx
Success Message: Successfully created a group. "testingsuccessnotification" (id: -1, default graphic unit: -99)
Failure Message: Failed to create a group with message: "Got request to create group with invalid data. Error(s): instance.name does not meet minimum length of 1"

NOTE: Most likely will have to change what values get displayed on the notification. The only required.

EditGroupModalComponent.tsx
Success Message: Successfully edited group. "testingfailuresuccess" (id: 31, default graphic unit: -99)
Failure Message: Failed to edit group with message: "Got request to edit group with invalid data. Error(s): instance.name does not meet minimum length of 1"

CreateConversionModalComponent.tsx
Success Message: Successfully created a conversion. (sourceID: 5, destinationID: 4)
Failure Message: Failed to create a group with message: "Got request to insert conversion with invalid conversion data. Error(s): instance.sourceId must be greater than or equal to 0,instance.destinationId must be greater than or equal to 0"

EditConversionModalComponent.tsx
Success Message: Successfully edited conversion. (sourceID: 53, destinationID: 20)
Failure Message: Failed to edit conversion."Got request to edit conversions with invalid conversion data, errors: instance.sourceId must be greater than or equal to 0,instance.destinationId must be greater than or equal to 0"

NOTE: I have not checked whether or not the notifications are applied elsewhere such as deleting in the edit pages.

DELETE MESSAGES

EditConversionModalComponent.tsx
Success Message: Successfully deleted conversion. (sourceID: 36, destinationID: 22)
Failure Message:

EditGroupModalComponent.tsx
Success Message: Successfully deleted group. testingsuccess2
Failure Message:

NOTE: data.ts does not have group.delete.success or group.delete.failure

EditUserModalComponent.tsx
Success Message: Successfully deleted user: testsuccess
Failure Message:

EditMeterModalComponent.tsx
Success Message:
Failure Message:

NOTE: No delete capabilities currently in EditMeterModalComponent.tsx.

EditUnitModalComponent.tsx
Success Message: Successfully deleted unit: test invalid unit
Failure Message:

huss · 2026-01-28T16:45:38Z

While working on this PR I became confused by the file src/client/app/redux/actions/conversions.ts. After some checking, it appears it is not used at all. This is also consistent with the fact that webpack does not rebuild the client when it is changed. I tried deleting it and everything still worked fine. I believe src/client/app/redux/api/conversionsApi.ts is the newer way with the RTK that has now completely replaced that file. @aduques if you agree then it can be removed as part of this PR even though it is only indirectly related.

huss

I want to thank @aduques for another contribution to OED. I'm sorry it took a little while to look this over. Overall, it seems good. You noted it is a WIP so you can, if you prefer, convert this PR to a draft until you think it is more complete. I made some comments for you to consider. Please let me know if anything is not clear or I can help in any way.

huss · 2026-01-28T14:23:29Z

src/client/app/translations/data.ts

 		"group.create.nounit": "The default graphic unit was changed to no unit from ",
 		"group.delete.group": "Delete Group",
 		"group.delete.issue": "is contained in the following groups and cannot be deleted",
+		"group.delete.success": "Successfully deleted group.",


The translation key needs to be in all three languages and it is only in en here. Please copy both of the new keys into the other languages. You don't need to do the translation and can put \u{26A1} at the end of the value/translation string to indicate it needs translation.

huss · 2026-01-28T15:56:04Z

src/client/app/components/conversion/CreateConversionModalComponent.tsx

+				})
+				.catch(err => {
+					showErrorNotification(
+						translate('group.failed.to.create.group') + '"' + err.data + '"');


This message seems to be about groups and not a failed adding of a conversion.

huss · 2026-01-28T16:22:43Z

src/client/app/components/conversion/CreateConversionModalComponent.tsx

+				.then(() => {
+					showSuccessNotification(
+						translate('conversion.successfully.create.conversion') +
+						' (sourceID: ' + conversionState.sourceId + ', destinationID: ' + conversionState.destinationId + ')'


This is a general comment. OED should not show ids on messages. I think I understand that you wanted to help a developer with debugging but the real usage is for an admin at an OED site. The id is something internal to OED that an admin does not need and should not see. If a developer needs this information then they should use a debugger and/or temporary console statements. If more information is to be added then one could put in the name of the source/destination in a similar fashion to what you did in other places.

huss · 2026-01-28T16:26:51Z

src/client/app/components/conversion/CreateConversionModalComponent.tsx

 			// Omit the source options , do not need to send in request so remove here.
 			// If source is a meter, make bidirectional false
 			// If source or destination is a suffix unit, make bidirectional false
 			addConversionMutation({...omit(conversionState, 'sourceOptions'),


I cannot add a comment above so am doing it here. handleWarningConfirm also does an add of the conversion when a warning is done first. It needs to deal with the error message.

The older code did the error checks and success/failure popups in the actions file but that is now gone with the RTK. I don't know if the new API files could easily be changed to do this so it is centralized so any conversion add (and for other ones too) would always show the message no matter where it is called. I think this is outside this PR but something OED could look into sometime in the future.

huss · 2026-01-28T19:00:24Z

src/client/app/components/admin/users/CreateUserModalComponent.tsx

 	Button, Col, Container, FormFeedback, FormGroup, Input, Label, Modal,
 	ModalBody, ModalFooter, ModalHeader, Row
 } from 'reactstrap';
+// TODO DEBUG: added in to test the showErrorNotification


I'm unclear on this comment on this being for debug as the include(s) that existed before your changes.

huss · 2026-01-28T19:29:30Z

src/client/app/components/groups/EditGroupModalComponent.tsx

+						.unwrap()
+						.then(() => {
+							showSuccessNotification(
+								translate('group.successfully.edited.group') + ' "' + submitState.name +


Please see create group for comments.

huss · 2026-01-28T19:31:22Z

src/client/app/components/meters/CreateMeterModalComponent.tsx

+					showSuccessNotification(
+						translate('meter.successfully.create.meter') + '"' + submitState.name +
+						'" (identifier: ' + submitState.identifier + ', type: ' + submitState.meterType + ')'
+					);


I cannot put a comment below so it is here. I wonder if the error msg should also include the meter name (maybe other values?) to be sure it is identified in case the err does not have it.

huss · 2026-01-28T19:32:04Z

src/client/app/components/meters/EditMeterModalComponent.tsx

+						showSuccessNotification(
+							translate('meter.successfully.edited.meter') + '"' + submitState.name +
+						'" (identifier: ' + submitState.identifier + ', type: ' + submitState.meterType + ')'
+						);


Please see create meter for comments.

huss · 2026-01-28T19:33:04Z

src/client/app/components/unit/CreateUnitModalComponent.tsx

-				showErrorNotification(translate('unit.failed.to.create.unit'));
+			.catch(err => {
+				showErrorNotification(
+					translate('unit.failed.to.create.unit') + '"' + err.data + '"'


I'm not sure I marked them all but see comment on more info on error and please make them all consistent to whatever is done.

huss · 2026-01-28T19:36:18Z

src/client/app/components/unit/EditUnitModalComponent.tsx

 						handleClose();
 					}}
 					onCancel={() => setShowUnsavedWarning(false)}
+					// TODO DEBUG: Disabled is always set to false,


This is fine. I noticed you can limit to only changing one place for testing if you modify the setCanSave to be true above.

aduques added 6 commits October 31, 2025 09:23

temporary solution for create/edit meter, unit, create group

40fd977

Merge branch 'development' into issue869

84f0ab4

added TODO DEBUG on all relevant files

a950687

Merge branch 'development' into issue869

d50188a

updated createGroup, createMeter, editMeter, groups.js

1d1b4ea

huss requested changes Jan 28, 2026

View reviewed changes

Issue869 - Implemented Failure/Success Notifications to Edit/Create pages #1566

Are you sure you want to change the base?

Issue869 - Implemented Failure/Success Notifications to Edit/Create pages #1566

Conversation

aduques commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

Checklist

Limitations

Uh oh!

aduques commented Jan 16, 2026

Uh oh!

huss commented Jan 28, 2026

Uh oh!

huss left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aduques commented Jan 16, 2026 •

edited

Loading