CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2018-07-20T21:44:32Zhttps://lab.civicrm.org/dev/core/-/issues/265The Edit screen handles Tax Amount and Total Amount differently depending on ...2018-07-20T21:44:32ZKarinGThe Edit screen handles Tax Amount and Total Amount differently depending on how whether Contributions are data entered with or without priceset.A. What's happening? The Edit screen handles Tax Amount and Total Amount differently depending on how whether Contributions are data entered with or without priceset. This results in an error on when trying to (empty Edit ->) Save a Cont...A. What's happening? The Edit screen handles Tax Amount and Total Amount differently depending on how whether Contributions are data entered with or without priceset. This results in an error on when trying to (empty Edit ->) Save a Contribution that has Sales Tax associated with it and is generated without a priceset. The error prompts users to manually adjust the Total Amount (and/or the Fee Amount and/or the Net Amount themselves and that results in bad data;
B. Can one use JMA's lineItem editor extension fix this? No - the civicrm_line_item data themselves are correct. Everything is properly recorded in both civicrm_line_item as well as in civicrm_contribution [screenshots at the bottom]. The issue is the math/data handling that is being done when the Edit screen is invoked.
C. Is this a specific Client issue for you? No it's not - it's a stripped down real issue example to point out that we need to standardize and define/review Tax Amount, Fee Amount, Net Amount, Total Amount, Contribution Total, Subtotal, Line Total, Total Price and use the calculations/definitions across all CiviCRM pathways or we'll continue to play whack-a-mole on Sales Taxes.
D. What would be a solution? We need to decide on what the Edit screen and math should look like - and make that independent of whether the contribution and it's associated line items were originally created with a priceset or not.
Setup:
* CiviCRM 5.3.0;
* Tax and Invoicing Enabled;
* 5% Sale Tax associated with Financial Type 'Taxable Item";
* lineItem editor extension installed;
**Contribution 4392 - Contribution w/ Sales Tax and NO priceset**
Steps to reproduce:
Contributions -> New Contribution:
![image](/uploads/c2eda8ae1cfd343cab99881e652533ec/image.png)
Save
![image](/uploads/c88751015be56d68fb20888f0ba60ab2/image.png)
Edit -> Save -> Error:
![image](/uploads/2e97f54b08ec71b81b576c1808befebf/image.png)
**Contribution 4394 - Contributions w/ Sales Tax and priceset**
Steps to reproduce:
Contributions -> New Contribution:
![image](/uploads/82622cd3ac88b1ad74e3260d4d8eb472/image.png)
Save
Edit (and Saves without Errors)
![image](/uploads/54f7680d542ce01423c3a3fe770a9b5d/image.png)
**Summary - two Contributions are identical except for how they were generated - 4394 can be edited and 4392 can not;**
![image](/uploads/58d888db9b42763385711ac7c14e53b1/image.png)
![image](/uploads/e839c09cb6ce57f991916204905d93e8/image.png)
![image](/uploads/14ff617650a153b32dc9b8dc566d947c/image.png)https://lab.civicrm.org/dev/core/-/issues/260Refunding a Contribution that has Sales Tax associated produces Validation Error2018-11-10T13:39:14ZKarinGRefunding a Contribution that has Sales Tax associated produces Validation ErrorTrying to isolate / reproduce some issues with Sales Taxes breaking them down into small bits; this is on 5.3.0
Add Contribution $100 -> Financial Type has Sales Tax associated with it 5% -> Contribution gets recorded as $105 (correctly...Trying to isolate / reproduce some issues with Sales Taxes breaking them down into small bits; this is on 5.3.0
Add Contribution $100 -> Financial Type has Sales Tax associated with it 5% -> Contribution gets recorded as $105 (correctly):
![image](/uploads/ff97c0324f00a6702b052d956be88af2/image.png)
Edit -> change Contribution Status -> from Completed to Refunded -> hit Save;
![image](/uploads/118ca44b7e956503aa7c1360a846a5a4/image.png)
Net Amount really is $105 and Fee Amount really is $0 - changing them to anything else would be incorrect.
See https://github.com/civicrm/civicrm-core/pull/9948 for original discussionhttps://lab.civicrm.org/dev/core/-/issues/252Add force search parameters to search forms.2022-08-20T05:03:37ZjitendraAdd force search parameters to search forms.Url parameters in search forms are not complete. There is yet no support to search for financial type id, pay later, etc in Contribution Search form using the URL.Url parameters in search forms are not complete. There is yet no support to search for financial type id, pay later, etc in Contribution Search form using the URL.jitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/251Fix batch copy for membership type field2019-05-01T06:03:03ZyashodhaFix batch copy for membership type fieldSteps to replicate :
1. Create a profile with membership type field.
2. Click Find Memberships and select a few members and do Update multiple memberships with above profile.
3. Click on copy icon for membership type, it doesn't copy ov...Steps to replicate :
1. Create a profile with membership type field.
2. Click Find Memberships and select a few members and do Update multiple memberships with above profile.
3. Click on copy icon for membership type, it doesn't copy over 1st row to the restyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/237Hide Drupal8 Administer Menu bar on CiviCRM pages2018-08-12T23:41:09ZMonish DebHide Drupal8 Administer Menu bar on CiviCRM pagesCurrently on Drupal8-Civi instance, when you visit any CiviCRM page you will find a Drupal8 Admin menu bar behind the CiviCRM menu bar:
![Screen_Shot_2018-07-06_at_2.01.21_PM](/uploads/ac5b9febff84a27b494d2d009aaf3910/Screen_Shot_2018-07...Currently on Drupal8-Civi instance, when you visit any CiviCRM page you will find a Drupal8 Admin menu bar behind the CiviCRM menu bar:
![Screen_Shot_2018-07-06_at_2.01.21_PM](/uploads/ac5b9febff84a27b494d2d009aaf3910/Screen_Shot_2018-07-06_at_2.01.21_PM.png)
Proposal
---------
It won't be a good idea to expand the CiviCRM menu bar to the width of Drupal8 menu bar, instead hide the Drupal8 menu bar when we are on Civi page. To restore the Drupal8 menu, you can use the existing CiviCRM actions to toggle CiviCRM menu on any Civi page.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/231Drupal8: Problem with user registration confirm email flow2019-06-13T15:11:27ZwannesderoyDrupal8: Problem with user registration confirm email flowIn our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user wa...In our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user was denied permission to the password form. And the onetime login link in the mail was always invalid.
In the CRM/Utils/System/Drupal8.php file we changed some of the user registration logic to be the same as the default Drupal 8 way.
1) First issue was that the user account was not set to 1 (active) when $verify_mail_conf was set to true. In default drupal this is the case.
2) Second issue was the user was logged in immediately after sending the verification mails, this should not happen when the verify_mail_conf setting is true. User may only be logged in when checking the mail and following the onetime login link.
[civicrm-core-d8-create-user-fix.patch](/uploads/f4b996b99de84406272e6742ca8b9912/civicrm-core-d8-create-user-fix.patch)https://lab.civicrm.org/dev/core/-/issues/226use decimal point from config to fix european numbers format2018-08-19T22:52:39Zsuniluse decimal point from config to fix european numbers formatFormat Amount using hardcoded decimal point, which is not fit for european format.Format Amount using hardcoded decimal point, which is not fit for european format.5.6https://lab.civicrm.org/dev/core/-/issues/219Improve consistency displaying "Test Transactions"2018-07-24T19:41:11Zmattwiremjw@mjwconsult.co.ukImprove consistency displaying "Test Transactions"There are currently a number of inconsistencies with displaying test transactions:
1. There is either no indication, or it is not obvious that you are viewing a test contribution/recur/membership when viewing the details.
2. Test members...There are currently a number of inconsistencies with displaying test transactions:
1. There is either no indication, or it is not obvious that you are viewing a test contribution/recur/membership when viewing the details.
2. Test memberships do not appear in the contact membership tab, but test contributions/recurring contributions do.
Proposal:
1. Add some "help" text that appears above the entity detail when viewing the entity if it is a test transaction.
2. Show test memberships in contact membership tab so it is consistent with other tabs.5.5.0https://lab.civicrm.org/dev/core/-/issues/214Suppress inappropriate error when trying to schedule mailing for today2022-08-17T05:03:36ZJoeMurraySuppress inappropriate error when trying to schedule mailing for todayWhen trying to schedule a mailing, there are two fields: one for date and one for time. If you select today for date a popup error immediately says that 'Error
The scheduled date and time is in the past'. It would be better if this was d...When trying to schedule a mailing, there are two fields: one for date and one for time. If you select today for date a popup error immediately says that 'Error
The scheduled date and time is in the past'. It would be better if this was delayed somewhat, though there are many possibilities. User ends up thinking Civi doesn't know correct date.
How about if validation changed so that if date==today and time is null, then set time=now()+1 minute?Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/206Filter webform dropdown through relationship type2018-10-15T12:00:57ZshitijgFilter webform dropdown through relationship type**Overview:**
This ticket is targeted at improving the data filtering capabilities of the ‘Existing Contact’ field of the Webform CiviCRM.
With this new filtering - we will be able to filter the existing contact field with values deri...**Overview:**
This ticket is targeted at improving the data filtering capabilities of the ‘Existing Contact’ field of the Webform CiviCRM.
With this new filtering - we will be able to filter the existing contact field with values derived from a particular relation type that a contact has with another contact.
**How it works currently:**
Currently we have the ability to filter through Groups and Tags
We also currently have the ability for the existing contact field on the webform to autoload static value through a predefined relationship to another ‘existing contact’ field on the webform.
i.e.
If Contact 1 is the Case Client and has a relationship: ‘Employee of’ with Ashville School, we can add another contact field on the webform and enable the relationship fields on it to:
‘Employee of’.
![Screen_Shot_2018-06-25_at_18.39.01](/uploads/c00aa3024f6e72160d7f781b1778f302/Screen_Shot_2018-06-25_at_18.39.01.png)
We will also have to edit the ‘Existing Contact’ field and select it’s default value to load from a relationship.
![Screen_Shot_2018-06-25_at_18.40.02](/uploads/0b316d87ec5e6fb5055765411b4dea1e/Screen_Shot_2018-06-25_at_18.40.02.png)
This would mean that Contact 2 on the webform will be the value coming from the ‘Employee of’ relationship with Contact 1 (in this case - for our selected case client - it would be ‘Ashville School’)
In this way we are able to load the value from a relationship that 2 contacts have, however, we can not do this dynamically.
I.e.
Contact 3 (another contact on the webform) cannot be set to filter and give back a list of all the students at Ashville School (have a relationship ‘Student at’ with ‘Ashville School’, so that the user filling the form can select one of the students.
**How we would like to improve the functionality:**
With this new implementation, we will be able to filter values for an ‘Existing Contact’ field on the webform through specifying a relationship and relationship with.
Continuing from our previous example where:
Contact 1 - Joe Bloggs (Case Client)
Contact 2 - Ashville School (Has the relationship ‘Employer of’ with Joe Bloggs)
Contact 3 - We need a list of all students at Ashville School and be able to select this on the form
To achieve this - we will need the following configurations in the filters section of the ‘Existing Contact’ field:
![Screen_Shot_2018-06-25_at_18.36.55](/uploads/b5ab2bbe9d46659399bae4739b6010e3/Screen_Shot_2018-06-25_at_18.36.55.png)
In the above example, the user will be able to select:
Relationship Type - ‘Student at’
Contact - ‘Contact 2’
This would mean when the webform loads, it will populate all the students at Contact 2 (Ashville School) as option values for Contact 3.https://lab.civicrm.org/dev/core/-/issues/204Add testcases to civicrm-core PR #112912021-09-13T00:08:27ZvarshithAdd testcases to civicrm-core PR #11291Ref. https://github.com/civicrm/civicrm-core/pull/11291
The above PR adds case tokens support to email activities.
We need test cases for the above PR to complete it.Ref. https://github.com/civicrm/civicrm-core/pull/11291
The above PR adds case tokens support to email activities.
We need test cases for the above PR to complete it.https://lab.civicrm.org/dev/core/-/issues/198Allow permission to "From Email Addresses"2022-08-16T05:03:36ZfrancescbassasAllow permission to "From Email Addresses"In order to solve this SE question [How to disable “From email address” for unauthorized users?](https://civicrm.stackexchange.com/questions/7236/how-to-disable-from-email-address-for-unauthorized-users) we have been using this extension...In order to solve this SE question [How to disable “From email address” for unauthorized users?](https://civicrm.stackexchange.com/questions/7236/how-to-disable-from-email-address-for-unauthorized-users) we have been using this extension [From Email Address Permission](https://civicrm.org/extensions/from-email-address-permission). The extension is very simple but hard to mantain because we were forced to overwrite a couple of core files.
Recently we see some core changes in the direction to [enhance "From Email Adresses"](https://github.com/civicrm/civicrm-core/pull/11047) and we would like to see also the possibility to add a From Email Address permission system.
We imagine something like ACL at report configuration level but in this case at from email address configuration level:
![from-email-adresses-permissions](/uploads/c509cdf596722aae401c51486476ddec/from-email-adresses-permissions.png)
To ensure that nothing breaks *Permission* configuration for the default From Email Address must be always *CiviMail: Access CiviMail* and *ACL Group/Role* must be empty.https://lab.civicrm.org/dev/core/-/issues/166updateAllMemberships in memberschip BAO crasches out of memory on large numbe...2022-08-14T05:03:44ZJoostupdateAllMemberships in memberschip BAO crasches out of memory on large numbers of membersWe have a database with about 1.3 million memberships. the scheduled task to update membership statuses crashes with an out of memory error.We have a database with about 1.3 million memberships. the scheduled task to update membership statuses crashes with an out of memory error.https://lab.civicrm.org/dev/core/-/issues/113Add new api handler 'current_domain' along the lines of 'user_contact_id'2022-06-13T01:56:11ZeileenAdd new api handler 'current_domain' along the lines of 'user_contact_id'Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the ca...Several api accept domain_id & in almost all cases the value passed is the current domain id. I think we should be able to set that as a default for api like membership type, instead of requiring it to be passed in as is currently the case.
With this we could change
```
function _civicrm_api3_membership_type_create_spec(&$params) {
// todo could set default here probably
$params['domain_id']['api.required'] = 1;
```
to
```
function _civicrm_api3_membership_type_create_spec(&$params) {
$params['domain_id']['api.default'] = 'current_domain';
```
We have a similar thing in place for 'user_contact_id' here
https://github.com/eileenmcnaughton/civicrm-core/blob/fee14197b427c1781e369e5bfd36816afad6d7ee/api/v3/utils.php#L2086 and I feel we could expand that piece of code.
Pinging @totten because Tim re-wrote that earlier handling of user_contact_id & may have some points he wishes to interjecthttps://lab.civicrm.org/dev/core/-/issues/109Categorizing case types2022-08-12T05:03:24ZreneolivoCategorizing case types#### Issue
Currently case types can have a name, but can't be grouped by a common category. Right now you can have multiple case types dealing with vacancies, (Ex: Publish available position, Conduct interview with candidate, Start recr...#### Issue
Currently case types can have a name, but can't be grouped by a common category. Right now you can have multiple case types dealing with vacancies, (Ex: Publish available position, Conduct interview with candidate, Start recruitment campaign, etc.), but there's no way to tell that these case types belong in a common conceptual group that differentiates them from other case types.
#### Proposed solution
Adding a *category* field to the *CaseType* schema.
#### Use cases
* Separating the administration of case types, such as the ones from application/vacancies.
* Using the case category to run specific actions when a new case is created or it's closed. For example, if a case with the category "Funds Raising" is closed, send a special notification to the accounts department. (this would be implemented on the extension side).
#### Core PR
https://github.com/civicrm/civicrm-core/pull/12098https://lab.civicrm.org/dev/core/-/issues/104Get Tests to pass on PHP7.22018-12-10T03:36:53ZseamusleeGet Tests to pass on PHP7.2This is a meta issue for getting our tests to run against PHP7.2 ping @monish.deb @eileen @tottenThis is a meta issue for getting our tests to run against PHP7.2 ping @monish.deb @eileen @totten5.10seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/100Membership Detail report throw DB error2018-05-25T05:45:46ZyashodhaMembership Detail report throw DB errorMembership Detail report throw DB error due to acl clause applied twice.Membership Detail report throw DB error due to acl clause applied twice.5.3.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/97Improve the process and documentation for "How to Contribute" so that Proposa...2018-10-14T22:43:57Zjustinfreeman (Agileware)Improve the process and documentation for "How to Contribute" so that Proposals can be discussed, reviewed and accepted (rejected) before a PR is createdCreating this issue to start the discussion about how we as a community can improve the process and documentation for "How to Contribute", the relevant pages are:
* https://docs.civicrm.org/dev/en/latest/core/contributing/
* https://doc...Creating this issue to start the discussion about how we as a community can improve the process and documentation for "How to Contribute", the relevant pages are:
* https://docs.civicrm.org/dev/en/latest/core/contributing/
* https://docs.civicrm.org/dev/en/latest/tools/issue-tracking/#guidelines
This specifically relates to adding new features to CiviCRM core or changing existing features in CiviCRM core (I'll just call these collectively "Proposal"). It could equally apply to CiviCRM extensions, since the approach is the same - just the ecosystem is more distributed.
The current documented process revolves around submitting a PR on Github with the associated code. The problem with this process is it has high potential to be rejected, because no prior process of discussion, review or approval has been sought for the Proposal. When you think about it the current state, it's a bit backwards. So this is incredibly frustrating for people wishing to contribute to the project and a huge waste of time. If the PR never had a chance of being accepted conceptually, then there is no point at all in spending time on writing code, testing it, documenting it etc. PRs cost money to produce and no one likes wasting money!
So the process change I would like to see is to move away from PRs being the initial step for the Proposal. The PR should be the resultant of the Proposal process.
A Proposal should be created in Gitlab (not a PR in Github). The reasoning for the change and the proposed approach for implementing the change should be documented with the Proposal.
The Proposal should be available for review and feedback on Gitlab for a set period of time, 2 to 4 weeks maximum (for example). This step is important, Proposals should not languish, unattended.
At the conclusion of that time, the Proposal should be: Accepted, Rejected or Require Further Review; by a **new team** (CiviCRM Proposal Team) responsible for reviewing Proposals. **This should not be the responsibility of the existing CiviCRM Core Team, which are currently under resourced and over worked**. For the CiviCRM Proposal Team, we need new people to step up and own this process, so that the work load can be shared between Proposals and PRs. CiviCRM Core Team should not have to do both processes - we want to reduce their work load. This is why I think establishing a new CiviCRM Proposal Team to review Proposals is fundamental to this improvement.
If the Proposal is Accepted then related PR(s) can be created and they individually can go through the code review process.
The key change here is that the PR(s) for this Proposal will be accepted following passing code reviews. Any debate about the merits of the change or new features should occur on the Proposal, during the Proposal review stage. Not during a review of the PRs.
Proposals are for planning and implementation.
PRs are for code management.
This issue has also been raised on separate the discussion being had on this PR, https://github.com/civicrm/civicrm-core/pull/11956#issuecomment-385849221
Thanks @eileen
Let's discuss!justinfreeman (Agileware)justinfreeman (Agileware)https://lab.civicrm.org/dev/core/-/issues/92Prevent deletion of groups which are used as search parameters of Smart Groups2023-04-20T08:59:49ZEvanPrevent deletion of groups which are used as search parameters of Smart GroupsIt seems that a group (static or Smart) being used a search parameter for a Smart Group can be deleted. Best case scenario is the Smart Group just has that many fewer contacts in it and we go on with life. We had an issue on a client sit...It seems that a group (static or Smart) being used a search parameter for a Smart Group can be deleted. Best case scenario is the Smart Group just has that many fewer contacts in it and we go on with life. We had an issue on a client site where there were so many contacts and so many groups, that rebuilding the Smart Group cache was causing a fatal DB error whether it (Updating Smart Group counts) was done manually or via the scheduled job. Proposed approach is to prevent deletion of groups that are dependencies for other groups. Example workflow:
1. A user with permissions to delete groups chooses to delete a group by selecting the "Delete" option from the "More" link on the Manage Groups page located here: Navigation Menu > Contacts > Manage Groups (this is the only place a user can delete a group, I believe)
1. The system (CiviCRM) does a check in the background to determine if the group being deleted is used as a search parameter in any active/non-deleted Smart Groups
1. If the group being deleted is determined to be "in use" by a Smart Group(s), don't allow the group to be deleted. Instead…
1. Show a message in the "Confirm Group Delete" notification that the group cannot be deleted as it's being used by a Smart Group(s). List the name of the Smart Group(s), preferably with the name(s) linked to that/those group(s)
I am inquiring with our client if they are willing to put funds (and how much) into fixing this. I have confirmed on demo master that one can delete a group that is a dependency for another group, though there were no ill effects. My assumption / theory is there just aren't enough contacts or groups for the rebuilding of Smart Group counts to fail.https://lab.civicrm.org/dev/core/-/issues/86CIVICRM_MAIL_LOG_AND_SEND does not work properly2018-11-18T21:03:25Zmattwiremjw@mjwconsult.co.ukCIVICRM_MAIL_LOG_AND_SEND does not work properlyIn the packages/Mail it is mistyped as "CIVICRM_MAIL_LOG_AND SEND" (ie. missing an underscore): https://github.com/civicrm/civicrm-packages/pull/204
In CiviCRM core the administrator is not notified if it is set: https://github.com/civi...In the packages/Mail it is mistyped as "CIVICRM_MAIL_LOG_AND SEND" (ie. missing an underscore): https://github.com/civicrm/civicrm-packages/pull/204
In CiviCRM core the administrator is not notified if it is set: https://github.com/civicrm/civicrm-core/pull/12037
In the docs it is missing altogether: https://github.com/civicrm/civicrm-dev-docs/pull/5265.2.0