CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-02-28T05:03:22Zhttps://lab.civicrm.org/dev/core/-/issues/3466On_hold field for phone record2024-02-28T05:03:22Zmagnolia61On_hold field for phone recordOverview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better...Overview
----------------------------------------
I think by design the civicrm_phone table should also have an on_hold field in order to 'block' individual phone numbers from receiving calls and texts.
I think this would help to better refine the means to comply to privacy regulations.
Current behaviour
----------------------------------------
Only on a contact level do_not_call and do_not_sms are available as options
Proposed behaviour
----------------------------------------
Just like the civicrm_email table individual phone numbers can be 'disabled' from receiving (automatic) texts and calls.
Comments
----------------------------------------
I am not really able to code this but would be able to help think about it and help test.https://lab.civicrm.org/dev/core/-/issues/3641[Feature] More (privacy) options for click tracking2024-02-23T05:03:23Zmarcelklehr[Feature] More (privacy) options for click trackingHello,
I would like to have more options regarding click tracking in mailings.
1. Currently, every user can decide for themselves if they want to use it. I would like to be able override this with a setting, so i can e.g. disable click...Hello,
I would like to have more options regarding click tracking in mailings.
1. Currently, every user can decide for themselves if they want to use it. I would like to be able override this with a setting, so i can e.g. disable click tracking entirely.
2. Click-throughs are currently tracked by mail-adress, which is not conformant to the privacy laws in Germany, or at least requires additional consent. It would be nice to be able to limit this to just the numbers per link, without personal data. I would like to have this as an admin option, too.
Thanks for your consideration and this awesome software!https://lab.civicrm.org/dev/core/-/issues/3633Error notification when scheduling civimail for current day may be incorrect2024-02-21T05:03:32ZrobinhoodError notification when scheduling civimail for current day may be incorrectThis is a minor issue. When setting up a civimail at a scheduled date and time, any time on the current day triggers "The scheduled date and time is in the past" error popup, even if the scheduled time is in the future. The error does n...This is a minor issue. When setting up a civimail at a scheduled date and time, any time on the current day triggers "The scheduled date and time is in the past" error popup, even if the scheduled time is in the future. The error does not prevent the civimail from being scheduled for the current day, but it is confusing to the user.
Edit: Using Civicrm 5.3.2 on Wordpress 4.9.8https://lab.civicrm.org/dev/core/-/issues/3543Provide warning for mailings that are being edited to prevent Mailing not sav...2024-02-12T05:03:28ZlarsssandergreenProvide warning for mailings that are being edited to prevent Mailing not saved errors.In our org, we have multiple users who might need to edit the same mailing. Unfortunately, this creates the possibility that someone leaves the mailing open and someone else opens it and begins editing, leading to the "Mailing not saved....In our org, we have multiple users who might need to edit the same mailing. Unfortunately, this creates the possibility that someone leaves the mailing open and someone else opens it and begins editing, leading to the "Mailing not saved. Content may be out of date" error (and tears and hair loss due to lost changes). In our case, this is mostly one user putting together a mailing and another user editing it, fixing formatting errors, etc. It's very hard to train users who are used to Google Docs not to leave the tab open, leading to the need for rigid hand off procedures. We've been trying to get people trained for years, but this continues to be an issue that we waste a lot of time on.
Would it be feasible to add some kind of warning that would warn another user who wants to open another mailing that is already open for editing? I'm thinking just setting a flag on the mailing with a 30 minute expiration, which is updated every time the mailing or content is saved. The flag would be unset when the user exits the mailing. Mailings with the flag would have a warning on the draft mailings screen that would say "Someone else may be editing this mailing" or a warning before opening the mailing. This won't be a perfect solution, but I think it would prevent 95% of problems.
We're using Mosaico, but I think this would be implemented in core and apply to both kinds of mailings.https://lab.civicrm.org/dev/core/-/issues/3446Please include Contributors and Reviewers website address in the CiviCRM Rele...2024-01-25T05:03:22Zjustinfreeman (Agileware)Please include Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog PostThis is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profi...This is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profiles.
It would be a nice way of giving credit to all people involved by including a link to their website.
Appreciate this requires some changes to how the release notes and blog posts are compiled, happy to help make this happen.https://lab.civicrm.org/dev/core/-/issues/3433FormBuilder: allow multiple email/phone/address blocks with pre-set location ...2024-01-21T05:03:28ZStéphane Lussierstephane@symbiotic.coopFormBuilder: allow multiple email/phone/address blocks with pre-set location typesOverview
----------------------------------------
I like the flexibility of _afform_ and its ability to edit multiple fields on the fly :
![afform](/uploads/132b8354b92569465f49a464dd9fd4f7/image.png)
...but sometimes, it would be ni...Overview
----------------------------------------
I like the flexibility of _afform_ and its ability to edit multiple fields on the fly :
![afform](/uploads/132b8354b92569465f49a464dd9fd4f7/image.png)
...but sometimes, it would be nice if it could also do this :
![profile](/uploads/83b66e2904f2391d6d7d56e971d279bd/image.png)
Current behaviour
----------------------------------------
Afform currently exposes all its flexibility to the end user by providing all available options to composite fields.
Proposed behaviour
----------------------------------------
Provide the ability to pre-configure a given amount of multiple fields in order to simplify the end-user interface and expose those fields immediately once the form is loaded.
Comments
----------------------------------------
In the case of an email field, we would be able to decide in advance the location of each field and/or specify which of those fields should be the main one.https://lab.civicrm.org/dev/core/-/issues/3363CiviEvent Cart seems broken completely. Any chance of fixing it?2024-01-07T05:03:24ZtapashCiviEvent Cart seems broken completely. Any chance of fixing it?CiviEvent Cart seems broken completely on 5.x . Any chance of fixing it please? thanksCiviEvent Cart seems broken completely on 5.x . Any chance of fixing it please? thankshttps://lab.civicrm.org/dev/core/-/issues/3353No way to empty the cart procedurally or via a URL2024-01-05T05:03:31ZTomAndersonNo way to empty the cart procedurally or via a URLHow do we get rid of anything in the cart? For example, if it's after 1 hour, we may want to dump the entire cart.
For example, could I do an AJAX call like this? `{crmURL p='civicrm/event/empty_cart' q="reset=1" fb=1}`
I'm not seeing ...How do we get rid of anything in the cart? For example, if it's after 1 hour, we may want to dump the entire cart.
For example, could I do an AJAX call like this? `{crmURL p='civicrm/event/empty_cart' q="reset=1" fb=1}`
I'm not seeing anything to this effect.
Alternately, how can we do this procedurally (in PHP).https://lab.civicrm.org/dev/core/-/issues/3203When using the Search Kit and Form Builder to implement a front-end Search Li...2023-12-20T05:03:24Zjustinfreeman (Agileware)When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_1744...When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_174423](/uploads/a065207345c884f41eae014ae25e1a8d/Screenshot_20211112_174423.png)https://lab.civicrm.org/dev/core/-/issues/793Improve administrative experience for managing/upgrading bundled extensions2023-12-11T05:03:27ZtottenImprove administrative experience for managing/upgrading bundled extensionsBackground
----------
The canonical release of CiviCRM now includes a couple extensions (e.g. `org.civicrm.api4` and `com.iatspayments.civicrm`). The business-need for distributing bundled extensions will continue to grow as we progress...Background
----------
The canonical release of CiviCRM now includes a couple extensions (e.g. `org.civicrm.api4` and `com.iatspayments.civicrm`). The business-need for distributing bundled extensions will continue to grow as we progress on "leap by extension".
Problem
-------
Suppose we have a process like this:
1. Administrator Alice downloads/installs CiviCRM 5.0 with a bundled copy of an extension, APIv4 (4.0.0).
2. Developer Bob publishes a new version of APIv4 (4.0.1).
3. Alice sees APIv4 (4.0.1) and upgrades it.
4. Bob publishes another version of APIv4 (4.1.0).
5. The next version of CiviCRM (5.1.0) is released. It bundles APIv4 (4.1.0).
6. Alice installs CiviCRM (5.1.0). It includes APIv4 (4.1.0), but Alice's system still uses APIv4 (4.0.1).
The situation should be resolvable by either removing or upgrading Alice's extra copy of APIv4 (4.0.1) stored in the site's customizable `extensionsDir` (e.g. `$WEBROOT/sites/default/files/civicrm/ext`).
However, the situation can be confusing (leading to support requests). This particularly true if there are any intertwined dependencies.
Analysis
--------
Why does this happen? Well, CiviCRM loads extensions from a list of *prioritized layers*:
* (E1) Extensions installed by the web-based administrator in the customizable extensionsDir (e.g. `$WEBROOT/sites/default/files/civicrm/ext`).
* (E2) Extensions installed with the CiviCRM bundle (e.g. `$WEBROOT/sites/all/modules/civicrm`).
* (E3) Extensions installed in site's master composer project (e.g. `$WEBROOT/vendor`).
When Alice (step 3) downloads any extension manually (whether upgrade or anew), it goes into the first layer E1. The version she specifically downloads will always take precedence over any versions in layer E2/E3.
Generally, this prioritization is a result of two opinions that:
* Web-administrators tend to be "closer to the ground" on the goal/situation for a particular site -- their upstream providers (e.g. civicrm.org and/or saas/partner) are more disconnected. Therefore, *if* the admin forms an opinion about what version to run, then it should take precedence.
* Only one of those layers (the first) tends to be writable at run-time. This may be a general security prophylactic, or it may specifically be a protection in multitenant deployments.
Those opinions are valid in many cases, but they are certainly not universal. For example:
* Many web-based administrators are only casually engaged (e.g. they're not tracking the nitty-gritty of each release every day), and many don't really *want* to think about the versions of each extension. They may not realize their upgrade today causes them to take greater ownership over future upgrades.
* Many WordPress and Joomla builds are usually web-writeable, which means that they are not confined to the customizable `extensionsDir` -- one can put upgraded code in any location desired/appropriate/necessary.
Possible Resolutions
--------------------
There are several possible ways to resolve this. The choice is an *ambiguous question* -- none is stand-out obvious winner; each option involves a trade-off which has some impact on the developer-experience/administrator-experience and which will likely be good and bad for different groups of people. However, to resolve the ambiguous question, it may help to list the possible resolutions:
* **REORDER**: Change the order of the layers -- put the custom folder (E1) below the others (E2/E3).
* **Strengths**: It is probably the simplest change (i.e. the explanation and implementation are both short).
* **Challenges**: It inhibits the ability of site-owners to act as testers and early-adopters on those extensions. Also, when it goes live, it may cause unexpected changes for sites who have tried to manage these extensions on their own.
* **BLOCK**: In step 3, block Alice from upgrading the extension. She may only upgrade an extension if it's stored in E1. If an extension is provided by another layer (E2/E3), then prohibit downloads/upgrades that would go into E1. Provide messaging to indicate why upgrades aren't allowed.
* **Strength**: This tightens the general shape of deployments across the ecosystem, which would be an overall simplification that makes it easier to reason about the system.
* **Challenges**: It inhibits the ability of site-owners to act as testers and early-adopters on those extensions. It also puts a greater responsibility on upstream bundler to issue a new bundle whenever one if its constituent parts has a critical fix.
* **ADVISE**: After step 3, the "Manage Extensions" screen (and possibly the status-check screen) should display a notice indicating that an extension is overridden. The administrator still has the prerogative here, but the app should try harder to educate/inform them about the consequences/responsibilities.
* **Strength**: This is the most backward-compatible resolution -- it doesn't change the real behavior, so no one can accuse of breaking anything.
* **Challenges**: The underlying situation (multiple copies of the same extension) can be confusing, and we're giving more of a blessing. That may lead to questions like "what order should I apply upgrades in?" for which there may not be a simple+generic answers.
* **UPGRADE-IN-PLACE**: In step 3, allow Alice to upgrade the extension. However, the upgrade should **not** go into the extension folder -- it should replace the existing code (wherever that may be). If the folder is not writeable, display a warning with advice on how to make it writeable/upgradeable.
* **Strength**: Most people reading the user-interface (but without any expertise in CMS+Civi file-structures) would probably expect this behavior.
* **Challenges**: The extensions can live in spaces which we don't "own" (like E3 - `$WEBROOT/vendor`). It's a bit scary to automatically delete a whole file-tree if we haven't traditionally "owned" that part of the filesystem. Also, if Alice in step 3 had upgraded really far ahead (APIv4 4.3.beta1), then the upgrade in step 6 would revert her system to 4.2.0.
* **DEFER => COMPOSER**: This issue reflects only one of several edge-cases in managing dependencies for a build. Don't spend any more time trying to solve this one scenario -- instead, focus energy on adopting a more powerful build system like `composer`, where their documentation/workflows/UIs address the various edge-cases.
* **Strength**: More comprehensive approach. More "industry standard".
* **Challenges**: Generally, longest process of any of this list. Most extensions aren't currently accessible via `composer` (although there's a [proof-of-concept bridge](https://github.com/totten/comex)). `composer` is primarily a CLI tool, and it's not currently widely deployed among Civi sites, so adoption will be an undertaking.
* **VERSION-PRECEDENCE**: Continue to allow extension code to be stored in all these locations. However, change prioritization -- it doesn't matter *where* the extension is stored. It only matters *what the version number* is. Highest local version wins.
* **Strength**: This also feels intuitive to me.
* **Challenges**: During the life of an extension, the absolute URL+path of its assets may fluctuate. For some use-cases (where hyperlinks and paths are integrated with another system or stored as content), this could cause problems.https://lab.civicrm.org/dev/core/-/issues/3129The way the Most Recent Activity column on Find Cases is calculated makes no ...2023-12-04T05:03:27ZDaveDThe way the Most Recent Activity column on Find Cases is calculated makes no senseIt shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do no...It shares code with the Case Dashboard, where the Most Recent Activity column only appears in a section for cases that have _recent_ activity. But on Find Cases depending on your search criteria it will of course include cases that do not have recent activity. For those cases, the column displays blank, when it really should simply display the most recent activity, whenever it was.
To reproduce, create a case and complete an activity. Wait 2 weeks. Then do a find cases and look at the Most Recent Activity column for that case.
Does Find Cases even need this column?https://lab.civicrm.org/dev/core/-/issues/4734ADMIN_UI: default checkbox2023-11-03T15:31:20ZGuillaumeSorelADMIN_UI: default checkboxCould it be possible to have checkboxes per default for each new admin screen using SK, so it becomes possible to select multiple lines (for mailings, messages templates, custom fields...) and proceed bulk actions on them, especially del...Could it be possible to have checkboxes per default for each new admin screen using SK, so it becomes possible to select multiple lines (for mailings, messages templates, custom fields...) and proceed bulk actions on them, especially delete?
New SK screens are sweet but actions still need to be proceeded one-by-one.https://lab.civicrm.org/dev/core/-/issues/2972track CiviMail metrics by mailing group2023-10-24T05:03:27Zhescotrack CiviMail metrics by mailing groupOverview
----------------------------------------
_Please describe your improvement in detail._
As a user of CiviMail, when examining the delivery and performance metrics on a mailing which was sent to multiple mailing groups, I should ...Overview
----------------------------------------
_Please describe your improvement in detail._
As a user of CiviMail, when examining the delivery and performance metrics on a mailing which was sent to multiple mailing groups, I should be able to exclude mailing groups from the metrics for that mailing to observe how each mailing group a recipient of a mailing is performing. In the recipients section of the report, each group should be associated with a checkbox which will control whether an included (or excluded ???) group is accounted for in the metrics displayed in a view of the report.
Example use-case
----------------------------------------
At this url, and those which I can drill down to from here:
/civicrm/mailing/report?mid=${mailing_id}&reset=1
by toggling on or off checkboxes and hitting a refresh button, I should be able to update a the metrics on the report view; and any view accessible by drilling down through the available links and buttons, should clearly indicate which mailing groups are accounted for by the metrics displayed on that drilled-down-to view.
Current behaviour
----------------------------------------
_What is currently possible? What limit ?_
Currently to achieve this level of granularity in the reporting views I have to create multiple mailings, being careful in how I set them up to exclude mailing groups which were included on previous mailings. This works, but is unnecessarily cumbersome to set up; and to track the results, cluttering my browser with multiple open tabs to monitor results on the multiple mailings.
Proposed behaviour
----------------------------------------
_What should happen? How is this better? If appropriate/available, include any wireframes or mockups._
I would rather have a single mailing defined by its content, and the ability to parse the metrics on that mailing by recipient mailing group by toggling checkboxes.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
Thanks again.https://lab.civicrm.org/dev/core/-/issues/2794Sort order of userdashboard event listing2023-10-21T13:17:38Zmagnolia61Sort order of userdashboard event listingWhile in the event dashboard I understand the registered_date to be the sort order,
In the userdashboard tab for events a sort order by event startdate would be more logic.
I have been searching where this is configured, but could not f...While in the event dashboard I understand the registered_date to be the sort order,
In the userdashboard tab for events a sort order by event startdate would be more logic.
I have been searching where this is configured, but could not find it.
Basically I'm asking
1) if more people agree with the default sort order by event date
2) where to find a place to change the default sort order in the user dashboard tabhttps://lab.civicrm.org/dev/core/-/issues/702remove price set options from UI if only CiviMember is enabled2023-10-11T05:03:16Zgernerremove price set options from UI if only CiviMember is enabledWhen only CiviMember is enabled as active component, menu for setting new price sets (civicrm/admin/price) is visible, but throws an DB syntax error.
When CiviContribute is also enabled, the same menu works, since price sets are meant t...When only CiviMember is enabled as active component, menu for setting new price sets (civicrm/admin/price) is visible, but throws an DB syntax error.
When CiviContribute is also enabled, the same menu works, since price sets are meant to create/interact with contributions.
Since CiviContribute and CiviMember are two distinct components, I consider this as a bug.
Expected behaviour is that menu for new price sets only appears on UI if CiviContribute is enabled.https://lab.civicrm.org/dev/core/-/issues/2854ipAddress function and front-end proxies (like Varnish)2023-10-01T05:03:27ZAlanDixonipAddress function and front-end proxies (like Varnish)There are times where CiviCRM likes to know who it's talking to, i.e. the ip address of the visitor.
This matters especially when it gets passed on to a payment processor (e.g. for the purposes of mitigating card tumbling).
Here's the ...There are times where CiviCRM likes to know who it's talking to, i.e. the ip address of the visitor.
This matters especially when it gets passed on to a payment processor (e.g. for the purposes of mitigating card tumbling).
Here's the utility function that does that for several core-shipped payment processors:
https://github.com/civicrm/civicrm-core/blob/b599743f3daa46ab96c09ebe410fbb833cdd080f/CRM/Utils/System.php#L1293
This code is fairly naive, but notably makes use of the fact that Drupal 7 (and earlier) that had a function "ip_address()" that would pay attention to the Drupal configuration to be able to deal with front end proxies.
Unfortunately, D8/9 no longer includes this function, but more importantly, it also fails for other CMSs.
In researching this issue, I noticed that D8/9 now uses a core symphony function, which might provide a better solution than using our current CMS-specific approach.
Specifically, in Drupal, you can reliably get the 'client' ip with this: return Drupal::request()->getClientIp();
Assuming civicrm has a container similar to Drupal, a similar solution might be available for CiviCRM.
It's reasonable to ask whether ipAddress should be changed in this way - here's a search showing where this function gets called:
https://github.com/civicrm/civicrm-core/search?q=ipAddresshttps://lab.civicrm.org/dev/core/-/issues/2765Revisit the decision to enforce the CMS new user account option, allow CiviCR...2023-09-26T05:03:25Zjustinfreeman (Agileware)Revisit the decision to enforce the CMS new user account option, allow CiviCRM to create CMS user accounts when CMS has public registrations disabledRaising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when...Raising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when CMS has public registrations disabled**.
There are three key reasons to have this functionality:
1. Public registrations on websites attract spamming and therefore require moderation and anti-spam systems to be in place.
2. For member-only websites, the method to because a member is using the membership sign-up form (CiviCRM) and when the membership fee is paid, that's when the corresponding CMS user account should be created. And not by any other means.
3. With user account creation disabled, a separate and in some cases manual process needs to be performed to create the corresponding user account for members - which is a waste of effort.
With the current logic where CiviCRM uses the CMS configuration, the site must be open for public user registrations to support CiviCRM registering a member user account.
The change is relatively simple and would be removing the check of the user registration option for each supported CMS. Thus CiviCRM Profiles can be used to create CMS accounts.
See also related, _User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled_ - https://lab.civicrm.org/dev/user-interface/-/issues/41
Agileware Ref: CIVICRM-1809https://lab.civicrm.org/dev/core/-/issues/3444Contribution balance token2023-09-24T22:55:47Zmagnolia61Contribution balance tokenOverview
----------------------------------------
Would it be technically easy and functional desired to have contribution balance token?
Example use-case
----------------------------------------
We would like to advocate for an contrib...Overview
----------------------------------------
Would it be technically easy and functional desired to have contribution balance token?
Example use-case
----------------------------------------
We would like to advocate for an contribution balance token
Current behaviour
----------------------------------------
1. We want to send our customers an email with the amount due, or the amount that is pending refund.
2. There is a balance field in the event participant context. But this is absent in the contribution context.
Proposed behaviour
----------------------------------------
A custom token field like {contribution.balance} is available in the contribution context
Comments
----------------------------------------
Eileen opened an issue to enable a balance field for api4 (and an total paid field): https://lab.civicrm.org/dev/core/-/issues/2890https://lab.civicrm.org/dev/core/-/issues/645Use site email domain in place of bounce email domain for automated messages2023-09-23T05:03:26ZnishantBUse site email domain in place of bounce email domain for automated messagesHello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails wh...Hello there!!
We encountered a scenario where we can whitelist only one email domain to send emails. We want to use email domain (eg: bouncedomain.com) for bounce processing and a different one (sitedomain.com) for rest of the emails which works fine except that do-not-reply emails use the email domain set for bounce processing (bouncedomain.com) because of which AWS SES prevent those emails to be sent.
**Current behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@bouncedomain.com
**Expected behaviour:**
1. Regular emails: example@sitedomain.com
2. Bounce emails: bounce@bouncedomain.com
3. Do-not-reply emails: do-not-reply@sitedomain.com
Is there already a configuration to set that or would it be a good idea to add a field where we can set the email domain for do-not-reply emails ?
Thanks!https://lab.civicrm.org/dev/core/-/issues/2722Search kit - totals2023-09-07T05:03:27ZeileenSearch kit - totalsI had a super nice experience using search kit + afform to do a reconciliation last night. Being able to swap out the financial type & have it update without the overhead of a quick form reload was great & I was able to set up the contri...I had a super nice experience using search kit + afform to do a reconciliation last night. Being able to swap out the financial type & have it update without the overhead of a quick form reload was great & I was able to set up the contributions to edit in a popup via a link
What would have made it better would have been a grand total for the filtered results - I had to keep refreshing my civi-report to get totals
@colemanw just one for your mental list of feature requests