Made it easier for less technical users to switch REDCap versions

[mmcev106]

@aldefouw, this is a great example of a tiny change that really simplifies things for less technical users. Ellis is comfortable running commands but not as comfortable editing JSON configuration files. I think this change would make it easier for users like him to change REDCap versions, and hopefully figure out how to do so on their own. What do you think?

[aldefouw]

@mmcev106 - Thanks, Mark! I agree this needs to be easier and can understand that some people do not want to deal with setting environment variables.

I'm definitely onboard with the idea of updating the cypress.env.json through a script - but I have a few thoughts.

If our overall goal is to make it easy for anyone to change REDCap version in Cypress ... would it possibly make more sense to write a "Change REDCap Version" script ... e.g. change_redcap_version.sh ... ?

Such a script would:

• Ask you for the version you want to test against ... something like: "What version of REDCap do you want to test in Cypress?"
• Changes the cypress.env.json to reflect the appropriate redcap_version
• Check to see if that specified REDCap version's source code is already present
• If source code is NOT present, you could even prompt to download that version - perhaps script could call download_redcap.sh in that condition?

To come full circle, we could conversely adjust download_redcap.sh to pair with change_redcap_version.sh in the opposite direction.

For example ... in download_redcap.sh ...

• After downloading REDCap version, prompt user: "Do you want to change the version of REDCap you are testing in Cypress?"
• If so, run change_redcap_version.sh
• If affirmative, we could say "REDCap version is changed to X.Y.Z in cypress.env.json" or something like that. Otherwise, we'd leave that version alone.

Here are some reasons why I think this makes sense as separate scripts:

• offers flexibility to change a version without downloading REDCap (you might already have the REDCap version - so running download_redcap.sh - at least to me - is counter-intuitive )
• offers possibility of downloading a version of REDCap without changing the version you are testing

I think having the verbs that are baked into the name of the script describe the behavior of what you're doing makes a lot of sense to me - but it's possible not to others.

That said, if you like the above proposal, feel free to create / adjust the scripts as described above in your feature branch and push them - I'd be happy to pull that modified request in.

Otherwise, if you think it should be left to just the download_redcap.sh like you are proposing, here's something I'd request: in that case, can we retain the instructions in README.md for changing REDCap version in the cypress.env.json?

I think if we don't have a script to change the version, we still need documentation indicating what drives the actual version of REDCap being tested in Cypress - so I wouldn't feel comfortable removing that without a specific script to change the version.

Let me know if you need any clarifications or have any questions. Thanks!

Side note: Someone else actually recommended a very similar change in a different PR: https://github.com/aldefouw/redcap_cypress_docker/pull/2/files

I was very close to pulling it in but I never got a chance to test it. What I'm proposing is essentially a combination of what you're suggesting and what he's suggesting - with the nuance that I'm also proposing a new script that just changes REDCap version.

[mmcev106]

@aldefouw, one of my biggest goals here was to reduce the number of steps required. Are you saying there is a scenario where someone would want to download a REDCap version without setting it as the version used to test?

[aldefouw]

@mmcev106 - That scenario is rare for most - but it's a scenario that I use to update the redcap_source code in preparation for a new version that will be put under test. I'll push the version ahead of changing my local cypress.env.json so that CircleCI won't barf when we start doing tests against it.

If you want to ignore that scenario, fair enough ... I can work around it because I know the tools.

The scenario I'm more concerned about is the one where someone cannot download REDCap from the community site because they do not have an account. This is a real scenario that many people encounter who work on this project.

If we're asking them to use download_redcap.sh to change the REDCap version - but they cannot get to that part of the script because I think it's nested in the authentication portion - and there is no documented method to do so outside of that file, isn't that problematic?

I'm fine with us using download_redcap.sh to adjust the REDCap version ... what I'm less certain about is the removal of documentation about how to change redcap_version outside of download_redcap.sh.

[aldefouw]

@mmcev106 - Thought about this last night after hours.

Here's how we'll proceed:

1) I will approve this request. I understand your approach, I think it does reduce the steps, and I want you to be able to complete your tasks and help other people get onboarded with minimal effort. I will prioritize your efforts and ideas ahead of others right now.

2) We do need to address how users who do not have REDCap community accounts download REDCap (and how they change their REDCap version in Cypress); however, I'll create a separate issue so we can circle back to it later - putting this in a parking lot here: Right now, we'll prioritize the efforts you are directing.

[mmcev106]

Thanks @aldefouw. I really do believe prioritizing the happy path is important if we want to encourage less technical users to participate as much as possible. We can of course have many side roads, but it will pay dividends to widen the main road, keep it clear, well marked, and generally prioritized.