Comments

edited

As a user of CALC, I want to look up labor categories by SIN prefix (not the entire SIN number) rather than the old schedule name, so that I can be confident that I am getting the current prices (since the recent data upload migrated the old schedules into one professional services schedule with SIN prefix replacing of the current and former schedule names).

For example, If I want to see all labor categories in FABS (former schedule name), then I should be able to filter all labor categories with SIN prefix of 520. I should also be able to do this for SIN prefix 132/IT 70 (current schedule name)

Acceptance Criteria

Scenario: Filters are adjusted so they show former (or current) schedule name, along with SIN prefix

This comment has been minimized.

edited

Hi @dsummersl! @KellyBailey would you answer this question for us? This seems like a product decision. Also @dsummersl it might help for you to file your pull request (even if it's incomplete) so we can better help out.

This comment has been minimized.

@dsummersl For all references to 541 or AIMS show Formerly AIMs. If it is an easy fix, can we use the term "Legacy" instead of "Formerly"? Disregard if it is too late at this point. I just noticed the use of the term Legacy on this page- http://www.gsa.gov/portal/content/246403, when researching the answer to your question. Thanks, Kelly.

This comment has been minimized.

@KellyBailey@mtorres253 I've made those two changes. I notice that my PR shows a three broken test cases...but I notice the three cases are all broken on the develop branch too when I test locally - do I need to fix these or are they some ongoing 'bulk test' related issue I can ignore? Went ahead and added a fix for one of them...but the two bulk tests are still broken.

I did a git bisect on the test_old_contracts_are_deleted test and got to here:

This comment has been minimized.

@toolness@KellyBailey The acceptance criteria for this story is that all tests pass but these seem to be broken on the development branch. Are you aware of that and is the team already working on that?

This comment has been minimized.

I just ran tests from the develop branch via docker-compose run app python manage.py ultratest and all tests are passing. They also appear to all be passing in the latest travis build of develop: https://travis-ci.org/18F/calc/builds/158492497

@dsummersl, how exactly are you running tests? We don't want develop to ever have broken tests, so I'd definitely like to figure out what's wrong. Sorry for the trouble!

This comment has been minimized.

Have you done a fresh docker-compose build? It looks like you just might be missing a package that was added to the requirements.txt sometime between when you originally built your docker containers and when you recently pulled.

This comment has been minimized.

@dsummersl another thing you might run into is that some tests will fail if you run docker-compose run app python manage.py ultratest while you also have a running docker-compose up in another terminal.

I'm not exactly sure why this is right now, but I think it is something to do with how the tests run the queued jobs synchronously while the app is running them normally/asynchronously.