The iris's discuss from mnit-rtmc

Improve ramp meter locks

Ideas:

Show name of user who created lock
Initial lock rate should match current ramp demand
Add duration, defaulted to 15 minutes
Automatic queue override to prevent backup
Lock reasons: knocked down, indication

Add compound signs

Static .png background
Rectangle defining location of DMS on sign (x,y,w,h)
Add support in honeybee as well as IRIS java

Improve DMS maintenance style

Add maintenance style when "Too many stuck pixel..." error happens

Wrong colors importing graphic from .png

Colors imported as RGB instead of BGR

Allow [loc...] tags in msg_line

When used, populate line selectors with downstream pickable locations. Use the same logic as incident locators.

Mapping issue

Hello

The tutorial in the site https://mnit-rtmc.github.io/iris/mapping.html, explaining how generate maps for iris is obsolete.
A lot of files required are no longer available on internet.

Can you update this part please.

Thank you in advance.

Can't log in using given credentials to IRIS

Hi, I just finished installing and trying to run IRIS, but it errors out after I used the given credentials of admin/atms_242.

Any insight on how to fix this?
----ERROR----
us.mn.state.dot.sonar.SonarException: Login timed out
at us.mn.state.dot.sonar.client.Client.waitLogin(Unknown Source)
at us.mn.state.dot.sonar.client.Client.login(Unknown Source)
at us.mn.state.dot.tms.client.SonarState.login(Unknown Source)
at us.mn.state.dot.tms.client.IrisClient.createSession(Unknown Source)
at us.mn.state.dot.tms.client.IrisClient.access$300(Unknown Source)
at us.mn.state.dot.tms.client.IrisClient$4.doInBackground(Unknown Source)
at us.mn.state.dot.tms.client.IrisClient$4.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Support ONVIF camera control

Add manifest to .traffic file

Message Composer Overlapping Text

When a whole-sign text rectangle tag is used in a multi-page message pattern in the message composer, IRIS will insert the text from the composer fields incorrectly, leading to overlapping text on one page of the message, and leaving other page(s) blank. For example, using the following message pattern:

[tr1,1,0,0][np][tr1,1,0,0]

will produce:

TEST 1[nl]TEST 2[nl]TEST 3[tr1,1,0,0]TEST 4[nl]TEST 5[nl]TEST 6[np][nl][nl][tr1,1,0,0]

Looking like this in the preview and on the sign:

Page 1	Page 2

This does not occur without the [tr...] tags, for example:

[np]

produces:

TEST 1[nl]TEST 2[nl]TEST 3[np]TEST 4[nl]TEST 5[nl]TEST 6

Which looks like:

Page 1	Page 2

Interestingly, this behavior also does not appear when using a non-default font tag. For example:

[fo10][tr1,1,0,0][np][tr1,1,0,0]

produces:

[fo10][tr1,1,0,0]TEST 1[nl]TEST 2[nl]TEST 3[np]TEST 4[nl]TEST 5[nl]TEST 6[tr1,1,0,0]

And looks like:

Page 1	Page 2

When using the default font in a font tag, however, it produces the issue (like the first pair of images). In that case, this message pattern:

[fo11][tr1,1,0,0][np][tr1,1,0,0]

produces the following MULTI string:

TEST 1[nl]TEST 2[nl]TEST 3[fo11][tr1,1,0,0]TEST 4[nl]TEST 5[nl]TEST 6[np][nl][nl][tr1,1,0,0]

This behavior has been observed in several versions back to at least 5.42.2 and can be replicated in the current version (5.49.0). Hopefully it is just a minor error in handling the input from the composer fields. If you have any questions or would like more testing, just let me know.

Cache password hash for LDAP users

Currently, a user_id can have a password and dn assigned, independently. This change would update the password hash upon successful authentication with the LDAP server. For users with no dn assigned, operation would remain the same.

This change would mitigate downtime due to LDAP servers being offline, as happened with the CrowdStrike event. If LDAP login fails due to server issues, the cached password would be checked, allowing users to still log in.

DMS action messages in work zones

