You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a good PR for anyone with any programming skills. It should be a very simple REST API.
Key acceptance criteria:
Messages should be able to be created through normal release or PR processes
Reading from existing processes will be helpful - example can the code read from an "Announcements.md" in the repo or GitHub releases?
Target URLs should be configurable with other branding configs, see Centralized branding #23 . That way vendors or resellers or other takers can set up their own notifications
The implementation could be EITHER a server or serverless thing OR changes to the Mirth code to just read from GitHub or openintegrationengine.org
Repos have a few atom feeds to read from, potentially for this issue using this feed could function as the source of truth for https://github.com/OpenIntegrationEngine/engine/releases.atom.
Since they were originally using the version number to send back to the server, we can chop up the semver version to filter out the returned entries in either the title (if that convention stays) or for what would appear more consistently, the version provided at the end of the id or link.
This path should be disabled in a round-about way in #23 with 4dc8f29 such that the notifications buttons and dialog are never shown and called. But now that I think of it, a much better band-aid would have been to return early from getNotifications() with an empty/hardcoded list...
I'd like to take a crack at this. From what I can tell, the current setup is for the getNotifications function to get information from NG, but we want to get it from the a github releases api tied to the OIE engine repo. Is that broadly correct?
I think the feed url should be configurable. #23 has a new class called BrandingConstants in the works for such hard-coded static values.
Technically speaking it doesn't really matter if the feed is GH's releases or someone's cooking blog. It just has to be configurable at compile-time. The main effort would be reading the feed and displaying it prettily.
Activity
#24 Disable fetching notifications from NextGen notification service
#24 Disable fetching notifications from NextGen notification service
jonbartels commentedon Apr 10, 2025
This is a good PR for anyone with any programming skills. It should be a very simple REST API.
Key acceptance criteria:
The implementation could be EITHER a server or serverless thing OR changes to the Mirth code to just read from GitHub or openintegrationengine.org
leovander commentedon Apr 11, 2025
Repos have a few atom feeds to read from, potentially for this issue using this feed could function as the source of truth for
https://github.com/OpenIntegrationEngine/engine/releases.atom.Here is a sample entry returned from above:
Seems like all the relevant metadata that the current service uses to display notifications is already there
id->idname->titledate->updated?content->contentengine/server/src/com/mirth/connect/client/core/ConnectServiceUtil.java
Lines 129 to 132 in 37968e1
Would obviously need to convert that XML to JSON or update the implementation to parse the xml feed instead.
And NG's as an example:
https://github.com/nextgenhealthcare/connect/releases.atomAnd what the parsed contents looks like: https://github.com/nextgenhealthcare/connect/releases/tag/4.5.2
kpalang commentedon Apr 11, 2025
I like @leovander's idea! Using RSS or Atom would be quite ideal for this.
leovander commentedon Apr 11, 2025
Few more notes:
This was potentially another phone home attempt providing a server id. re: #5
https://github.com/OpenIntegrationEngine/engine/blob/main/server/src/com/mirth/connect/client/core/ConnectServiceUtil.java#L101-L103
Since they were originally using the version number to send back to the server, we can chop up the
semverversion to filter out the returned entries in either thetitle(if that convention stays) or for what would appear more consistently, the version provided at the end of theidorlink.That filtering could happen in the ConnectService that fetches the entries.
A few other things to need to test out or confirm:
There actually is a REST API, no credentials needed:
https://api.github.com/repos/nextgenhealthcare/connect/releasesand supports pagination: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#list-releasesI think that answers that.
kpalang commentedon Apr 12, 2025
This path should be disabled in a round-about way in #23 with 4dc8f29 such that the notifications buttons and dialog are never shown and called. But now that I think of it, a much better band-aid would have been to return early from
getNotifications()with an empty/hardcoded list...kelaompachai commentedon Apr 17, 2025
I'd like to take a crack at this. From what I can tell, the current setup is for the getNotifications function to get information from NG, but we want to get it from the a github releases api tied to the OIE engine repo. Is that broadly correct?
kpalang commentedon Apr 21, 2025
@kelaompachai Please do!
I think the feed url should be configurable. #23 has a new class called
BrandingConstantsin the works for such hard-coded static values.Technically speaking it doesn't really matter if the feed is GH's releases or someone's cooking blog. It just has to be configurable at compile-time. The main effort would be reading the feed and displaying it prettily.
kelaompachai commentedon Apr 22, 2025
Ok, I'm on it.
#24 Disable fetching notifications from NextGen notification service
#24 Disable fetching notifications from NextGen notification service
#24 Disable fetching notifications from NextGen notification service
mgaffigan commentedon Jun 1, 2025
I'm including here for reference the existing HTTP Request made by 37e0f4c, and the response from NextGen as of right now.
NotificationServerlet getNotificationCount
Request:
Response:
NotificationServerlet getNotifications
Request:
Response:
Update client notifications to pull from github Release API
Update client notifications to pull from github Release API
Merge pull request OpenIntegrationEngine#24 from Innovar-Healthcare/u…