B-21941 TOO Queue Filtering For Destination Only Requests

[traskowskycaci]

Agility ticket

Summary

This query gave me a run for my money - to filter out moves from the main TOO queue with only destination requests, we have to do some joins and check for destination requests, like destination SIT or destination address changes - as well as check that we only have those and not anything else that should keep the move in the TOO main queue (such as excess weight warnings).

I added a locator check in the tooDestinationOnlyRequestsFilter function, otherwise it would pull in moves with excess weight on every search, in addition to the move searched for.

How to test

Please ignore the move CRQST1 - it has only a destination address change and should be filtered out of the queue, but is hanging around for some reason. However, if you create a new move with only a destination address change - it is filtered out of the TOO queue correctly. I suspect the weird behavior is due to this being an old test move.

Please try to think of any situation where a move should appear in the TOO queue and test that in addition the scenarios below.

Some test cases to try - please try various combos of these as you see fit.

Test cases:

1. New move
2. SC counsels
3. TOO approves
4. Prime adds origin SIT service items
5. Check TOO queue - should appear
6. TOO approves origin SIT service items
7. Check too queue - should not appear
8. Prime adds dest SIT service items
9. Check TOO queue - should not appear
10. Check dest queue - should appear
11. Approves dest SIT service items
12. Check TOO queue - should still not appear
13. Check dest queue - should not appear
14. Update dest address to have a delivery address update request ( > 50 miles)
15. Check too queue - should not appear
16. Check dest queue - should appear
17. Trigger move for excess weight as prime
18. Check TOO queue - should appear
19. Check dest queue - should still appear if you didn't approve the destination address change, or won't appear in dest queue if you did

Test service items, shipment address updates, excess weight triggered

1. New move
2. SC counsels
3. TOO approves
4. Prime adds origin SIT service items
5. Check TOO queue - should appear
6. TOO approves origin SIT service items
7. Check TOO queue - should not appear
8. Prime adds dest SIT service items
9. Check TOO queue - should not appear
10. Check dest queue - should appear
11. Trigger move for excess weight as prime
12. Check TOO queue - should appear
13. Check dest queue - should not appear
14. Approve dest SIT service items
15. Check TOO queue - should still not appear
16. Check dest queue - should not appear
17. Update dest address to have a delivery address update request ( > 50 miles)
18. Check TOO queue - should not appear
19. Check dest queue - should appear

Should be able to appear in both TOO and destination TOO queue:

1. New move
2. SC counsels
3. TOO approve
4. Prime addes origin SIT service items
5. Check TOO queue - should appear
6. Prime adds dest SIT service items
7. check too queue - should appear
8. check dest queue - should appear
9. approve dest SIT service items
10. check too queue - should still appear
11. check dest queue - should not appear

SIT Extension should appear in TOO queue:

1. New move
2. SC counsels
3. TOO approves
4. Prime adds origin SIT service items
5. Check TOO queue - should appear
6. TOO approves origin SIT service items
7. Check TOO queue - should not appear
8. Prime requests SIT extension
9. Check TOO queue - should appear
10. Check dest queue - should not appear

[brianmanley-caci]

So I have a question on this part. It seems like this allows them to use the column filter to filter by a move code that wasn't in the table. Is that the desired behavior? It seems kind of odd to me, but maybe that's what they asked for?

[traskowskycaci]

Great catch - pushing up a change now to address that.

[traskowskycaci]

Changed this here but broke a test - moving PR back to draft, will pick back up when I come back next week

[traskowskycaci]

That test was incorrect - the TOO shouldn't have the move appear in the queue after a payment request is created, it should appear in the TIO queue. However, the TOO can use the higher level move search instead of the move code queue search, so I updated the test to do so.

[brianmanley-caci]

Does this not apply to other origin services like IOPSIT, ICRT, IOSFSC?

[traskowskycaci]

Added here

[traskowskycaci]

Please ignore the move CRQST1 - it has only a destination address change and should be filtered out of the queue, but is hanging around for some reason. However, if you create a new move with only a destination address change - it is filtered out of the TOO queue correctly. I suspect the weird behavior is due to this being an old test move.

pinging those who I know have been taking a look - I updated the description with the above statement about ignoring CRQST1. @danieljordan-caci @brianmanley-caci @cameroncaci

[danieljordan-caci]

It's crazy how such little code changes can be so complex under the hood.

I tested a bunch of moves and it seems to be working well. Destination only shows up in the destination queue and not in the origin queue, destination address requests only show up in the destination queue if that's all there is...

Hope you're okay after doing this work

[traskowskycaci]

Hope you're okay after doing this work

Twas a rough one on me!