Development issueshttps://lab.civicrm.org/groups/dev/-/issues2018-11-09T20:25:39Zhttps://lab.civicrm.org/dev/core/-/issues/289CiviCase Dashboard link to edit an activity status broken2018-11-09T20:25:39ZGMCVO DatabasesCiviCase Dashboard link to edit an activity status brokenThere is a bug with the CiviCase dashboard
When you click to edit the case activity pencil it crashes with 'required params missing'
Also replicated on the demo site https://dmaster.demo.civicrm.org/civicrm/case?reset=1There is a bug with the CiviCase dashboard
When you click to edit the case activity pencil it crashes with 'required params missing'
Also replicated on the demo site https://dmaster.demo.civicrm.org/civicrm/case?reset=15.5.0https://lab.civicrm.org/dev/core/-/issues/3804Civicase dashboard not displaying recently performed activities2023-03-30T09:37:49ZKurund JalmiCivicase dashboard not displaying recently performed activitiesCiviCase Dashboard does not display 'Recently Performed Activities` when there are no `Upcoming Activities`.CiviCase Dashboard does not display 'Recently Performed Activities` when there are no `Upcoming Activities`.5.61.0Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/1715CiviCase dashboard/find case: Additional columns and filters needed2022-05-11T14:39:19ZDetlev SieberCiviCase dashboard/find case: Additional columns and filters neededIn order to improve the workflow, the following should be added to the find case / dashboard functionality of CiviCase:
New column: "Case_ID" -> with sorting
New filter: "Next Sched. assignee"
* This should refer to the "Next Sched." ...In order to improve the workflow, the following should be added to the find case / dashboard functionality of CiviCase:
New column: "Case_ID" -> with sorting
New filter: "Next Sched. assignee"
* This should refer to the "Next Sched." actitivity from the list.
* The filter list should contain "myself" as the first entry, and then should display all other assignee contained in the activities displayed on the case list.
This functionality should be available on:
* case dashboard
* search results (case search)
* case dashletshttps://lab.civicrm.org/dev/core/-/issues/1338CiviCase end date not showing nor consistent2022-12-30T05:03:34ZStoobCiviCase end date not showing nor consistentIt is possible to search by End Date in CiviCase
![find](/uploads/545ddd404b11dbebb421e1c88131488c/find.png)
But neither Date shows up in the results of Find Cases. End Date is _only_ visible using Search Builder
![results](/uploads/e0...It is possible to search by End Date in CiviCase
![find](/uploads/545ddd404b11dbebb421e1c88131488c/find.png)
But neither Date shows up in the results of Find Cases. End Date is _only_ visible using Search Builder
![results](/uploads/e0fe3b35b3a2e71eb960f52d5bf3db45/results.png)
Nor does the End Date visible when managing the case itself
![case-view](/uploads/d4ec00d1267d0e4232405e8b045f3683/case-view.png)
Furthermore, the End Date of the Case is occasionally set mechanically by the software (not a human) to a Date *other than* the last Activity on the case. This is confusing how this Date determination is made and the treatment is inconsistent.
I'd find an explanation to this behavior from someone who knows, and possibly improve this Date process.https://lab.civicrm.org/dev/core/-/issues/2875CiviCase Forces Case Status to Resolved (Closed) when all Activities in a Seq...2023-09-30T05:03:30ZpbarmakCiviCase Forces Case Status to Resolved (Closed) when all Activities in a Sequence are CompleteOverview
----------------------------------------
For Cases that use a Sequence, once all activities in the sequence are complete, the Case gets set to a Resolved (aka Closed) status. This is fine. However, after a Case is in the Resolve...Overview
----------------------------------------
For Cases that use a Sequence, once all activities in the sequence are complete, the Case gets set to a Resolved (aka Closed) status. This is fine. However, after a Case is in the Resolved status, if a user then wishes to change the status to something other than Resolved (like to a custom status), even though CiviCase says it made the change and even creates a status change activity that shows the status was changed, the case remains in Resolved status.
It looks like Civi/CCase/SequenceListener.php is firing after any case status changes are written to the DB, but SequenceListener is not accounting for someone purposefully trying to change the case status. It only looks for all activities being completed and forces the case back to Resolved.
This doesn't seem like correct behavior nor a good user experience. The listener should check to see if the action was a status change action and not fire the API call in that case. I'm not sure how that can be done (not sure what input the listener has), but that's my guess on how to resolve the issue.
Reproduction steps
----------------------------------------
1. Create a Case Type that uses a sequence of activities (doesn't matter how many)
1. Create a new Case using that type
1. Complete each activity in the sequence and see that the Case automatically changes to Resolved.
1. Try to then change the Case Status to something other than Resolved (like In Progress or Ongoing or any custom status).
1. See that the Case status remains as Resolved, even though a new case activity says it was changed.
Expected behaviour
----------------------------------------
The Case should allow a change in Status even if all Activities in a Sequence are completed. That way user can change to a custom status that also reflects completion (we have multiple status that denote completion but for a variety of reasons).https://lab.civicrm.org/dev/core/-/issues/630CiviCase multi-category/ multi-instance support2022-10-29T05:03:41ZguanhuanCiviCase multi-category/ multi-instance supportRecently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. So...Recently having had some discussions with a few of our clients and participants of CiviMeetup, We have realised that there are a lot of interest in using CiviCase to manage many different types of workflows in different organisations. Some of them require a change to evolve CiviCase’s data model to a multi-level structure.
To support this idea, I have attached a diagram to demonstrate the multi-level structure. We have suggested that a new field “case type category” would provide a lot of flexibility.
![CiviCase_Structure](/uploads/b73a3f3e8eb1d71034ac9121e1379f9c/CiviCase_Structure.jpg)
The basic idea is, an organisation’s business is made up of many different workflows for different business areas, such as Service delivery (i.e. a Helpdesk, Counselling service or Delivering care/housing support), Prospecting (i.e. major donors, grants bid writing in), Awards (i.e. Grants out), Volunteer vacancy management and even perhaps as a set of tasks for an event etc. These completely different workflows often are managed by completely different teams (who would need to manage their own case types), produce very different data and therefore require very different analysis and reports. "Case Type” is not sufficient to support all these needs as there may be several case types which apply to any specific business area.
Each team would probably want:
- The ability to create/configure case types of their category. For example with a volunteer vacancy managers they may want to create multiple vacancies, or with Grants, there may be multiple open opportunities. For Major donors they may split these between different types of donor - i.e. trusts, individuals, government which have different timelines and activities.
- The ability to add additional fields at the case type level for each category.
- Only having access to cases with the case type category they should have access to
- Some modifications to the case screen for cases of that case type category.
We've made a more detailed [draft proposal](https://compucorp.atlassian.net/wiki/spaces/PS/pages/1014398991/CiviCase+multi-category+support) of what we need to do to eliminate these caveats. The main target is to bring out the full potential of CiviCase as CiviCRM’s workflow management suite.https://lab.civicrm.org/dev/core/-/issues/1115CiviCase singleton activity warning has wrong url2019-07-15T19:07:10ZDaveDCiviCase singleton activity warning has wrong urlThis came up earlier when I was first checking out the Case v5 extension, but I thought I also checked it against core and it was ok in core so I filed the bug against the extension (https://github.com/compucorp/uk.co.compucorp.civicase/...This came up earlier when I was first checking out the Case v5 extension, but I thought I also checked it against core and it was ok in core so I filed the bug against the extension (https://github.com/compucorp/uk.co.compucorp.civicase/issues/151). But maybe I didn't actually check since it also seems to be in core.
1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. On manage case, create a second activity of that type.
3. It will properly give you the warning that the singleton activity already exists, and provide a link to edit the existing one, but the link has `id=0` instead of the actual activity id.
4. If you click the link, it gives a fatal error.
It's something going on here: https://github.com/civicrm/civicrm-core/blob/5.15.1/CRM/Case/Form/Activity.php#L187-L199
Will see what I can do...https://lab.civicrm.org/dev/core/-/issues/1526civiCase, Contributions and activities have no record locking!2023-01-29T05:03:15ZsqwciviCase, Contributions and activities have no record locking!To Reproduce
1) Open 2 windows on the same Case
2) Edit the details in both windows - use different data in each
3) Save record in both windows
4) The later saved record will be the only date recorded
There is no user warning either bef...To Reproduce
1) Open 2 windows on the same Case
2) Edit the details in both windows - use different data in each
3) Save record in both windows
4) The later saved record will be the only date recorded
There is no user warning either before or after editing or saving the data.
The same is reproducible for activities and contributions.
This may apply elsewhere.
To my mind this is a fundamental show stopper since it can cause loss of data at any time without warning or notice.https://lab.civicrm.org/dev/core/-/issues/590CiviCase- additional timeline- activity offset not working post upgrade2022-09-21T05:03:42ZalarmingcodCiviCase- additional timeline- activity offset not working post upgradeWe've recently upgraded a site from 4.6.38 to 5.7
They were using cases with additional timelines. So they could add a new session to an existing case offset by 7 days from the "newest" activity of type x.
Post upgrade the additional t...We've recently upgraded a site from 4.6.38 to 5.7
They were using cases with additional timelines. So they could add a new session to an existing case offset by 7 days from the "newest" activity of type x.
Post upgrade the additional timeline only offsets the new activity from the oldest activity of type x in the case. (This holds true wether the offfset is marked as oldest or newest in the timeline settings.
Just tested this out on dmaster.demo and found this works the same.https://lab.civicrm.org/dev/core/-/issues/500CiviCase: dashboard summary count includes cases from inactive relationships2019-11-24T19:59:34ZbgmCiviCase: dashboard summary count includes cases from inactive relationshipsHow to reproduce:
* Create a case
* Assign it to someone, view their dashboard, it will show X cases
* Then re-assign it to someone else, view their dashboard, it will still show X cases (instead of X-1).How to reproduce:
* Create a case
* Assign it to someone, view their dashboard, it will show X cases
* Then re-assign it to someone else, view their dashboard, it will still show X cases (instead of X-1).5.11bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/405CiviCase: unable to save case type config2018-10-09T16:51:14ZlcdwebCiviCase: unable to save case type configTo reproduce, visit Administer > CiviCase > Case Types and edit an existing or create a new case type. The save button is not available and there doesn't appear to be any missing required data that would prevent it from being enabled.To reproduce, visit Administer > CiviCase > Case Types and edit an existing or create a new case type. The save button is not available and there doesn't appear to be any missing required data that would prevent it from being enabled.https://lab.civicrm.org/dev/core/-/issues/2019Civicase: Wrong Details in Change Custom Data Activity when filling an empty ...2021-03-11T12:47:44ZAndreasandreas.howiller@civiservice.deCivicase: Wrong Details in Change Custom Data Activity when filling an empty fieldOverview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumsta...Overview
----------------------------------------
When custom case data is changed in CiviCase a Custom Data Activity is created logging the change in the activity details. This is working well in most circumstances but in some circumstances the change log contains misleading content.
Reproduction steps
----------------------------------------
1. Create custom case field eg. of type text called "Custom text".
2. Go to any case and change the data of this field from empty to "short text" (save changes), and then again from "short text" to "short text" (same text, save again).
3. View the details of the two Custom Data Activity created.
Current behaviour
----------------------------------------
When changing the data of a custom text field called "Custom text" from "short text" to "a second short text" it will log: "Custom text: short text => a second short text".
**However under the following two conditions this produces misleading logging:**
1. When the text field above is empty in the beginning what you get is "Custom text: short text => short text". In practice this behavior may produce misunderstandings as it suggests that "short text" was already there and in use cases like application processes this may make a huge difference.
2. When the text field contains the same string a Custom Data Activity is created with Details empty.
Expected behaviour
----------------------------------------
1. In the first case one would expect something like "Custom text: [ ] => short text".
2. In the second case probably the best behaviour would be not to create an activity at all and showing an appropriate message instead.
Environment information
----------------------------------------
* __Browser:__ Firefox 80.0.1
* __CiviCRM:__ 5.28.1 on drupal 7 and 5.28.2 on WordPess 5.5.15.37.0https://lab.civicrm.org/dev/core/-/issues/1394CiviCaseTestCase setup() can make duplicate activity type option values2019-11-18T06:54:19ZDaveDCiviCaseTestCase setup() can make duplicate activity type option valuesSee these lines https://github.com/civicrm/civicrm-core/blob/5.19.1/tests/phpunit/CiviTest/CiviCaseTestCase.php#L57-L71 and note that setup() also uses quickCleanup().
```
$optionValues = array(
'Medical evaluation' => 'Medica...See these lines https://github.com/civicrm/civicrm-core/blob/5.19.1/tests/phpunit/CiviTest/CiviCaseTestCase.php#L57-L71 and note that setup() also uses quickCleanup().
```
$optionValues = array(
'Medical evaluation' => 'Medical evaluation',
'Mental health evaluation' => "Mental health evaluation",
'Secure temporary housing' => 'Secure temporary housing',
'Long-term housing plan' => 'Long-term housing plan',
'ADC referral' => 'ADC referral',
'Income and benefits stabilization' => 'Income and benefits stabilization',
);
foreach ($optionValues as $name => $label) {
$activityTypes = $this->callAPISuccess('option_value', 'Create', array(
'option_group_id' => 2,
'name' => $name,
'label' => $label,
'component_id' => 7,
));
```
So for example if you have a dataprovider that calls your test multiple times, it keeps creating new duplicate activity types with the same `name`.
PR coming
In the option_value table definition maybe these keys should be unique keys, but that's extra.
```
KEY `index_option_group_id_value` (`value`(128),`option_group_id`),
KEY `index_option_group_id_name` (`name`(128),`option_group_id`),
```5.21.0https://lab.civicrm.org/dev/core/-/issues/1407CiviContribute Confirm Text2023-02-21T05:04:08ZanilpremlallCiviContribute Confirm TextOverview
----------------------------------------
Minor text change for clarity. Replace Continue with Make Contribution
Example use-case
----------------------------------------
1. Enable "Use a confirmation page?" option on Contributi...Overview
----------------------------------------
Minor text change for clarity. Replace Continue with Make Contribution
Example use-case
----------------------------------------
1. Enable "Use a confirmation page?" option on Contribution Page
2. Launch a test-drive contribution
3. Enter required fields and click "Confirm Contribution"
4. Help text in reference is at the top of the confirmation page
Current behaviour
----------------------------------------
Text: Please verify the information below carefully. Click **Go Back** if you need to make changes. To complete your contribution, click the **Continue** button below.
Proposed behaviour
----------------------------------------
Text: Please verify the information below carefully. Click **Go Back** if you need to make changes. To complete your contribution, click the **Make Contribution** button below.
Comments
----------------------------------------
Thank you for looking into this![CiviContribute-Text](/uploads/350d742bc23b81bc337b0c07cdb63434/CiviContribute-Text.png)https://lab.civicrm.org/dev/core/-/issues/3081CiviContribute Dashboard #chart_Layout does not respect Financial Type ACL2023-11-28T05:03:27Zchris_bluejacCiviContribute Dashboard #chart_Layout does not respect Financial Type ACLOverview
----------------------------------------
When a user is assigned financial type ACL, the **chart** (#chart_layout) on the CiviContribute Dashboard totals all financial types, not just the financial type/s the user has add/view p...Overview
----------------------------------------
When a user is assigned financial type ACL, the **chart** (#chart_layout) on the CiviContribute Dashboard totals all financial types, not just the financial type/s the user has add/view permissions.
The **table** (#table_layout) does respect the financial type ACL when determining the totals.
Reproduction steps
----------------------------------------
1. User is assigned permissions:
- CiviCRM: add contributions of type XXX
- CiviCRM: view contributions of type XXX
2. Go to CiviContribute Dashboard
Current behaviour
----------------------------------------
/civicrm/contribute?reset=1#chart_layout
- Chart contribution totals all financial types, regardless of ACL
- ![CiviContribute-chart-layout](/uploads/9290a635ba5c59d34e89fa5a37901ed6/CiviContribute-chart-layout.png)
/civicrm/contribute?reset=1#table_layout
- Table contribution totals financial type XXX, respecting the ACL
- ![CiviContribute-Table-Layout](/uploads/f8de42bb72e3ef4e395fe97f3bb1bf70/CiviContribute-Table-Layout.png)
Expected behaviour
----------------------------------------
Chart totals should be total of financial types the user has view access to
Environment information
----------------------------------------
* CiviCRM: 5.46.2
* PHP: 7.3.27
* CMS: Drupal 7.88
* Database: MySQL 5.7.33
* Web Server: Apache 2.4.46
* reCAPTCHA: Version 5.40.2
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/2586CiviContribute: Cannot clear the Thank-you Date (does not set to null on save)2021-05-06T01:47:07ZpbarmakCiviContribute: Cannot clear the Thank-you Date (does not set to null on save)Overview
----------------------------------------
When editing a Contribution in version 5.36.1, we click on the x to clear the Thank-you Date field. It removes the date and time. But, when we click Save, the field remains with the last-...Overview
----------------------------------------
When editing a Contribution in version 5.36.1, we click on the x to clear the Thank-you Date field. It removes the date and time. But, when we click Save, the field remains with the last-used data/time. It does not saved the cleared/null value. This is true on the latest demo as well.
Reproduction steps
----------------------------------------
1. Find any contribution. Click View. Then click Edit.
2. Click the small x next to the time field to clear out the date and time (or simply erase/delete what is there)
3. Click Save.
4. View the contribution, and the Thank-you Date is still set to the old value.
Expected behaviour
----------------------------------------
It should clear out the value of that field.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _Firefox 88
* __CiviCRM:__ 5.36.1
* __PHP:__ 7.3
* __CMS:__ Drupal 75.37.1https://lab.civicrm.org/dev/core/-/issues/3415CiviContribute: Thank you page does not appear after donation has been submit...2022-04-28T13:14:00Zben_fairlessCiviContribute: Thank you page does not appear after donation has been submitted.Overview
----------------------------------------
When a donation or membership renewal has been submitted, the user is not redirected to a thank you page. The user is redirected back to a blank page.
A receipt is generated and emailed ...Overview
----------------------------------------
When a donation or membership renewal has been submitted, the user is not redirected to a thank you page. The user is redirected back to a blank page.
A receipt is generated and emailed to the user, and their contribution is recorded (if successful), however the user is unaware that their payment has been successful.
Reproduction steps
----------------------------------------
1. Navigate to Contribution page: https://www.example.com/civicrm/?civiwp=CiviCRM&q=civicrm%2Fcontribute%2Ftransact&reset=1&id=5
2. Enter required information including credit card details via Stripe
3. Click Continue
Current behaviour
----------------------------------------
The user is redirected back to a blank version of https://www.example.com/civicrm/?civiwp=CiviCRM&q=civicrm%2Fcontribute%2Ftransact&reset=1&id=5
Expected behaviour
----------------------------------------
The user should be redirected to a "Thank you" page.
Environment information
----------------------------------------
* __Browser:__ _Chrome Version 100.0.4896.127_
* __CiviCRM:__ _5.48.1_
* __PHP:__ _7.4.28 (Supports 64bit values)_
* __CMS:__ _WordPress 5.9.3_
* __Database:__ _10.2.43-MariaDB_
* __Web Server:__ _Apache_
Comments
----------------------------------------
This can be replicated while signed in and while browsing without being signed in. The issue happens both to the test contribution page and the live page.https://lab.civicrm.org/dev/core/-/issues/2604CiviCRM 5.37.2, Both the Fetch Bounces and Process Inbound Emails jobs will ...2023-09-08T22:41:11Zjustinfreeman (Agileware)CiviCRM 5.37.2, Both the Fetch Bounces and Process Inbound Emails jobs will fail with error: 'returnPath' is invalid (patch attached)Both the **Fetch Bounces** and **Process Inbound Emails** jobs will fail with Error message: `The value 'KO'Bananas@benders.com' that you were trying to assign to setting 'returnPath' is invalid. Allowed values are: the characters 'A-Za-...Both the **Fetch Bounces** and **Process Inbound Emails** jobs will fail with Error message: `The value 'KO'Bananas@benders.com' that you were trying to assign to setting 'returnPath' is invalid. Allowed values are: the characters 'A-Za-z0-9_.@=/+{}#~-'.`
Definition of **allowed characters** from https://en.wikipedia.org/wiki/Email_address#Local-part
zetacomponents / Mail, blocks valid email addresses due to RETURN_PATH_CHARS being too restrictive
const RETURN_PATH_CHARS = 'A-Za-z0-9_.@=/+{}#~-';
https://github.com/zetacomponents/Mail/blame/master/src/mail.php#L133
https://github.com/zetacomponents/Mail/commit/5187f764a0937f9fe04e675299558f5c1a90fd77#diff-52d017c2950c2583488542baf7d18f2bed8cb4e4d460050b43413c8dd56999b5R136
This problem was introduced with zetacomponents/mail 1.9.x which had a "security fix" that introduced email name part limits, which themselves are too limiting.
https://github.com/civicrm/civicrm-core/blame/master/composer.json#L62
Relevant commit dev/mailing#59 Update the version of zetacomponents/mail package, https://github.com/civicrm/civicrm-core/commit/ec88fefe6e0e1e09d0a1a2bdee199cbb3df382fa - which looks like CiviCRM 5.37.2
Unable to submit a PR as this path does not exist in the CiviCRM Git tree, https://github.com/civicrm/civicrm-core/tree/master/tools/scripts/composer/patches
But it should exist, see https://github.com/civicrm/civicrm-core/blob/master/composer.json#L291
**Proposed solution**
Attached is a patch with the proposed fix.
[060-CIVICRM-1601-Option-A.patch](/uploads/297a7b457a6682f5bbad9046260de5cf/060-CIVICRM-1601-Option-A.patch)
Agileware Ref: CIVICRM-16015.66.0https://lab.civicrm.org/dev/core/-/issues/1349CiviCRM "Mobile" Menu on Drupal 8 is positioned weirdly.2022-12-31T05:03:25ZhomotechsualCiviCRM "Mobile" Menu on Drupal 8 is positioned weirdly.![image](/uploads/1c1129de0ced6919bb23cdb5c1a38be6/image.png)
This is the CiviCRM menu's styling on Drupal 8 with the Drupal Toolbar collapsed in "Mobile" mode. We're using absolute positioning to place the CiviCRM active menu in the mo...![image](/uploads/1c1129de0ced6919bb23cdb5c1a38be6/image.png)
This is the CiviCRM menu's styling on Drupal 8 with the Drupal Toolbar collapsed in "Mobile" mode. We're using absolute positioning to place the CiviCRM active menu in the mobile menu - this seems a little odd as a solution and I'm certain there's a better way to handle this.
If we decide not to take a different approach to this I feel changing the iconography to match Drupal 8's default styling would make this less "jarring".
Opened this issue for further discussion around possible solutions/thoughts.https://lab.civicrm.org/dev/core/-/issues/3776CiviCRM - next version? Getting fit for future...2022-08-24T03:00:46ZTobias KrauseCiviCRM - next version? Getting fit for future...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find th...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find the reasons for these I diged into the code basis of CiviCRM and I found out that CiviCRM relys on very old frameworks (e.g. Smarty version 2.6 from the year 2016) or on frameworks not really actively maintained (zetacomponents/mail from the year 2020). Just two examples but I feel if I would check the other dependencies there might be some more old frameworks.
The tip for now from the Civi-community: stay on PHP 7.4 - which will reach end of life by November this year. Even PHP 8.0 will just receive security updates until November this year so that from November on PHP 8.1 would be the correct version - on which CiviCRM is absolutely not working as I already tested.
Now I got very concerned about the next years. We heavily use CiviCRM in our daily work for the administration of thousands of donators and newsletter subscribers and for the newsletter sending so that CiviCRM is the main tool of our daily work. And now CiviCRM already feels a little bit like a dinosaur to me - especially compared with Drupal 9 I am working with in general. I fear that CiviCRM cannot keep up with the ongoing developments of PHP (and JavaScript).
My question: are there any plans for updating the dependencies? Maybe even a plan to change to more modern frameworks like Twig? I found a roadmap where Form Builder, CiviCRM Standalone and UI Improvements are listed but this feels just like some new features based on the current code basis.