Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-06-28T22:02:47Zhttps://lab.civicrm.org/dev/translation/-/issues/3'minimal' subset of localized strings2020-06-28T22:02:47Zcividesk'minimal' subset of localized strings10% of strings are probably accounting for 90% of displayed text in CiviCRM - the rest are error messages or other help text that is rarely seen. Identify this subset of strings, and then structure Transifex so it's easy to translate thi...10% of strings are probably accounting for 90% of displayed text in CiviCRM - the rest are error messages or other help text that is rarely seen. Identify this subset of strings, and then structure Transifex so it's easy to translate this 'minimal' subset. This should very significantly facilitate translation of CiviCRM in new languages AND help in improving existing translations.https://lab.civicrm.org/dev/core/-/issues/3534Simplify the settings for filesystem paths2022-06-11T16:35:32ZxurizaemonSimplify the settings for filesystem paths* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)...* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)
* Caching generated content there means potential for info leakage or execution via input variables
* Filesystem caching can be inefficient compared to other caches
* Herb has done work to get Smarty caching via Redis?
* https://www.drupal.org/node/2570335
* https://forum.civicrm.org/index.php?topic=35125.0;nowap
* https://issues.civicrm.org/jira/browse/CRM-17401
* https://github.com/freeform/civicrm-drupal-pantheon/blob/4.6.x/patches/smarty-redis-civi-cache.patch
* would Smarty 2 choke if we just set the path to redis:// ?
* .php extension is [tacked on here](https://github.com/civicrm/civicrm-packages/blob/master/Smarty/Smarty.class.php#L1512), may be other places to change thishttps://lab.civicrm.org/dev/core/-/issues/3535Does CiviCRM allow us to declare which directories are writable, allowing the...2022-06-11T14:45:00ZherbdoolDoes CiviCRM allow us to declare which directories are writable, allowing the rest to be locked-down?CiviCRM core seems to be consistent in only writing to a files directory. Until recently, however, it attempted to write to the extensions directory to store extension updates. It's unclear if CiviCRM enforces this for extensions. I've h...CiviCRM core seems to be consistent in only writing to a files directory. Until recently, however, it attempted to write to the extensions directory to store extension updates. It's unclear if CiviCRM enforces this for extensions. I've heard that some extensions will write to directories outside of the files (but I haven't been able to confirm this). If that's the case then it will conflict with PAAS that only allow certain directories to be writable.https://lab.civicrm.org/dev/core/-/issues/3524Does CiviCRM make it possible to specify which directories are private and wh...2022-06-11T14:42:36ZherbdoolDoes CiviCRM make it possible to specify which directories are private and which are public-accessible?This is currently not possible in CiviCRM. A PAAS like Pantheon provides a specific folder for private file uploads and we can't change it to any other folder. However, CiviCRM assumes that the site is either running on Apache (and it ca...This is currently not possible in CiviCRM. A PAAS like Pantheon provides a specific folder for private file uploads and we can't change it to any other folder. However, CiviCRM assumes that the site is either running on Apache (and it can use .htaccess files) or that custom NGINX rules can be set. This is an unreasonable expectation.
CiviCRM requires some filepaths to be private and will complain if they're not configured properly: https://civicrm.org/advisory/civi-sa-2014-001-risk-information-disclosure
CiviCRM has hardcoded the filepaths of some things based on the path of CIVICRM_TEMPLATE_COMPILEDIR. The problem is that CIVICRM_TEMPLATE_COMPILEDIR needs to be private but many of the files that CiviCRM is trying to write based on that path need to be publicly available (e.g. dynamically written JS).
An audit of both baseFilePath() and CIVICRM_TEMPLATE_COMPILEDIR:
[audit-template_compiledir.txt](/uploads/9302db5820d0af0181edf9990fd47b90/audit-template_compiledir.txt).
Tim provided some technical guidance in another thread https://lab.civicrm.org/dev/cloud-native/issues/1#note_3124:
> - The references to `baseFilePath()` in `CRM_Utils_System_*` should become irrelevant if `civicrm.settings.php` has the `$civicrm_paths['civicrm.files']`
>
> - The references to `baseFilePath()` in `CRM_Utils_File::absoluteDirectory` and `::relativeDirectory` already appear to be irrelevant within `civicrm-core`. (The only usage I could find was one which explicitly set its own base.)
>
> - The reference to `baseFilePath()` in `CRM_Core_Config_Runtime` is more effort. I don't know if it'd work, but my first try would be (a) lookup a path-variable like `Civi::paths()->getVariable('civicrm.log', 'path')`, (b) declare the variable in `Civi\Core\Paths`, (c) change the relative boot order of `Civi\Core\Paths` and `CRM_Core_Config_Runtime`.
>
> - I think `CRM/Utils/Cache/SerializeCache.php` is unused.
>
> - The `CRM/Core/IDS.php` line feels silly. We should pick one folder! Pointing that at `templates_c` makes as much sense as `uploadDir`. (TBH, I'm not sure does anything now that `Config.IDS.ini` has been killed.)
>
> - `Civi/Core/Container.php` and `CRM/Extension/ClassLoader.php` are very similar to the Smarty use-case (i.e. writing out ephemeral PHP files to take advantage of opcode caching).https://lab.civicrm.org/dev/core/-/issues/3536[META] Does CiviCRM make it easy for all connection-related configuration to ...2024-02-10T05:03:26Zherbdool[META] Does CiviCRM make it easy for all connection-related configuration to be provided via environment variables: database credentials, key-value database credentials, filesystem, and so on?It is possible by editing civicrm.settings.php to inject the environment variables.
I'm wondering if a more generic framework might be useful where CiviCRM provides some boilerplate for what strings are required from the environment va...It is possible by editing civicrm.settings.php to inject the environment variables.
I'm wondering if a more generic framework might be useful where CiviCRM provides some boilerplate for what strings are required from the environment variables.
This could help since there is so much repetition of variables that need to be assigned.
----
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/12
* https://lab.civicrm.org/dev/cloud-native/issues/7
* https://lab.civicrm.org/dev/cloud-native/issues/8https://lab.civicrm.org/dev/core/-/issues/3530[META] Does CiviCRM make it easy to install without using the UI?2024-02-08T05:03:21Zherbdool[META] Does CiviCRM make it easy to install without using the UI?Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow...Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow for builds we may need to be able to point CiviCRM to a file with the env vars and then install fresh. And may need to override the default behaviour of CiviCRM showing errors when it finds a civicrm.settings.php already.
---
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/7
* https://lab.civicrm.org/dev/cloud-native/issues/8https://lab.civicrm.org/dev/core/-/issues/3528[META] Does CiviCRM make it easy to provide the absolute system path at runti...2024-02-08T05:03:20Zherbdool[META] Does CiviCRM make it easy to provide the absolute system path at runtime from the environment rather than hardcoded in a file?In CiviCRM 4.7 this seems to be mostly solved but issues keep cropping up now and then. The environment variables can be specified in the settings file. In CiviCRM 4.7.25 it finally got rid of the hardcoded absolute path in Config.IDS.in...In CiviCRM 4.7 this seems to be mostly solved but issues keep cropping up now and then. The environment variables can be specified in the settings file. In CiviCRM 4.7.25 it finally got rid of the hardcoded absolute path in Config.IDS.ini. Most recently I've noticed some hardcoded paths in civicrm_cache where group_name = js_strings. It's unclear if the cache is regenerated if the paths cannot be found. Even better would be to avoid saving the full path.
----
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/12
* https://lab.civicrm.org/dev/cloud-native/issues/14
* https://lab.civicrm.org/dev/cloud-native/issues/15
* https://lab.civicrm.org/dev/cloud-native/issues/16https://lab.civicrm.org/dev/core/-/issues/3533Rewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.2024-02-09T05:03:20ZtottenRewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`...## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`, `extern/rest.php`, or `extern/cxn.php`. More broadly, *all test suites and CLI processes* use a standalone bootstrap script. (These entry-points are distinct from the front-end entry-points typically associated with the UI.)
There are a number of technical details and happenstance we can go into, but there are two fundamental nubs in writing and executing a standalone script:
* *It doesn't know which CMS is active.* There's usually some *hard-coding* to the find the CMS.
* *Bootstrapping the CMS adds overhead.* Many admins have written-off this consideration as cost of doing business - but for someone, somewhere, at some point it mattered.
## Background: `civicrm.config.php` protocol
The original protocol for standalone bootstrap originated many years ago (circa 1.x or 2.x?). It's still used in several cases. It's key design elements:
* `civicrm.config.php` is *generated* at build-time to match the CMS. The tarball/zipball for each CMS includes a different build of this file. It's main purpose is to locate `civicrm.settings.php`.
* `civicrm.settings.php` includes a `define` for the `CIVICRM_UF` (among many others).
* `CRM_Utils_System::*` includes functions like `loadBootStrap()`.
* __Original protocol__: A standalone script would include `civicrm.config.php`, which would locate the `civicrm.settings.php` using a CMS-specific search. It then boots Civi by loading `civicrm.settings.php` and calling `CRM_Core_Config::singleton()`. Optionally, it also boots the CMS by calling `CRM_Utils_System_*::loadBootStrap()`.
The original boot protocol has some major consequences -- for example:
1. It requires creating an extra settings file (`civicrm.settings.php`) on every build.
2. Depending on how the page-load starts, the Civi settings file and CMS settings may load in different orders. It's not valid to infer Civi settings based on CMS settings (and vice-versa).
3. You need to figure the *absolute or relative* path of `civicrm.config.php`. This is *possible* in `civicrm-core` -- but it's basically impossible with any other publishable deliverable.
4. Reading/understanding the boot protocol requires having multiple builds of Civi (one for each CMS) -- *that's the only way to see each version of `civicrm.config.php`.
## Background: `cv` bootstrap protocol
A few years ago, I combined the various `civicrm.config.php` files with the aim of producing a universal boot script that solved `#3` and `#4`. This produced https://github.com/civicrm/cv/blob/master/src/Bootstrap.php which eventually became the heart of the `cv` command. This endeavor preserved a bunch of assumptions from the original protocol... but it made a key change: *dynamically discovering* the boot info.
The dynamic discovery works a bit like this:
* Do a file-system search (from PWD) to figure out the CMS.
* Do a file-system search (from CMS dir) to figure out where `civicrm.settings.php` is.
* Unless... you really want a faster bootstrap. Then you can set an environment variable with your boot info (and bypass the searches).
IMHO, dynamic CMS discovery (with optional env-var for optimization) is a pretty good way to make the code more robust to deploying in a variety of environments and file-structures.
There's just one problem: the *implementation* grew out of `civicrm.config.php` and kept some of the assumptions, so the implementation still shares issues `#1` and `#2`.
## Proposal: Provide a universal, CMS-first bootstrap script -- and knock over some dominoes
The basic idea is to write a CLI helper which bootstraps the CMS first -- and then bootstraps Civi. The logic is roughly:
```php
function boot($startDir) {
$parentDirectories = array($startDir, parent($startDir), grandparent($startDir), ...);
foreach ($parentDirectories as $dir)
if ($dir has Drupal) { bootDrupal(); bootCivi(); return; }
elseif ($dir has Joomla) { bootJoomla(); bootCivi(); return; }
elseif ($dir has WordPress) { bootWordPress(); bootCivi(); return; }
elseif ($dir has Backdrop) { bootBackdrop(); bootCivi(); return; }
}
}
```
This helper still provides standalone bootstrap, so we can still have all our standalone scripts/unit-tests/commands/etc. But it makes a fundamental change:
* **You can always rely on having the CMS bootstrapped first**.
* Therefore, you can detect things like `CIVICRM_BASEURL` using CMS API's -- because they're always available.
* Therefore, you don't need `civicrm.settings.php` to store those settings.
* Therefore, you don't need `install/index.php` to create `civicrm.settings.php`.
* Therefore, you don't need write-access to create `civicrm.settings.php` (in the typical case).
* Therefore, you don't need to migrate or preserve `civicrm.settings.php` (in the typical case).
*Note: Of course, the entire CiviCRM install-base currently uses `civicrm.settings.php`, and some of them use it to accomplish special ends (like custom multidomain/multisite/multitenant arrangements). Therefore, I wouldn't argue for complete removal of the file -- but, instead, it should be an optional/advanced thing.*
## General Tasks
* Write the new bootstrap script.
* Phase-in the new bootstrap script for use by `cv` and `civicrm-core`.
* Update `civicrm-core` to compute values for all those constants (`define('CIVICRM_FOO',...)`) at runtime using CMS functions.
* Update the installer to omit `civicrm.settings.php`
* Update docs to describe the advanced/optional use of `civicrm.settings.php`.https://lab.civicrm.org/dev/core/-/issues/3525Move example data to an optional/add-on step2024-02-07T05:03:27ZtottenMove example data to an optional/add-on stepDuring installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generat...During installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generated.mysql`.
This has some consequences:
* You must choose whether to load sample data during *installation*. This is presented in the installer UI.
* The `civicrm_generated.mysql` takes extra work to maintain (eg `bin/regen.sh`; the output of which is not merge-friendly).
The goal here would be to have one *installation* process -- which could be headless. *Afterwards*, you should have the *option* to enable create the sample data. This *option* may be specified as at same time as other install parameters (eg via arg) or perhaps via a separate command afterwards.https://lab.civicrm.org/dev/core/-/issues/3529Does CiviCRM work well with database replication and clustering?2022-06-11T14:44:13ZdavejDoes CiviCRM work well with database replication and clustering?There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 20...There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 2017 eileen:
> We have been having some replication lag issues & one metric we are investigating is the slaves (only) seem to show a large number of open temp tables on one metric. The odd thing about the replication lag is it seems to get worse the longer since a server restart (presumably just the mysql part needs to be restarted).
10 Oct 2017 jackrabbithanna:
> Ok we're dealing with Percona DB
>
> Database Error Code: Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions., 1787
>
> followed by a php error: Fatal error: Uncaught CRM_Core_Exception: [0: Transaction integrity error: Expected to find active frame thrown
>
> Per https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html the multi-statements transactions are not allowed as they could potentially run using the same global transaction ID (GTID)
>
> this error happens when trying to create a Drupal user, with CiviCRM profile on the form
Further comments from Eileen:
> OK - I'll have a read of that - the CiviCRM usage of temp tables is pretty common & in particular ties in with the way mailing recipients are calculated & rolled back. However, I'm also reading concerns that replicated DBs don't like temp tables (although it's not blocked in the version we have)
>
> (we use mixed mode replication)
>
> I think it's kind of a big picture question isn't it? I had thought to move all temp table creations to a single function (so if we want to do something different we can do it in there) - the thing is a lot of them are used to calculate group_contact_cache & those will cause rollback to fail
> "A recommended practice when using statement-based or mixed-format replication is to designate a prefix for exclusive use in naming temporary tables that you do not want replicated, then employ a --replicate-wild-ignore-table option to match that prefix. For example, you might give all such tables names beginning with norep (such as norepmytable, norepyourtable, and so on), then use --replicate-wild-ignore-table=norep% to prevent them from being replicated." - we could at least do that for reports etc
> if you are using statement based replication or mixed replication then any temp tables used to build real tables have to be replicated
>
> or else the query will fail on the slave
> it's an improvement basically 'make civicrm support replication'
> it does work with replication but I think that's more because various people have just configured it to do so
>
> but I don't think there has ever been any official support for that or effort to understand the design implications
13 Oct eileen:
> ... our replication issue DOES seem to be related to the temp tables created for civimail at this stage. ... What we are seeing is the DROP statement is written to the binlog BEFORE the create statement is - somewhat in line with https://www.xaprb.com/blog/2007/01/20/how-to-make-mysql-replication-reliable/
>
> (not really clear from there but it says "As I mentioned, each transaction goes into the binlog in the order in which it commits, not in the order in which it is started, so transactions may execute in a different order on the replica. ")
>
> the binlog is parsed on the slaves & they temp tables mount up
>
> not 100% sure if this will solve all our woes - but not letting civicrm use temp tables to create recipient lists seems to be important
We ran a bunch of Civi sites with MySQL replication several years ago and had a lot of problems with it: replication would fall over periodically and then everything would grind to a near standstill as it was re-sync'd.
As a starting point, it would be useful to gather some data on how many people use replication / clustering with Civi, how frequently problems are encountered, what the most common problems are and whether they have been solved.https://lab.civicrm.org/dev/release/-/issues/15.x - Update version-numbering pattern2018-08-17T00:17:24Zcolemanw5.x - Update version-numbering pattern## Tasks
* [x] `civicrm.org` - Update extension validation to accept 4.7 as synonym for 5.x
* [x] `civicrm.org` - Update extension validation to allow forward compatibility within 5.x series
* [x] *Upgrader* and `set-version` - Allow on...## Tasks
* [x] `civicrm.org` - Update extension validation to accept 4.7 as synonym for 5.x
* [x] `civicrm.org` - Update extension validation to allow forward compatibility within 5.x series
* [x] *Upgrader* and `set-version` - Allow one to easily increment middle digit
* [ ] [doc](https://lab.civicrm.org/development-team/Release-Management/tree/master/doc) - Update RM docs
* [x] `5.x-rc.md`
* [x] `5.x-final.md`
* [x] `5.x-patch.md`
* [x] `test.civicrm.org` - Assess/update CI:
* [x] `civi-test-run`
* [x] `civibuild upgrade-test`
* [x] https://test.civicrm.org/job/CiviCRM-Core-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-Ext-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-WebTest-Matrix/
* [x] https://test.civicrm.org/job/CiviCRM-Core-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Backdrop-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Drupal-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Packages-PR/
* [x] https://test.civicrm.org/job/CiviCRM-Publish/
* [x] https://test.civicrm.org/job/CiviCRM-Publish-Watch-Core/
* [x] http://download.civicrm.org/latest - Display multiple autobuilds/pre-releases simultaneously
* [x] `civicrm-core` - Trial run, using installer/upgrader/distmaker/test-suite on v5.0
* [x] `civicrm-core` - Update various copyright headers from "4.7" to "5.x".
* [ ] `civicrm-drupal` - SPECME: The *.info files are set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these?
* [ ] `civicrm-wordpress` - SPECME: The `civicrm.php` file is set to 4.7 and twiddled on release. For git-based deployments, should we do anything to maintain these?
* [ ] *Extension author outreach* - Grep universe for READMEs/docs. Send mail-blast with suggested updates.
* [ ] `civicrm-core` - The file `js/crm.angular.js` has a function with a "remove me" notice
* [x] `docs-publisher` - https://lab.civicrm.org/documentation/docs-publisher/merge_requests/87
* [x] `civicrm-sysadmin-guide` - https://github.com/civicrm/civicrm-sysadmin-guide/pull/75
## FAQ
__Q: Would it be better to say `v4.8.0` vs `v5.0.0` vs `v5.1803.0` vs `v18.3.0` vs `v33.0.0`?__
They're all basically the same. All of these options will give *someone* the heebeegeebees -- because we've been doing 4.7.x for two years, and anything that looks different will look different, and different is scary.
The fundamental message should be this:
* The change in number is superficial.
* The substantive editorial/QA regime for `v5.{$Y}.0` is (initially) the same as the previous `v4.7.{$Z}`.
* The new numbering makes it to easier to administer minor patch updates, enabling us to consider more fine-tuned maintenance regimes.
There are bikesheddy reasons to favor one or another.
__Q: But I think there should be substantive change!__
Grand! Please head over to #2 to weigh-in on proposals or add new ones! (Or, if you want to focus-in on the [main review criteria](https://docs.civicrm.org/dev/en/latest/standards/review/), feel free to open a pull-request in [civicrm-dev-docs](https://github.com/civicrm/civicrm-dev-docs).)
__Q: Does this mean you're going to start making more, bigger, scarier changes more often?__
No. This is strictly a superficial realignment of the numbers. In fact, the general tenor of editorial policy has been toward tightening rather than loosening standards.
https://lab.civicrm.org/dev/core/-/issues/3537Does CiviCRM handle UNIX filesystem functionality like symlinks?2024-02-10T05:03:27ZxurizaemonDoes CiviCRM handle UNIX filesystem functionality like symlinks?Some cloud hosting providers dynamically assign storage (disk) and may use symlinks to associate dynamic storage with predictable filesystem locations. CiviCRM seems to be confused by the presence of symlinks in the CiviCRM install path ...Some cloud hosting providers dynamically assign storage (disk) and may use symlinks to associate dynamic storage with predictable filesystem locations. CiviCRM seems to be confused by the presence of symlinks in the CiviCRM install path (and possibly resource paths).
This manifests as "weird" resource URLs or inability to resolve filesystem paths.
> This doesn't work in all configurations. For example, if your directory structure uses symlinks, it may not resolve correctly.
For examples, https://civicrm.stackexchange.com/search?q=symlink eg
* https://civicrm.stackexchange.com/questions/19495/set-civicrm-files/19498#19498
* https://civicrm.stackexchange.com/questions/20064/help-needed-in-setting-up-rest-api-in-civi-crm/20076#20076
* https://civicrm.stackexchange.com/questions/20265/mailchimp-plugin-creating-webhook-with-invalid-url
* https://civicrm.stackexchange.com/questions/21925/incorrect-resource-url-warning-but-menu-arrows-are-present
For WP specifically, https://github.com/civicrm/civicrm-core/pull/11086https://lab.civicrm.org/dev/financial/-/issues/1On new contribution, when priceset chosen remove 'Alternatively, you can use ...2020-05-27T13:21:37ZJoeMurrayOn new contribution, when priceset chosen remove 'Alternatively, you can use a price set.'On backoffice new contribution screen, there is on screen help text under Total Amount field saying 'Alternatively, you can use a price set.' Clicking button to choose a price set incorrectly leaves the text there after the price set is ...On backoffice new contribution screen, there is on screen help text under Total Amount field saying 'Alternatively, you can use a price set.' Clicking button to choose a price set incorrectly leaves the text there after the price set is displayed. Clicking the Price Set field toggles to make it disappear even if the selection is 'Choose price set' which removes price set.
Fix to display this text when price set is not (yet) selected, and to hide it when a price set is selected.Monish DebMonish Deb2018-02-07https://lab.civicrm.org/dev/release/-/issues/2Brainstorm: Little Ideas for QA2018-04-19T03:15:34ZtottenBrainstorm: Little Ideas for QAThis issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. ...This issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. For purposes of this issue, humor me. Suppose there's a realistic budget -- like a week of senior developer/designer/documenter/administrator time. What process change could they perform that might make a dent at improving QA? Perhaps something that makes PR review more thorough? Or perhaps it improves engagement with RCs? Or perhaps it lowers the barrier to testing?
Please post one idea per comment. If you like or dislike an idea, put a thumbsup or thumbsdown emoji on the comment. To discuss the idea in more depth, ping the commenter on Mattermost (https://chat.civicrm.org under `dev`).
------
Emojis:
* :thumbsup_tone1: - Good idea. Simple, clear steps. Would probably improve quality. Achievable within budget.
* :thumbsdown_tone1: - Bad idea. Wouldn't improve quality.
* :8ball: - Don't really want to judge. It sounds good, but it's not simple enough or not clear enough or too long. Maybe if the idea was refined more.
* :baby_chick: - The comment is conversation.https://lab.civicrm.org/dev/core/-/issues/3305Allow overriding membership status temporarily until specific date2022-04-22T16:16:26Zomar_compucorpAllow overriding membership status temporarily until specific date## Overview
Improving membership status override to provide extra options to allow temporary status override.
## Details
Instead of having a checkbox called (Override Status?) in membership add/edit/renew form, it will be replaced wi...## Overview
Improving membership status override to provide extra options to allow temporary status override.
## Details
Instead of having a checkbox called (Override Status?) in membership add/edit/renew form, it will be replaced with a select box that allow the user to choose one of three options :
1- No
2- Override Permanently
3- Override until selected date
- If the first option is selected, then the membership will behave as if the old (Override Status?) is **unchecked**, which means that the membership is subject to membership status rules.
- If the 2nd option is selected, then the membership will behave as if the old (Override Status?) is **checked**, which mean that the membership status is overridden and is not subject to the membership statues rules.
- If the 3rd option is selected, then a new field will appear allowing the user to choose a date, in this status, the membership will behave similar to option 2, but when today date is equal or less than the selected date, then the "Update Membership Statuses" scheduled job will automatically convert its status back to **No**, which means that the membership status is overridden temporarily only for the selected date and after that it will revert back and be subject to membership status rules
## Mocks
![Screen_Shot_2018-01-12_at_18.09.22__1_](/uploads/17bbabdc32947f63399d37e9af7652e6/Screen_Shot_2018-01-12_at_18.09.22__1_.png)
## Most notable Technical Details :
civicrm_memebership.is_override field is removed, and two alternative fields are added, once is called status_override_type (DEFAULT 0) , and the other is status_override_end_date (DEFAULT NULL).
status_override_type may contain 0 (means no override), 1 (means override Permanently) or 3 (means Override until selected date), where status_override_end_date will contain the override end date in case the status override type is 3 (override until selected date).https://lab.civicrm.org/dev/core/-/issues/1Allow to search for "in progress" contributions2024-03-01T16:29:50ZxavierAllow to search for "in progress" contributionsThe search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on s...The search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on status "in progress". Worse case scenario, no contributions have this status, and it will return an empty list4.7.31https://lab.civicrm.org/dev/core/-/issues/3538Docker2022-06-11T14:45:10ZMichael McAndrewDockerHey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit mor...Hey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit more.
I am wondering whether cloud native is the right place for it, or if we should create a Docker project.
On the one hand, I feel like there could be a lot of Docker chat and wouldn't want to drown out other chat. On the other, I don't want to proliferate groups unnecessarily.
Any thoughts? I am erring toward a seperate group at the minute.https://lab.civicrm.org/dev/translation/-/issues/4Create nl_BE translation2020-04-10T01:47:08ZbgmCreate nl_BE translationDiscussed at CiviCamp Brussels, February 2018:
* [x] Create a nl_BE translation of CiviCRM
* [x] Synchronize from nl_NL, so that it is possible to re-use the existing NL translation, but adapt a few sentences where necessary.
cc @alainbDiscussed at CiviCamp Brussels, February 2018:
* [x] Create a nl_BE translation of CiviCRM
* [x] Synchronize from nl_NL, so that it is possible to re-use the existing NL translation, but adapt a few sentences where necessary.
cc @alainbhttps://lab.civicrm.org/dev/core/-/issues/2Display Inbound Email: linefeed suppressed2024-03-26T10:22:28ZDetlev SieberDisplay Inbound Email: linefeed suppressedWhen viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.When viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.4.7.31https://lab.civicrm.org/dev/core/-/issues/3Upgrade Symfony dependency to 3.x2024-02-09T08:47:50ZbgmUpgrade Symfony dependency to 3.xThe Ubuntu/Debian community have raised the issue that the 2.x version of Symfony used by CiviCRM is quickly going to be outdated. `nacc` on IRC recommended moving to 3.x.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
cc @ja...The Ubuntu/Debian community have raised the issue that the 2.x version of Symfony used by CiviCRM is quickly going to be outdated. `nacc` on IRC recommended moving to 3.x.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
cc @jackrabbithanna @totten
IRC log:
```
2018-02-12 13:11 < nacc> Apologies for what might be considered offtopic; I work on Ubuntu
Server, and am responsible for our current migration to PHP7.2 (from PHP7.1). One of
the fallouts was a move to Symfony 3.4.3, which in turns breaks CiviCRM which is incompatible
with 3.0 per composer.json. Is this a hard (and not likely to change) dependency, and should
we therefor remove civicrm from Ubuntu?
2018-02-12 13:16 < nacc> [...] our feature freeze is March 1. I will note as well that civicrm
is uninstallable in Debian for the same reason (the Debian pacakge, that is):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
```
@jackrabbithanna mentioned on Mattermost:
> Actually CiviCRM Core is behind Drupal 8, so upgrading it would be super
> D8 either is or will be using Symfony 3.2.8 (was/is 3.2.6)
> https://www.drupal.org/node/2743809
> https://www.drupal.org/node/2891254
> anyway, 8.4 definitely is Symfony 3.2