The OCC SPIKE and LOCKED ON auto fail conditions can prevent the use of DMS messages with action tags. A flag will be added to action plans to ignore detector auto-fail conditions.

Exit ramp backup [exit...]
Slow traffic warning [slow...]

Use hashtags for camera states

Replace streamable flag with "#LiveStream" hashtag
~~Also for "#Publish"?~~
Add "#Recorded" tag (for external recording system)
Tag for "#IrisOnly" / "#NoVdu" ?
Others?

Add a hashtags field to the "camera" / "camera_pub" JSON files produced by honeybee.

Web UI Tracking

This issue tracks tasks needed for the Web UI.

Mapping

Change earthwyrm to use rosewood/loam instead of PostGIS
Update to modern version of Leaflet JS library
Handle Leaflet events by updating selected items, etc.
Add tooltips for devices

Honeybee / graft

Merge into a single service, using axum
Generate freeway segment layer (loam) for earthwyrm
Implement SSE messages for selected card / resource type
Verify user's network domain on login

DMS

Incidents

Add resource type 🚨

Cameras

LCS Arrays

Status card showing current indications
Deploying indications
Default to deployed item state, not all

Ability to disable camera iris/focus/reset buttons

Maybe these should only be allowed with "Manage" permissions?

Extend DMS message duration

Re-sending a message with an updated duration should allow an operator to adjust the expiration time.

Beacon action trigger on friction threshold

For beacons attached to "slippery when flashing" signs -- when nearby weather sensors report friction threshold below 0.6 (configurable).

Detector label improvement

The label generated by the detector_label SQL function does not always match the label generated by DetectorHelper.getLabel

External authentication with LDAPS

Currently, external authentication is only supported using unencrypted connections to an LDAP server, such as Active Directory. LDAPS would improve security of these connections.

User account management

Features:

Crack attempt detection
Request throttling (minimum 1 second)
Forced password reset on login (non-LDAP accounts)
Track hashes of compromised passwords and prevent reuse
Auto-disable accounts based on inactivity
Reduced permission account management
Notes field on user (for admin)

Improve DMS brightness management

Allow sign configs to share brightness tables.

Permission/privilege transition

There is some overlap between the old "privilege" system used by the Java client, and the new "permission" system for the web UI. The current migration scripts create permissions for the administrator role, but all other roles are excluded. Since permissions are checked by the server for some operations, this prevents users in the Java client from performing certain actions that they have the appropriate privileges for. Since permissions are (presumably) only configurable via the web UI (and database), this creates some administrative challenges.

Can you add a note to the release notes that administrators need to consider this when upgrading? I presume you have some way that you're dealing with it at MnDOT that may not work for others, but maybe you can recommend an approach. In our case, since we don't currently have the web client running, I added permissions to bypass those checks to leave things working with the old privilege system for now (which we can revisit when we get around to deploying the web stuff).

Let me know your thoughts on this when you have time. Ideally we could come up with some approach to deal with this in the migrate scripts, at least partially (or perhaps there could be another method for enabling/disabling it). I know eventually you plan to move everything over to the new system, but some way to deal with things in the interim (or at least a prominent warning) would be good. Thanks!

PeriodicSample comparisons

If stamp marks end of period, should it be minus operator here, not plus?
But I may be wrong.

iris/src/us/mn/state/dot/tms/server/PeriodicSample.java

Lines 46 to 50 in 93ef16f

    
           public int compareTo(PeriodicSample other) { 
        
           	long ms = stamp + periodMillis(); 
        
           	long oms = other.stamp + other.periodMillis(); 
        
           	return (int) (ms - oms); 
        
           }

And by the way, you can use Long.compare() method.

DMS sign_event owner after scheduled msg cleared

The sign_event table has a msg_owner column, which contains the "owner" of a sign message when activated. After a scheduled message is cleared, the user msg (msg_user) will be activated, with msg_owner set to the user who created that message. This can be confusing if the message is "blank" -- it seems like the user initiated the sign to blank, but in fact, it was just a regular scheduled message expiring with no user interaction.

The fix is to not store blank messages in DMS msg_user