... | ... | @@ -5,6 +5,7 @@ |
|
|
* **<span dir="">Workflow</span>**<span dir="">: The workflow of “civicrm_generated.mysql” is tedious/onerous. It is prone to merge-conflicts and difficult to trace or patch.</span>
|
|
|
* **<span dir="">Ossification</span>**<span dir="">: Because it is difficult to maintain “civicrm_generated.mysql”, we avoid it - so many areas/topics have weak coverage in the sample data-set.</span>
|
|
|
* **<span dir="">D8/D9</span>**<span dir="">: If you use D8/D9, the default installation flow bypasses the install screen - it is highly unlikely that an evaluator/tester will discover that sample data is available.</span>
|
|
|
* **<span dir="">Default Types</span>**<span dir="">: CiviCase and CiviGrant both ship with default case/grant types which in practice are sample data ("Housing Support" and "Emergency Funds" are not generally applicable), but they are distributed as part of the core data (not the sample data set). That's not ideal, but both components are broken if no types are defined, so something would needed to prompt the user to create a grant/case type when enabling the component if it doesn't auto-create any (note: CiviGrant is [about to become an extension](https://github.com/civicrm/civicrm-core/pull/22064) which will change the install process)</span>
|
|
|
* **<span dir="">Extension Entities</span>**<span dir="">: There is no consistent approach to sample data for extensions (say, CiviVolunteer or Mosaico).</span>
|
|
|
* **<span dir="">Reproducibility/E2E</span>**<span dir="">: With RNG, a small change can bubble out to make a larger change in the overall sample data-set. It is therefore unreliable to use sample-data for E2E testing.</span>
|
|
|
* **<span dir="">POV/Tuning</span>**<span dir="">: Different evaluators/testers may have different interests (wrt #records, choice of locales+subsystems, minimal-vs-maximal use of config options). The use of a singular sample data-set makes it difficult to attune to all those interests.</span>
|
... | ... | |