CiviCRM Core issues
https://lab.civicrm.org/dev/core/-/issues
2024-02-23T15:18:48Z
https://lab.civicrm.org/dev/core/-/issues/5017
Fatal Error with Angular Manager.php after upgrading to CiviCRM 5.69.5
2024-02-23T15:18:48Z
LKuttner
Fatal Error with Angular Manager.php after upgrading to CiviCRM 5.69.5
After upgrading to CiviCRM 5.69.5 from 5.64.4 we get a WSOD.
`Parse error: syntax error, unexpected '=' in .../modules/civicrm/Civi/Angular/Manager.php on line 98`
`Fatal error: Exception thrown without a stack frame in Unknown on line...
After upgrading to CiviCRM 5.69.5 from 5.64.4 we get a WSOD.
`Parse error: syntax error, unexpected '=' in .../modules/civicrm/Civi/Angular/Manager.php on line 98`
`Fatal error: Exception thrown without a stack frame in Unknown on line 0
`
I have not been able to identify what is causing this.
I have disabled all the non-standard CiviCRM extensions, with no change.
This is on Drupal 7.99 with PHP 7.3.33. Thank you for any help you can offer.
https://lab.civicrm.org/dev/core/-/issues/5015
'Clean-up Temporary Data and Files' doesn't empty the tplCache by default
2024-02-23T15:18:23Z
Andrew West
'Clean-up Temporary Data and Files' doesn't empty the tplCache by default
The 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this balloon...
The 'Clean-up temporary data and files' scheduled job [doesn't clean the tpl directory by default](https://github.com/civicrm/civicrm-core/blob/06540d39dc2cedcadb19be5c351ef831a9133534/api/v3/Job.php#L631). Should it? We see this ballooning to tens of gigabytes when sending large mailings.
Workaround is to add the parameter, but it seems like this might catch some people out.
![image](/uploads/85b4275fb08070a8995fe094e32d466e/image.png)
https://lab.civicrm.org/dev/core/-/issues/5009
SearchKit table display: some pager settings doesn't stick
2024-02-14T10:09:42Z
noah
SearchKit table display: some pager settings doesn't stick
![hidepager](/uploads/df0e16539b7cc4b283b277aa7b036fd6/hidepager.gif)
The screen recording shows that the "Adjustable Page Size" setting doesn't save. This is also true for "Hide Pager if One Page" and most if not all other pager settings.
![hidepager](/uploads/df0e16539b7cc4b283b277aa7b036fd6/hidepager.gif)
The screen recording shows that the "Adjustable Page Size" setting doesn't save. This is also true for "Hide Pager if One Page" and most if not all other pager settings.
https://lab.civicrm.org/dev/core/-/issues/5004
Wrong Contribution ID passed to TokenValueEvent and Duplicate Invoice Numbers...
2024-02-22T04:18:48Z
ginkgomzd
ginkgomzd@fastmail.com
Wrong Contribution ID passed to TokenValueEvent and Duplicate Invoice Numbers for Contributions created around same time
New description after diagnosis:
Code was setting invoice number to a predicted next ContributionID instead of waiting for the Contribution ID to be set.
----
Overview
----------------------------------------
When two contributions are ...
New description after diagnosis:
Code was setting invoice number to a predicted next ContributionID instead of waiting for the Contribution ID to be set.
----
Overview
----------------------------------------
When two contributions are made at the same time (same datetime to the second), one of the contributions is assigned a duplicate invoice_number. The invoice number is assigned based on a Contribution ID, therefore, we infer that the Contribution ID is corrected later in the request handling, but the invoice ID is not updated and is therefore a duplicate of another existing contribution.
There is no token for invoice number and we are not using the System Workflow messages that make it available as a variable in Smarty processing.
Our custom token sets it from the Contribution ID passed to TokenValueEvent. Perhaps this is a better framing of the bug over-all... the incorrect Contribution ID is passed to the TokenValueEvent. This is probably inconsequential for most cases since Contribution ID is not a likely token or token dependency.
Reproduction steps
----------------------------------------
It has been observed multiple times in our high-volume event registrations. Reproduction would require submitting simultaneous requests. This might involve some luck, but maybe an appropriately high load compared to the system configuration would trigger the condition reliably.
We are using the payflowpro payment processor extension.
Current behaviour
----------------------------------------
Two contributions, with different but sequential Contribution ID's, share the same invoice_number and are both returned in a search by invoice number.
Expected behaviour
----------------------------------------
The invoice_number should be unique and is expected to be derived from Contribution ID and invoice prefix.
https://lab.civicrm.org/dev/core/-/issues/5002
Number field input validation does not respect decimal separator (member cust...
2024-03-07T12:13:16Z
CΓ©sar
Number field input validation does not respect decimal separator (member custom field)
## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set...
## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set "Thousands Separator" to "." (dot) and "Decimal Delimiter" to "," (comma).
2. Create a custom field extending Memberships. Data type: Number. (money works)
3. Edit an existing member (or: add a new member). In the number field, enter a number that includes a comma, such as "1,5".
## Current behaviour
Validation fails with the error message "**Error One of parameters (value: 1,5) is not of the type Float**"
## Environment information
Tested on https://dmaster.demo.civicrm.org/ 5.72.alpha1
https://lab.civicrm.org/dev/core/-/issues/5000
SearchKit: Allow formatting of the totals in the footer
2024-02-14T10:06:39Z
simon.hermann
SearchKit: Allow formatting of the totals in the footer
SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either ...
SearchKit allows to create a footer row, where the total of a column can be displayed. However, this total does not allow for any formatting or reproduces the formatting of the columns it sums.
It would be great if there would be either an option to choose a formatting (decimal separators, thousand separators, currencies if applicable etc) or if the total would reflect the formatting of the column it sums.
https://lab.civicrm.org/dev/core/-/issues/4999
Imagine a world without CodeGen
2024-03-05T04:32:51Z
colemanw
Imagine a world without CodeGen
Currently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha...
Currently we use `CRM_Core_CodeGen` to take our schema/xml files and generate DAO.php, install.sql and uninstall.sql files, which have to be periodically regenerated. This is a minor inconvenience for a core developer, a potential gotcha for an extension developer, and a major coordination difficulty across *all* extensions in `universe` (whenever any aspect of the generated code needs to change).
But what if we didn't have to generate those files? What if we could read schema information directly from the xml (or potentially a different source).
Current Structure:
-----
**Key:** βοΈ Handwritten file | π Generated file
| File | Purpose | In Core | In Extensions |
| --- | --- | --- | --- |
| βοΈ `schema/xml` | Canonical declaration of entity + all metadata | Run `setup.sh -g` | Run `civix generate:entity-boilerplate` |
| π Install sql | Add schema tables | `civicrm.mysql` | `auto_install.sql` |
| π Uninstall sql | Drop schema tables | `civicrm_drop.mysql` | `auto_uninstall.sql` |
| π Entity.php | Declare entity's existence | `AllCoreTables.data.php` | `*.entityType.php` + `entity-types-php` mixin |
| π `CRM/Core/I18n/SchemaStructure.php` | Lists localizable table columns | Seems kinda redundant with other metadata? | Doesn't exist |
| βοΈ `CRM_Core_DAO` | Base class for all generated DAOs | All DAOs extend this class | Extension DAOs also extend core class (makes change-management across `universe` difficult) |
| π `CRM_*_DAO_*` | Generated from the xml file | Must be generated | Must be generated |
The generated DAO file (including stuff it inherits from `CRM_Core_DAO`) serves a variety of purposes:
1. OO class that allows a database table to be used like a php object, e.g.
```
$contact = new CRM_Contact_DAO_Contact();
$contact->first_name = 'Bob';
$contact->save();
```
This is a neat idea and probably ahead of its time, but is basically deprecated now, mostly because, in a relational database, having access to only one table at a time isn't very useful. If it weren't for legacy core & extension code still using this pattern, we could drop it in favor of more robust tools like APIv4.
2. Static methods like `fields()` and `indices()` which return the data from the xml file in php format.
3. Localizes strings, because CodeGen wraps titles and labels in `ts()`.
4. A bunch of other random static methods (e.g. `disableFullGroupByMode()`) which seem like they'd be better-placed in a separate utility class.
New Structure
----------
If we no longer want to generate files and just read from a canonical source, then the main question is, "what should be the canonical source of entity metadata?"
1. **Stick with XML:** Keep the existing xml files but delete the generated stuff. Parse the xml at runtime to get that data.
- Pro: It's already there, no rewrites needed.
- Con: Poor DX (developers don't generally enjoy writing XML files).
- Con: It's very slow (the slowest by far of all the options) so heavy caching would be needed.
- Con: Without generating php files, another method of i18n string extraction would be needed ([such as this](https://github.com/civicrm/civistrings/pull/17)).
2. **DAO Files:** Delete the `schema/xml` files and run everything from the generated DAO files, which going forward will be hand-edited instead of regenerated.
- Pro: DAO files are already there.
- Con: Also poor DX (the boilerplate in those files would not be fun to write/edit by hand).
3. **Somewhere Else:** Move schema info to e.g. json files or better-structured PHP files.
- Pro: DX and performance could be optimized.
- Con: XML files must be rewritten (could be scripted).
- Con: Migration management for core and extensions.
Supporting Dynamic/Virtual Entities
--------
It's also worth keeping in mind that there are now several types of entities that are dynamic & share a DAO:
- Multi-record custom fields
- ECK entities
- SearchKit materialized displays
The DAO structure doesn't cope with this very well, as the assumption has always been 1-1-1 between table, entity & DAO class. But while we're restructuring things let's avoid adding more code that makes this assumption. An ideal DAO from the POV of virtual entities would be an object that takes entity name in its constructor & initializes itself with the appropriately corresponding tablename, fields, and other metadata.
https://lab.civicrm.org/dev/core/-/issues/4998
[PHP 8] Undefined properties @ ext/Standaloneusers DAO
2024-02-14T10:05:35Z
jofranz
franz@systopia.de
[PHP 8] Undefined properties @ ext/Standaloneusers DAO
PhpStan is reporting some Undefined properties on current master @ eacd1f4206fab41f0cf14bcbd80b5f7187b42bea
```
β standaloneusers (master) phpstan analyse -c ~/repositories/ext/phpstan.d11.neon.dist -l 0 . ...
PhpStan is reporting some Undefined properties on current master @ eacd1f4206fab41f0cf14bcbd80b5f7187b42bea
```
β standaloneusers (master) phpstan analyse -c ~/repositories/ext/phpstan.d11.neon.dist -l 0 . β β
50/50 [ββββββββββββββββββββββββββββ] 100%
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/Role.php
------ --------------------------------------------------------------------------------------
100 Access to an undefined property CRM_Standaloneusers_DAO_Role::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/Session.php
------ --------------------------------------------------------------------------------------
74 Access to an undefined property CRM_Standaloneusers_DAO_Session::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/User.php
------ --------------------------------------------------------------------------------------
171 Access to an undefined property CRM_Standaloneusers_DAO_User::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ --------------------------------------------------------------------------------------
Line CRM/Standaloneusers/DAO/UserRole.php
------ --------------------------------------------------------------------------------------
65 Access to an undefined property CRM_Standaloneusers_DAO_UserRole::$__table.
π‘ Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
------ --------------------------------------------------------------------------------------
------ ---------------------------------------------------------------------
Line Civi/Api4/Action/User/PasswordReset.php
------ ---------------------------------------------------------------------
36 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
45 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------
------ ---------------------------------------------------------------------
Line Civi/Api4/Action/User/SendPasswordReset.php
------ ---------------------------------------------------------------------
40 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------
------ -----------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Create)
------ -----------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ -----------------------------------------------------------------------------------------
------ ---------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Save)
------ ---------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ ---------------------------------------------------------------------------------------
------ -----------------------------------------------------------------------------------------
Line Civi/Api4/Action/User/WriteTrait.php (in context of class Civi\Api4\Action\User\Update)
------ -----------------------------------------------------------------------------------------
56 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
59 Instantiated class API_Exception not found.
π‘ Learn more at https://phpstan.org/user-guide/discovering-symbols
------ -----------------------------------------------------------------------------------------
------ ------------------------------------------------------------------------------------------------------------
Line Civi/Standalone/Security.php
------ ------------------------------------------------------------------------------------------------------------
24 Unsafe usage of new static().
π‘ See: https://phpstan.org/blog/solving-phpstan-error-unsafe-usage-of-new-static
328 Regex pattern is invalid: Unknown modifier '+' in pattern: /
^
\$([a-z0-9-]{1,32}) # Match 1 algorithm identifier
(\$v=[0-9+])? # Match 2 optional version
(\$[a-z0-9-]{1,32}=[a-zA-Z0-9/+.-]*(?:,[a-z0-9-]{1,32}=[a-zA-Z0-9/+.-]*)*)? # 3: optional parameters
\$([a-zA-Z0-9/+.-]+) # Match 4 salt
\$([a-zA-Z0-9/+]+) # Match 5 B64 encoded hash
$/x
------ ------------------------------------------------------------------------------------------------------------
[ERROR] Found 15 errors
```
Touches #4072
Config used: https://github.com/jofranz/civicrm-code-scans
https://lab.civicrm.org/dev/core/-/issues/4996
Standalone - user documentation for user management functionality
2024-02-23T16:54:58Z
ufundo
Standalone - user documentation for user management functionality
Would be good to write some user documentation for how to use the standaloneusers user management screen.
I think this belongs somewhere here: https://docs.civicrm.org/sysadmin/en/latest/setup/ ?
Would be good to write some user documentation for how to use the standaloneusers user management screen.
I think this belongs somewhere here: https://docs.civicrm.org/sysadmin/en/latest/setup/ ?
https://lab.civicrm.org/dev/core/-/issues/4994
Standalone - issues with haveibeenpwned on password setting screen?
2024-03-26T11:33:19Z
ufundo
Standalone - issues with haveibeenpwned on password setting screen?
Rich
Rich
https://lab.civicrm.org/dev/core/-/issues/4992
Standalone - front-end theming
2024-02-14T10:01:23Z
ufundo
Standalone - front-end theming
@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.
@artfulrobot suggests: provide a template for front facing pages. People can edit that file
(manually) to suit. It should not get overwritten on upgrade.
Rich
Rich
https://lab.civicrm.org/dev/core/-/issues/4991
Standalone SSO - third-party authentication for single sign on, such as Hybri...
2024-02-14T10:01:04Z
ufundo
Standalone SSO - third-party authentication for single sign on, such as HybridAuth or LDAP or SAML
Would be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?
Would be great to build out the standalone users functionality.
Either in Standaloneusers extension or a separate one?
ufundo
ufundo
https://lab.civicrm.org/dev/core/-/issues/4986
Montreal Sprint Topics
2024-02-28T23:28:14Z
colemanw
Montreal Sprint Topics
Brainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/...
Brainstorming ideas for the Montreal Sprint
- Afform testing. Build on [Dave D's extension](https://lab.civicrm.org/extensions/afformminktests)
- Accessibility improvements: priorities may include
- accordion overhaul (#3294 / [dev/user-interface#67](https://lab.civicrm.org/dev/user-interface/-/issues/67))
- accordions: review [#29533](https://github.com/civicrm/civicrm-core/pull/29533)
- accordions: JS fixes for [#29448](https://github.com/civicrm/civicrm-core/pull/29448)
- select2 upgrade/replacement (#3292)
- ensure all fields have labels (see [testing by mthompson](https://chat.civicrm.org/civicrm/pl/un7ajre7mbyc3fis4qebnczpse) on MM)
- ensure tabs are accessible
- ensure pop-ups (dialogs, notifications) are accessible
- ensure date fields are accessible
- ensure [validation errors](https://chat.civicrm.org/civicrm/pl/seqg55bm4fn58eaybqaz5e7kcr) use best practices
- Improve loading of SK/FormBuilder content client-side (bundle requests to minimize Civi bootstrap cycles)
- Placing fields in a form that are not saved to Civi (but are recorded in `civicrm_afform_submission`)
- UX improvements to FormBuilder
- Keyboard navigation of edit-in-place SK displays (and other afforms?) -- and accessibility more broadly?
- Making FormBuilder field placement more flexible (independent of container)
- Use the Queue system for SearchKit exports
- [Open AdminUI PRs](https://github.com/civicrm/civicrm-core/pulls?q=adminui+OR+admin_ui+OR+%22admin+ui%22+is%3Apr+is%3Aopen)
- [Open Afform/SK/FB PRs](https://github.com/civicrm/civicrm-core/pulls?q=afform+OR+searchkit+OR%22search+kit%22+OR+formbuilder+OR+%22form+builder%22+is%3Apr+is%3Aopen+)
https://lab.civicrm.org/dev/core/-/issues/4984
Display issue on membership view for relationships
2024-02-14T09:55:26Z
yashodha
Display issue on membership view for relationships
## Steps to replicate :
* Create a membership type configured with a relationship in both directions.
![Screenshot 2024-02-08 204424.png](/uploads/d4e47bd30b2673291f1e8c5bfe4346aa/Screenshot_2024-02-08_204424.png)
* Create a relations...
## Steps to replicate :
* Create a membership type configured with a relationship in both directions.
![Screenshot 2024-02-08 204424.png](/uploads/d4e47bd30b2673291f1e8c5bfe4346aa/Screenshot_2024-02-08_204424.png)
* Create a relationship between contacts that have this relationship "Shares home"
* Create a primary membership on one of them.
* On membership view screen, we can't see the related contact
![Screenshot 2024-02-08 205130.png](/uploads/63407ba8348abd8a2259ad59702c608b/Screenshot_2024-02-08_205130.png)
This should show like (fixed)
![Screenshot 2024-02-08 205008.png](/uploads/fde582a5808cf50f49f8d3fa80cf865c/Screenshot_2024-02-08_205008.png)
I can confirm this is not working on dmaster as well.
yashodha
yashodha
https://lab.civicrm.org/dev/core/-/issues/4983
FormBuilder - allow injection of js files to afform forms
2024-02-14T09:54:42Z
seamuslee
FormBuilder - allow injection of js files to afform forms
As part of JMA's geotargeted petition extension we have some javascript that we inject on the front end https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L58. The purpose of...
As part of JMA's geotargeted petition extension we have some javascript that we inject on the front end https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L58. The purpose of the Javascript is to do a dynamic lookup based on address information entered and then add checkboxes onto the form of "your local representatives that we will be contacting"
Is there a way to be able to do this within the GUI of form builder or similar to make it easier to always ensure that the js is loaded rather than just based on a specific block being on the form
@JoeMurray @Edselopez @colemanw
https://lab.civicrm.org/dev/core/-/issues/4982
Form builder - Extension provided entity settings
2024-02-14T09:53:44Z
seamuslee
Form builder - Extension provided entity settings
JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter ...
JMA is in the progress of working on a geographically targeted petition extension
At the moment we have some additional settings that we get a user to set when creating the petition page in Form Builder. These get injected by the alter angular hook https://lab.jmaconsulting.biz/extensions/geotargetedpetitions/-/blob/main/geotargetedpetitions.php?ref_type=heads#L76 however this means that even on non petition related form builder forms they will show up.
This is about seeing if there is a better way to achieve this and or see if we can get them put onto the specific settings page for say GeotargetedPetition Entity.
@JoeMurray @Edselopez @colemanw
https://lab.civicrm.org/dev/core/-/issues/4979
Should `die()` be called when a DB Query fails?
2024-02-14T09:49:16Z
haystack
Should `die()` be called when a DB Query fails?
Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#...
Overview
----------------------------------------
As the title says, when a DB Query fails, `CRM_Utils_File::runSqlQuery()` [calls](https://github.com/civicrm/civicrm-core/blob/fd4913060d8e944a99abe30c22ba670ed0e51a9a/CRM/Utils/File.php#L327) `die()` and all script execution stop *ahem* dead. Is this intentional?
Reproduction steps
----------------------------------------
1. Install the "Deduper" Extension (v1.7) via the API (sorry @eileen :dove:)
1. See the unrecoverable error "**Cannot execute INSERT INTO civicrm_contact_name_pair_family (id, name_a, name_b, is_most_common_form, is_active) VALUES (65, 'Takahashi', 'ι«π£Ί', 0, 1)**".
Current behaviour
----------------------------------------
There's no way to trap this and continue with a script that installs Extensions via the API.
Edit: apparently there [is a way](https://stackoverflow.com/a/16925225) but this seems a less than sensible way to go about trapping the error.
Expected behaviour
----------------------------------------
A script that installs Extensions via the API should be able to trap the error as an `Exception` with `try/catch` and act accordingly.
https://lab.civicrm.org/dev/core/-/issues/4978
Creating a user was not succesful
2024-02-14T09:48:02Z
Betty Dolfing
Creating a user was not succesful
I wanted to add a user to civistandalone, but had to try 5 times, before I was succesful.
I tried in FF first and after 5 times I switched to Chrome. Then a user was created.
I have the impression that not so much the browser caused th...
I wanted to add a user to civistandalone, but had to try 5 times, before I was succesful.
I tried in FF first and after 5 times I switched to Chrome. Then a user was created.
I have the impression that not so much the browser caused the problem, but some kind of error.
However, I only saw for a split second an error message in the right hand corner, so am not aware of the _type_ of error.
For now I am ok and when I add users, I will just keep on trying till I am succesful.
But when Civi stand alone is beyond the beta version, this needs to be fixed.
https://lab.civicrm.org/dev/core/-/issues/4976
Standalone: Timezone improvements
2024-02-07T18:41:29Z
DaveD
Standalone: Timezone improvements
It doesn't look like standalone has a setting for a site-wide default timezone. It means anywhere where anonymous sees timestamp fields (as opposed to datetime fields) they'll see whatever the server default is, but without a way for the...
It doesn't look like standalone has a setting for a site-wide default timezone. It means anywhere where anonymous sees timestamp fields (as opposed to datetime fields) they'll see whatever the server default is, but without a way for the average site admin to "fix" it. At the moment I'm drawing a blank as to which screens this would be. Something like a creation date, or an activity date if you have doctorwhen installed.
I also don't see where php's timezone gets set, which is somewhat equivalent to a site-wide default. There might be some places where that will come up, but am also drawing a blank on where at the moment. Drupal sets it in drupal somewhere, and see e.g. what wordpress does for civi: https://github.com/civicrm/civicrm-core/blob/888e65374f208e6d79ff8adc68d0adfa05575277/CRM/Utils/System/WordPress.php#L732
https://lab.civicrm.org/dev/core/-/issues/4975
FormBuilder: Case Status field shows disabled statuses
2024-02-23T15:32:47Z
noah
FormBuilder: Case Status field shows disabled statuses
The Case Type admin screen (e.g. civicrm/a/#/caseType/1) allows you to disable some case statuses for a given case type.
When you create a Case submission form in FormBuilder, and add the Case Status field to the form, all case statuses...
The Case Type admin screen (e.g. civicrm/a/#/caseType/1) allows you to disable some case statuses for a given case type.
When you create a Case submission form in FormBuilder, and add the Case Status field to the form, all case statuses are available in the resulting widget, regardless of whether they're enabled for the case type.
You can manually remove some of the status options, but they won't stay in sync with the Case Type admin screen.