Enable the "sequentialcreditnotes" extension on new installations

[eileenmcnaughton]

Overview

Adds install for our new prototype Core Extension

Before

New Core Extension sequenttialcreditnotes added on upgrade but not on install

After

Added on install

Technical Details

Per @totten there are some good future-thinking ways to address this issue of how to
install extensions on install. For now however, this should work & achieve our short-term goal

Comments

[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).

[totten]

1. Probably need to run regen.sh so that dev/test sites get an updated civicrm_generated.mysql.

2. I think this is a fairly clever work-around and sounds pretty plausible for the sequentialcreditnotes scenario.

An observation (probably obvious for you and me - but maybe not for all readers)... this bypasses the normal lifecycle functions (install/enable/upgrade) of an extension. As it stands, for sequentialcreditnotes, that's OK - because this extension doesn't currently use those. And I see the appeal in un-blocking this aspect of sequentialcreditnotes.

There was a voice in the back of my head that worried about this as a precedent / example - e.g it doesn't work for the General Case of activating an extension during install, but it will be the only example on record, so Future Code Reader will use it as a reference-point. They'll think, "this stuff is working and I can see how!", start on a path to adding another extension, imitate the example, and be surprised when it doesn't work for their (qualitatively-different) extension - at which point their easiest option will be to ignore the extension lifecycle and somehow hotwire the core lifecycle with the extension lifecycle. God forbid, they might even rationalize it as a feature. ("Well of course a core-extension gets a different lifecycle!...") And then we won't be able to reason about "extensions"... we'll have to reason about "regular-extensions" vs "core-extensions". Let's please keep the contracts for "extensions" consistent. 😅

But I digress.

Perhaps we can head this off with some comments in-situ? e.g.

-- Auto-install the special extension "sequentialcreditnotes". 
-- This technique only works because sequentialcreditnotes is relatively small and does not require any installation logic.

[eileenmcnaughton]

@totten I would hope given all the docs we have on extensions people would follow those rather than copy what is in a core folder - if not there is only so much we can do to save people from themselves. Once the tags thing is resolved I'll add a note to the docs clarifying that coreextensions are about being able to separate add-on-core functionality into separate features for code management & are not the template for extensions

[totten]

@eileenmcnaughton So I gave this a light r-run locally to see if the extension was activated, and it wasn't - and it was still an issue with civicrm_generated.mysql.

What was up with that? The issue is inregen.sh, which has a list of certain tables which should not be based on the local-data at time of execution (incl civicrm_cache, civicrm_setting, civicrm_extension). IIRC, these are based in historical incidents wherein someone ran regen.sh locally and wherein local settings inadvertently leaked into other dev sites.

e98ed87 carves a narrow allowance for sequentialcreditnotes.

Now, when I do a civibuild reinstall dmaster, it does appear to end with the ext active:

[bknix-max:~/bknix/build/dmaster/web/sites/all/modules/civicrm] cv ext:list /credit/
Using extension feed "https://civicrm.org/extdir/ver=5.24.alpha1|uf=Drupal|status=stable|ready=ready"
+----------+-----------------------+-----------------------+---------+-----------+-------------+
| location | key                   | name                  | version | status    | downloadUrl |
+----------+-----------------------+-----------------------+---------+-----------+-------------+
| local    | sequentialcreditnotes | sequentialcreditnotes | 1.0     | installed |             |
+----------+-----------------------+-----------------------+---------+-----------+-------------+

[totten]

Regarding tests... it might help to state the intended behavior. My guess from the file-structure is that one would want:

• For the core headless suites in civicrm/tests/phpunit/{api,CRM,Civi}, the sequentialcreditnotes extension should not be active.
• For any tests in civicrm/ext/sequentialcreditnotes/tests, the extension sequentialcreditnotes should be active.

The CI reports a failure in api_v3_PaymentTest.testRefundPayment. Is this because the extension is (contrary to desire) active during the execution of tests/phpunit/api?

[eileenmcnaughton]

@totten no the expectation is this extension would be active for all tests - core extensions are still core (they can be disabled but that is not part of what we are testing).

I'm not sure why the test is failing - I will rebuild locally with your change & test

[eileenmcnaughton]

OK - the bug was because I switched to api v4 & missed the setPermissions(FALSE) but looks good now

[eileenmcnaughton]

@totten passing now

[seamuslee001]

This looks fine to me now @totten @eileenmcnaughton

[eileenmcnaughton]

cool

[eileenmcnaughton]

did we get the tests running on it @totten @seamuslee001 ?