Add fee or salary information to course offer pages

[avinhurry]

Context

In order to remind candidates what the fee or salary is for a course at the point they accept an offer (entering into a "contract"), we should repeat the information from Find within the offer page on Apply.

Changes proposed in this pull request

• Add the following columns to the TTAPI course sync: fee_details, fee_international, fee_domestic and salary_details

• Render Fees row which contains fee_international with fee_details (if fee_details is provided) alongside the amount and the fee_domestic on a new line if the international fee is not nil, otherwise only render the fee_domestic with fee details (if provided) on the same line.

• Render the Salary row if the course is salary or apprenticeship. This is just the salary_details column.

Guidance to review

• Does the logic make sense, is it what we want?
• I don't think it's possible for a fee paying course to have neither a fee_domestic and a fee_international so the if statement without the else should be ok, any thoughts or concerns?

Screenshots

Link to Trello card

https://trello.com/c/4vI0TOO1/4364-add-fee-or-salary-information-to-course-offer-pages-on-apply

Things to check

• If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
• This code does not rely on migrations in the same Pull Request
• If this code includes a migration adding or changing columns, it also backfills existing records for consistency
• API release notes have been updated if necessary
• Required environment variables have been updated added to the Azure KeyVault

[frankieroberto]

Logic looks good to me. I think some of the free text fields need to rendered with markdown.

Are you planning on plucking the migration out into a separate PR so that it can be shipped first, to avoid errors?

[avinhurry]

Logic looks good to me. I think some of the free text fields need to rendered with markdown.

Are you planning on plucking the migration out into a separate PR so that it can be shipped first, to avoid errors?

Thanks @frankieroberto, that's good feedback. I've made those changes. Yes we'll merge the migrations PR first in #6915 . Will leave it in this PR too for now so that we can review more easily.

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.77%	95.77%
⬆️	Branches covered	85.17%	85.31%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.78%	95.78%
⬇️	Branches covered	85.42%	85.11%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.78%	95.78%
⬇️	Branches covered	85.42%	85.32%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.78%	95.78%
⬇️	Branches covered	85.42%	85.32%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[stevehook]

This looks great. I've got one question inline about markdown rendering.

It all worked for me locally. I saw one slight glitch on a course that specified a UK fee but not an International one, there's an empty line between the fee and details:

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.79%	95.79%
⬇️	Branches covered	85.43%	85.31%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[github-actions]

Code Coverage

	Coverage type	From	To
↔️	Lines covered	95.79%	95.79%
⬇️	Branches covered	85.43%	85.31%

Line vs. Branch coverage

Branch coverage concerns itself with whether a particular branch of a condition had been executed.
Line coverage is only interested in whether a line of code has been executed.
This comes in handy for measuring one line conditionals.
eg.

          def do_something_with_even_numbers(number)
            return if number.odd?
            ...
        

If all the code in the method was covered you would never know if the guard clause was ever triggered with line coverage as just evaluating the condition marks it as covered.

[stevehook]

As discussed we think we should keep the markdown processing where it is so the idea of moving it to the course sync only makes sense if we run into performance issues.