Group routes together about public-message-board HOT 5 CLOSED

I don't think we need to remove filtered-out-routes if they share a detour with routes that we included in our URL parameter (I could be wrong, but no situations come to mind where that would be an issue, should it ever come up).

However, now that I think about it, we ought to sort by Priority too. How about:

• Group routes together (sort by route within each detour)
• Sort detours by Priority, then ascending by route (where general messages [ones that aren't associated with any routes] are after route-specific messages at the same priority level, and we use the lowest route number when there are multiple routes associated with a single detour), then descending by FromDate, then descending by FromTime (so newest detour shows first if route and priority are the same)

Priority values appear to be:

0. Emergency
1. High
2. Medium
3. Low

No matter what we do, the nature of grouping by route means we may occasionally end up with detours for a specific route not being next to each other in the list (and sorting by priority will affect that as well).

I have a vague recollection of FromTime maybe not being used (or not being used in a way that make sense), and what there's now is weird:

<Message>
Due to staffing levels, "S" Trips will not operate between 05/27/2023 and 09/03/2023.
</Message>
...
<FromDate>2023-05-28T00:00:00</FromDate>
<FromTime>2023-05-30T00:00:00</FromTime>

But I can't think of harm being caused by sorting by FromDate and then FromTime.

Am open to suggestions.

This seems like something we can/should do, but I'd like it as a second ticket/PR (that I'm gonna make now). Just grouping the routes and reconciling that with the current sorting/filtering logic is already going to be a fairly dense PR.

So for this issue:

• public messages should be grouped by route
• all routes in group should be fully displayed, even if only one of the routes is a part of the filter
• current ordering should be preserved, but using the "highest ranked" route within a group

from public-message-board.

Still pending green light (dont work on yet) but @frothedoatmilk called dibs on this

from public-message-board.

Thanks, it's green lit.

There are pros and cons to each approach, but I think it's worth doing since our use case is for this to be rendered in a small iframe, and it's common for UMTS detours to impact multiple routes (so it's likely that detours listed for each route would not all fit in the iframe, which also doesn't have scroll bars).

Please sort by route within each detour, and also by route for all detours.

from public-message-board.

Please sort by route within each detour, and also by route for all detours.

On the second part, I guess we have no real choice but to use the "lowest" route in a grouping. The other uncertainty I have is what should happen if only part of a route grouping has been whitelisted. Should we remove them from the groupings, or still display labels for ones that have been filtered out?

from public-message-board.

I don't think we need to remove filtered-out-routes if they share a detour with routes that we included in our URL parameter (I could be wrong, but no situations come to mind where that would be an issue, should it ever come up).

However, now that I think about it, we ought to sort by Priority too. How about:

• Group routes together (sort by route within each detour)
• Sort detours by Priority, then ascending by route (where general messages [ones that aren't associated with any routes] are after route-specific messages at the same priority level, and we use the lowest route number when there are multiple routes associated with a single detour), then descending by FromDate, then descending by FromTime (so newest detour shows first if route and priority are the same)

Priority values appear to be:

0. Emergency
1. High
2. Medium
3. Low

No matter what we do, the nature of grouping by route means we may occasionally end up with detours for a specific route not being next to each other in the list (and sorting by priority will affect that as well).

I have a vague recollection of FromTime maybe not being used (or not being used in a way that make sense), and what there's now is weird:

<Message>
Due to staffing levels, "S" Trips will not operate between 05/27/2023 and 09/03/2023.
</Message>
...
<FromDate>2023-05-28T00:00:00</FromDate>
<FromTime>2023-05-30T00:00:00</FromTime>

But I can't think of harm being caused by sorting by FromDate and then FromTime.

Am open to suggestions.

from public-message-board.