dev/core#2773 Add an ACL to demo data

[eileenmcnaughton]

Overview

Add an ACL to demo data

Before

A lot of work to set up an ACL user to test something

After

An ACL is created for 'members in group Advisory Board can edit members in group Summer programme volunteers'. A contact 'Jenny Ling jenny@example.com' is added to the Advisory board group

Technical Details

In conjunction with a patch to buildkit we wind up with a user 'advisor' password 'advisor' who does not have permission to view all contacts

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

[colemanw]

This will be really helpful for testing.
And one more reason why we should stop advertising "Include demo data" as an option in our installer!

[totten]

🎉 for having some ACLs for test/demo purposes.

(@colemanw) And one more reason why we should stop advertising "Include demo data" as an option in our installer!

This statement confuses me. I agree that sample data has a list of topics/issues - and that checkbox might be rethought - but I disagree that advertising/visibility during install is specifically problematic. Some advertising/visibility seems necessary if you consider that the audience of evaluators/learners lack the depth/experience to dig-up more obscure options.

Anyway, rather than bat around abstractions a hypothetical list of issues, here's a draft wiki to brainstorm a concrete list:

https://lab.civicrm.org/dev/core/-/wikis/sample-data

[eileenmcnaughton]

@totten not strictly on sample data - but I have been wondering if we should have a separate 'dev install' in build kit - the things I'm thinking of are mostly settings (debug = on, environment = dev, escape by default = on) - which we would want to differ between our local environments and the evaluator demos - ie we want low tolerance on dev environments & low messiness on demos

[colemanw]

Thanks @totten I've added one more issue to the list in that wiki (case/grant types are weird)

[totten]

@colemanw Good one on case/grant types.

@eileenmcnaughton I agree it's an important distinction on default settings for local-dev and for evaluator-demo. FWIW, I've been using /etc/civicrm.settings.d/*.php to create files like this:

$GLOBALS['civicrm_setting']['domain']['debug_enabled'] = 1;
$GLOBALS['civicrm_setting']['domain']['backtrace'] = 1;
$GLOBALS['civicrm_setting']['domain']['mailing_backend'] = [
  'outBound_option' => 0, 
  'smtpServer' => 'localhost',
  'smtpPort' => 1025,
  'smtpAuth' => FALSE,
];

The big upshot is that it applies to any/all local builds (eg {wp,drupal,drupal8,backdrop}-{clean,demo}) - so you don't need to multiply #build-types ({wp,drupal,drupal8,backdrop}-{dev}). The big downside is that it doesn't present itself; you have to "discover" it by reading the manual.

(There are some other trade-offs. Edits to /etc/civicrm.settings.d go live instantaneously - and they survive rebuilds. There's no way to insert/modify entities. A handful of unit-tests are finnicky with common overrides - iirc JobProcessMailingTest gets upset if you override mailing_backend. )

the things I'm thinking of are mostly settings (debug = on, environment = dev, escape by default = on) -

• Yeah, I personally use debug_enabled and backtrace all the time.
• The current environment setting never clicked for me. (For me, environment=Development sounds worse than doing nothing. I have mailcatcher/mailhog which work nicely for isolating and logging mail. Setting environment=Development means that I would have to add runInNonProductionEnvironment=1 helter-skelter.)
• I can see the appeal of "auto-enlist developer-builds as guinea-pigs for $EXPERIMENTAL_SETTING_X=TRUE". I would acquiesce to this if (as one of the guinea-pigs) I still had an easy way to say, "oops, no, my system needs EXPERIMENTAL_SETTING_X=FALSE for now."

FWIW, I do see+like how the terms dev/demo/staging/prod/etc ("environment") help to explain some common patterns. Maybe we could link-up "environment", "civibuild", and "common default settings" with something like https://lab.civicrm.org/dev/core/-/issues/3020

[eileenmcnaughton]

@totten default modifiers is currently a define in civicrm.settings.php - the main reason for this as opposed to a setting is that I feel there is a track record for using defines for transitional things (where eventually we expect it to be 'how it is' rather than an option) - having said that I'm not uber-wedded to any approach - I just think it will quickly stabilise if most of us are using sites with it defined

[totten]

FWIW, the current civicrm.settings.d can be used for define() or $civicrm_setting - eg define(CIVICRM_MAIL...).