Setup UI - Validate that at least one "Component" is enabled

[totten]

Overview

Suppose an admin uses the "Setup UI" to perform installation - and disables all components. The behavior should be less crashy.

Before

The user is allowed to start the installation. It aborts mid-way through, leaving the system in an inconsistent state.

After

There are now two more guards:

• Server side: If one submits a request to install without any components, it will complain during the checkRequirements phase -- before installation begins.
• Client side: If one uses the "Setup UI" and disables components, the form will display an error and prevent submission.

Comments

This PR builds on #17749. It is not logically dependent, but it is technically dependent - because they both touch the list of <script> tags used on the "Setup" screen. Consequently, the list of commits is a bit long right now - this PR is really just the last three commits.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@totten is this 'ok-without-test'?

[totten]

@eileenmcnaughton Yeah, I think it's OK without a test.

Note that this PR is an offshoot of #17749 which @herbdool has r-run, and I don't think there are any blockers on the original PR. This PR only adds ~3 commits which are pretty squarely in the "Setup UI" - i.e. they're fairly isolated and unlikely to have knock-on effects in the runtime.

IMHO, the main test suite doesn't have a good harness for installer tests. However, we do have QA coverage of it by way of:

(1) implicit testing in CI (i.e. some CI builds rely on the same "setup" API)
(2) manual E2E testing of the installer during every release (ie "civihydra")

[eileenmcnaughton]

@totten I think this needs a rebase to eliminate most of the commits?

[totten]

@eileenmcnaughton Quite right. It's rebased now, so the commits are tidier.

[seamuslee001]

is this right?

[totten]

@seamuslee001 You're asking if the closure is properly formed? Well, $ seemed to bind correctly.

Note that the setup page doesn't have all the normal services of a Civi page, so we work from first principles. JS on the setup page loads like this:

<script type="text/javascript" src="http://dmaster.bknix:8001/sites/all/modules/civicrm/bower_components/jquery/dist/jquery.min.js"></script>
<script type="text/javascript" src="http://dmaster.bknix:8001/sites/all/modules/civicrm/setup/res/installer.js"></script>
<script type="text/javascript">
  window.csj$ = jQuery.noConflict();
</script>

Which means the JS file should be written in the style of a vanilla jQuery plugin.

Double-checking some other examples (jquery.jeditable.js, jquery.notify.js, jquery.tokeninput.js, etc), it seems more typical for vanilla-style jQuery plugins to take the input as jQuery. So on style grounds this snippet is a little off.

I'm pushing an update to make it clearer that this file works like a vanilla jQuery plugin.

[eileenmcnaughton]

test this please

@herbdool did you test this one too?

[eileenmcnaughton]

test this please

[herbdool]

I haven't tested this but I could try next week.

[eileenmcnaughton]

thanks @herbdool

[herbdool]

@eileenmcnaughton @totten PR works for me.

JS validation: all good. I get the error and cannot continue unless I select at least one component.

PHP validation: all good. I removed the JS and tested the process. It also gives me an error message.

[seamuslee001]

thanks @herbdool