Fix(create_template)

[sbreitbart-NOAA]

The impetus

• [Bug]: create_template rda issue #144

What is the feature?

• Fix create_template so that rda files can be added as input, if already created, OR generated if model results are included as an argument.
• Update documentation

How have you implemented the solution?

• in create_template, changed the exp_all_figs_tables() rda_dir argument from subdir to rda_dir. This changes the workflow so that the rda_files folder is always placed in rda_dir, not in the report folder. The issue was that the captions_alt_text.csv file was always being created in rda_dir, but exp_all_figs_tables() within create_template() was breaking because captions_alt_text.csv wasn't ever within the "report" folder. I chose to keep the rda_files folder in the rda_dir, instead of the report folder, because sometimes the user will be providing their own rda_files folder, and I wanted to keep the workflow consistent among users that did and did not provide their own rda_files folder.
• altered create_tables/figures_doc() calls in create_template so that rda_dir is always rda_dir (updated to match the change that the rda_files folder is always placed in rda_dir, not in the report folder.)

Does the PR impact any other area of the project, maybe another repo?

• create_tables_doc() & create_figures_doc() calls in create_template

Tested?

• Tested with:
  • an SS3 model result csv
  • BAM model result csv
  • empty create_template() call
  • a create_template call with convert_output = T and model_results = Report.sso

[github-actions]

Instructions for code reviewer

Hello reviewer, thanks for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete!
• For PRs that don't make changes to code (e.g., changes to README.md or Github actions workflows), feel free to skip over items on the checklist that are not relevant. Remember it is still important to do a thorough review.
• Then, comment on the pull request with your review indicating where you have questions or changes need to be made before merging.
• Remember to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
• PR reviews are a great way to learn, so feel free to share your tips and tricks. However, for optional changes (i.e., not required for merging), please include nit: (for nitpicking) before making the suggestion. For example, nit: I prefer using a data.frame() instead of a matrix because...
• Engage with the developer when they respond to comments and check off additional boxes as they become complete so the PR can be merged in when all the tasks are fulfilled. Make it clear when this has been reached by commenting on the PR with something like This PR is now ready to be merged, no changes needed.

Checklist

• The PR is requested to be merged into the appropriate branch (typically main)
• The code is well-designed.
• The functionality is good for the users of the code.
• Any User Interface changes are sensible and look good.
• The code isn’t more complex than it needs to be.
• Code coverage remains high, indicating the new code is tested.
• The developer used clear names for everything.
• Comments are clear and useful, and mostly explain why instead of what.
• Code is appropriately documented (doxygen and roxygen).

[Schiano-NOAA]

Looks good to me. The change seems pretty straight forward