Feature request issueshttps://lab.civicrm.org/community/feature-request/-/issues2021-02-18T21:01:17Zhttps://lab.civicrm.org/community/feature-request/-/issues/29Add "About" page to simplify AGPL Section 13 compliance2021-02-18T21:01:17ZtottenAdd "About" page to simplify AGPL Section 13 compliance# Background
1. CiviCRM is published under AGPLv3.
2. Most CiviCRM extensions are also published AGPLv3.
3. It is common in our community for people to deploy, fork, patch, etc. code from others. (Witness: open-source in action!)
4. ...# Background
1. CiviCRM is published under AGPLv3.
2. Most CiviCRM extensions are also published AGPLv3.
3. It is common in our community for people to deploy, fork, patch, etc. code from others. (Witness: open-source in action!)
4. Under AGPLv3 Section 13, if you make a modified/derivative work, then there is an obligation to provide download links to your users.
5. CiviCRM Core has a standard download link in the footer -- but you can't do that for everything, and I've never noticed an extension providing download links to non-admins, and most people who use patches aren't going to edit code to tweak that notification.
6. There is no general/standard practice in how to address Section 13.
# Proposal
The footer should include a Legal/About. Add a built-in core page `civicrm/about` which:
* (a) summarizes CiviCRM's mission+model
* (b) summarizes the works being used for this deployment - authorship/copyright/publication URLs
* (c) optionally links to any site(s) where modifications are published (e.g. "All modified works are published at https://github.com/myorg")
Parts (a) and (b) can be standard/no-effort/out-of-the-box.
Part (c) would be unnecessary and blank for stock deployments. If you are an active implementer/developer in the habit of patching things, it can be a bit onerous to identify every patch in-app. But it should be easy to add your Github/Gitlab org-link. If someone suggests that you are out-of-compliance on Section 13, then this becomes an easy fix.
# Comments
(1) When I was an implementer, we used a patch similar to this on our Civi deployments. It actually went a bit further and allowed you download a live zip file of the civicrm tree (to ensure that we were meeting the obligation while keeping our project-management stuff private). However, I suspect many folks would have technical questions (e.g. "persuade me about performance/security/usability of a live zip on every Civi deployment"). Many folks already publish their forks on Github/Gitlab - so that feels like the path of least resistance.
(2) Item (b) would actually go beyond what's required. However, I think it's nice for our community to over-communicate credits.https://lab.civicrm.org/community/feature-request/-/issues/28CiviMail: "Blast addresses"2021-04-20T20:13:57ZtottenCiviMail: "Blast addresses"__Context__:
You're a CiviMail backend user, and you want to send a casual message to a group of contacts. But you're too lazy to login every time you want to send a message.
__One-Time Setup__:
* In CiviCRM, go to "Administer => Civ...__Context__:
You're a CiviMail backend user, and you want to send a casual message to a group of contacts. But you're too lazy to login every time you want to send a message.
__One-Time Setup__:
* In CiviCRM, go to "Administer => CiviMail => Blast Addresses".
* Create a "New Blast Address". Choose a list of include/exclude groups. Choose some other standard CiviMail options (like header/footer). The output is a unique address `blast.1234.abcd@example.org`
* In your personal email address book, add a contact for `blast.1234.abcd@example.org`
__Regular Usage__:
Send email `blast.1234.abcd@example.org`. CiviMail's IMAP scanner picks it up and immediately schedules a mailing.
__Considerations__:
* If your personal email gets hacked, then someone can blast on your behalf.
* If you have someone who you trust composing content -- but not managing contacts -- then you could give them a blast address. Don't need think about ACLs/etc.https://lab.civicrm.org/community/feature-request/-/issues/26Multi-lingual for multinational/global-scale2022-06-11T16:02:17ZtottenMulti-lingual for multinational/global-scale(This issue is not a singular problem with a singular fix. Think of it more as a long-term epic or general problem statement - it may entail several different approahces, issues, extensions, patches, phases, or experiments. My hope is to...(This issue is not a singular problem with a singular fix. Think of it more as a long-term epic or general problem statement - it may entail several different approahces, issues, extensions, patches, phases, or experiments. My hope is to capture some discussion from sprints+calls over the years, esp points from @ayduns @BjoernE @bgm @eileen @ejegg etal)
# Background
Internationalization (i18n) is the process of adapting a software system to support different languages and locales. For some organizations, their i18n needs are met by flagging one language for the entire system (e.g. an English organization uses the English language; a French organization uses the French language).
Other organizations require a more advanced form of i18n called *multilingual* -- this means that one organization offers its business-programs (eg events, conferences, newsletters, donation pages) in multiple languages *concurrently*. There are a few contexts in which multilingual makes sense:
* The organization targets a single region with multiple endemic languages. For example, in Canada, you may have an organization serving significant populations of French and English speakers. Similarly in Belgium (Flemish/French), southwestern US (English/Spanish), Switzerland (Swiss German/Swiss French/Swiss Italian), and so on. As a rule-of-thumb, few locales would have more than 3 endemic languages.
* The organization targets a large number of countries with diverse languages. For example, a pan-European organization might have 8 languages, and a global organization might have 30 languages.
When adapting business software to a multilingual organization, one might take an informal approach or a formal approach, by which I mean:
* __Informal translation (duplicates)__: The software remains effectively unchanged. If the user needs more languages, then he simply adds more records. Thus, if the user wants to make a bilingual newsletter, then he actually makes two distinct `Mailing`s (one per language). For a bilingual fundraising campaign, he makes two `ContributionPage`s. (*This requires less upfront technical work, but it also requires on-going training. Fine-tuning workflows+reports may be tricky.*)
* __Informal translation (in-line)__: As above, the software remains effectively unchanged. If the user needs more languages, then he just does everything in-situ. Thus, a bilingual newsletter has one "Subject" with two languages (`Subject: Hello world / Bonjour tout le monde`). (*This again requires less upfront technical work, but it's progressively uglier as you add each new language. Fine-tuning workflows+reports may still be tricky.*)
* __Formal translation__: The software is updated to allow translation of different records. Thus, a bilingual newsletter is one `Mailing` with two different `Subject`s. A bilingual fundraising campaign is one `ContributionPage` with two descriptions. (*This requires more upfront technical work, but it allows more tuning of the workflows and reports.*)
There is some documentation about CiviCRM and i18n, eg
* https://docs.civicrm.org/user/en/latest/the-civicrm-community/localising-civicrm/
* https://docs.civicrm.org/dev/en/latest/translation/
# Problem/Goal (General)
In its default/basic mode, CiviCRM supports *single language* (which can also be used for *informal translation*). Additionally, the Civi administrator can enable *formal* multilingual. The formal mode is well suited to some organizations and challenging for others.
The next section will summarize some specific technical issues, and the needs obviously vary case-by-case, but (broadly speaking) I found it helpful to consider two types of multilingual organizations:
* __(Loosely) Bilingual orgs__: For regional organizations supporting 2-3 endemic languages (loosely - "bilingual" orgs), Civi's formal multilingual is "pretty good"; it's often "optimal"; and (even at its worst) it is at least "acceptable".
* __(Loosely) Multinational orgs__: For far-flung organizations supporting 8+ languages (loosely - "multinational" or "global" or "pan-continental"), the design is... less optimal.
# Problems (More specific)
* __MySQL Columns__: For every language, Civi's MySQL schema replicates ~100 DB columns in ~25 tables. (For 8 languages, that would be a total ~800 columns.) This can max-out some hard limits in MySQL.
* __Roles__: For an organization supporting 1-3 endemic languages, there are many staff who speak each of the languages, and (e.g.) it's realistic to say that the event-manager role is *responsible* for translating the event-description. However, with 10+ languages, it is not realistic -- so you may create more specialized roles that don't exist in a unilingual/bilingual organization. For example, one person may set the initial terms of the `ContributionPage`, and 9 other people translate the description. More nuanced roles mean you also need to think about:
* __Workflows__: If your role is "Italian translator", then you don't want to manually fish through all the `Event`s and `ContributionPage`s to see which ones need translation. The workflow should draw attention to the things that need you.
* __Permissions__: If your role is "Italian translator", then you certainly need permission to edit the Italian "Description" of an `Event`... but maybe you shouldn't have permission to change the registration-deadlines, the price-structure, or the Spanish translation.
* __Negotiation/Fallback/Sparsity__: With a larger number of languages, it takes a lot of labor to fill every translatable field on every record in every locale in a timely way. There will be gaps in the translation matrix -- whether purposeful ("it's not worthwhile to translate this one between en_US and en_CA") or incidental ("the translator hasn't gotten to this yet"). With sparser translations, the fallback/language-negotiation becomes more important. (Ex: If `en_US` is missing, then fallback to `en_CA` or or `en_GB`. If `fr_CA` is missing, then fallback to `fr_FR`.)
* __Entities/Fields__: The multilingual translation support is targeted at specific entities+fields. However, the value of formally translating any specific entity or field may be assessed differently. Consider two opposing examples:
* __ContributionPage__: For a regional organization with bilingual constituents, you might commit to formally translating every `ContributionPage`. In a global organization with different countries, you might find that each country has so many differences (language, pricing, taxes, etc) that you prefer to create new `ContributionPage` for each.... so you never use *formal* translation of `ContributionPage`s. (*Or, if we're really exacting, you might have one `ContributionPage` for each country... but within bilingual countries, you'd want different translations of the page!*)
* __MessageTemplate__: For a regional organization with bilingual constituents, you may decide it's preferable to send bilingual notifications (ie send a receipt with both English+French text), so you don't need *formal* translation of `MessageTemplate`s. However, in a global organization, it's crazy to put 10 languages into 1 receipt -- instead, you should formally distinguish the translations for each language.
Considerations
----------------------
For purposes of this issue, I would say that support is "complete" when it is possible (by a mix of extensions/patches) to configure the MySQL schema/roles/workflows/permissions/fallbacks/entities/fields in a way that satisfies (a) a regional/bilingual organization and (b) an multinational/global organization.
However, this still leaves considerable room for interpretation/variation. Ask yourself: is it true that multilingual users fall in two distinct buckets (bilingual vs multinational)? Or are those idealized extremes, with most organizations taking some place in between?
* If it is truly two categories, then you might address this by implementing two separate subsystems:
* The existing "bilingual" subsystem provides permissions/workflows/entities that are suitable for bilingual orgs.
* A new "multinational/global" subsystem provides permissions/workflows/entities for multinational orgs.
* If there are many shades of grey, then you might address this by giving more subtlty to each aspect, eg
* The data-storage layer might use localized columns, or a dedicated string table, or something else. (Perhaps you can swap the data-storage while keeping the rest.)
* Different modules might provide different workflows/UIs - so one module allows editing translations in-situ (per-entity), while another another module provides more centralized translations (per-language). (Perhaps these different workflows/UIs can used separately - or perhaps they can coexist giving alternate access to the same data.)
* The list of localized entities/fields might be configurable.
* The process of configuring l10n/i18n might be softened - instead of a system-level flag (configuring translation for everything), it could be more case-by-case/opportunistic -- where you can optionally "attach" n-ary translations to any given field.https://lab.civicrm.org/community/feature-request/-/issues/25Enriched Deletion2020-03-18T20:08:55ZtottenEnriched Deletion> You might call this a "minority opinion" - I imagine few would take (on first glance) come to the same approach. However, I want to get it on paper because I think it's a deeper solution - and the issue may recur.
# Background / Conte...> You might call this a "minority opinion" - I imagine few would take (on first glance) come to the same approach. However, I want to get it on paper because I think it's a deeper solution - and the issue may recur.
# Background / Context
CiviCRM is a *database application* which tracks *related data*. For example, an `Activity` may be related to a `Case` and three `Contact`s. This creates the question of *referential integrity*. For example, if one of those three `Contact`s is deleted, then the *relation* (aka "foreign key" or "reference") between the `Activity` and the deleted `Contact` becomes nonsensical, and you must do something to make the data sensible again.
CiviCRM builds on top of MySQL, and MySQL provides one mechanism to deal with this: `ON DELETE`. When declaring the schema for `Activity` and `Contact`, you can set a rule to resolve this nonsensical situation by either (a) putting a blank (`null`) value into the reference or (b) deleting the record which has the invalid reference. This process can be thought of as s *cascading* or *propagating*. (Conceptually, the deletion of `Contact` could trigger the deletion of an `Activity` which could trigger the deletion of a custom dataset for that activity).
CiviCRM also builds on top of PHP. It has hooks and events, which leads to another mechanism: by subscribing to some event (e.g. `hook_civicrm_pre`), you can take some action before or after deletion. This mechanism can also provide the *cascading* or *propagating* effect. Compared to MySQL, this empowers a developer to define more nuanced cascading rules.
# Basic Concept
The basic concept of "Enriched Deletion" (*for want of a better name*) can be seen by comparing these two screens. First, we have a normal confirmation dialog that you might show to user before deleting an important record:
![Screen_Shot_2020-03-17_at_8.25.22_PM](/uploads/1b3e288f2cdef33843ed1170d2ec0967/Screen_Shot_2020-03-17_at_8.25.22_PM.png)
With enriched deletion, the user (or *agent*; more about the expanded view in a moment) has visibility and discretion into the consequences of the deletion:
![Screen_Shot_2020-03-17_at_8.25.34_PM](/uploads/630070c9e524b11eb4274e8cbf155a15/Screen_Shot_2020-03-17_at_8.25.34_PM.png)
They have the ability to *see* what data is affected by their action -- and to *decide* what the impact will be.
# Expanded Concept
The *cascade policy* is what you in see the table above -- a list of relations and the rules about how to handle each stale reference (delete the record, set to null, block deletion/raise an error, etc).
The *default cascade policy* is, well, the default. It is determined programmatically. It is mediated via event/hook, and the site administrator can make overrides/customizations.
A screen such as the above is a thin wrapper around an API. All standard API entities would support two actions:
* `delete`: This API performs the deletion. In absence of suitable instruction, it obeys the *default cascade policy*. If the agent has suitable permission (eg `manage rich deletion` -- *for want of a better name*), and if the API call specifies some `cascade` option, then the inputs will take precedence over the defaults.
* `deletePreview` (*for want of a better name*): This API reports about the related entities that would be deleted - and the cascade options that are valid for them. (If the user permission `manage rich deletion`, then all options are valid. If they lack permission, then options are locked-in to the *default cascade policy*.)
# Rationale
Rare is the user who clicks "Delete" while thinking, "Please, I hope the next screen is more complicated!" So why would you add this extra panel to the "Delete" action?
Regardless of this Gitlab filing, *some* cascade policy already exists. It must exist. The question is its form, content, comprehension, maintenance. Who can influence it?
* In the early/original CiviCRM, the cascade policy is specified via `xml/schema/**.xml` (e.g. `xml/schema/Contribute/Contribution.xml` specifies that the `contact_id` relation has a policy of `<onDelete>CASCADE</onDelete>`).
* In CiviCRM with hooks/events, a third-party developer can potentially use `hook_civicrm_pre` to refine the cascade policy. It is not certain if this is actually done or if the interface works well for the purpose, but the basic idea is there.
However, there is no *visibility* into this behavior for a user. Whatever the cascade policy is, there will be elements which feel a bit grey or uncertain. Users will be in the dark about this - they won't even think about the extended implications of a delete until *after* it matters. The existence of extensions heightens the mystery - a user isn't in a position to know what extensions are, and an admin isn't in a position to say how each extension does (or does not) adjust the policy.
CiviCRM is a modular, multi-organization, "customizable/off-the-shelf" system. Consequently, it is difficult to make one set of judgments for grey area things -- especially when there's an open-set of customizations for each site. Even if you do understand the policy, programmatically customizing the policy is an expensive proposition.
The basic concept of "Enriched Deletion" is to formalize the cascade policy in a way that realistically allows+reconciles influence from (a) developers, (b) site admins, and (c) backend users.
# Alternatives
* Hard-code one cascade policy
* Use "on-delete" hooks to allow programmers to customize policies
* Never delete anything - all deletions should be reversible.
* __Comment__: I'm not sure this changes the basic issue about the *sensibility* of the data - for example, suppose a user "deletes" a contact who has a case. Does that case remain visible? Do its activities in reporting about case-activities? Whether the deletion mechanism is hard or soft, there is still some kind of policy/effect on the case and activities ascribed to the contact.
https://lab.civicrm.org/community/feature-request/-/issues/24api feature request for usability: filter out deleted contacts unless is_dele...2020-02-04T21:03:41Zndavisapi feature request for usability: filter out deleted contacts unless is_deleted = 1 in parametersThe title says it all... when pulling a contact by email, I should only get undeleted contacts. This is painful when something works fine on dev then you move it to stage, with a much bigger dataset that includes billions of deleted cont...The title says it all... when pulling a contact by email, I should only get undeleted contacts. This is painful when something works fine on dev then you move it to stage, with a much bigger dataset that includes billions of deleted contacts, and everything breaks.
"where is_deleted=0" should be a part of all api calls unless you specifically indicate that you want deleted stuff.
```
$result = civicrm_api3('Email', 'get', [
'sequential' => 1,
'email' => "someuser@somedomain.org",
'api.Contact.get' => [],
]);
```
returns all contacts with that email attached. By default it should only include contacts that aren't deleted.
Just a suggestion! No one is interested in deleted contacts unless they're removing them permanently or undeleting them.https://lab.civicrm.org/community/feature-request/-/issues/23Proposal: Simplified alternate logging setup using MariaDB Temporal tables2019-11-20T00:20:25ZlolcodeProposal: Simplified alternate logging setup using MariaDB Temporal tablesWe are experimenting with [MariaDB temporal tables](https://mariadb.com/kb/en/library/temporal-data-tables/) for time stamped data extraction jobs. They make detecting record level updates easy and pass that off to the DB engine.
I woul...We are experimenting with [MariaDB temporal tables](https://mariadb.com/kb/en/library/temporal-data-tables/) for time stamped data extraction jobs. They make detecting record level updates easy and pass that off to the DB engine.
I would like to propose an alternate method of CiviCRM logging that just enables the MariaDB standard temporal columns and SYSTEM VERSIONING. This logging option would be available if the DB is on MariaDB 10.3 or later. This would remove the need for the triggers.
This should start out as an extension.
Core changes needed to get feature parity with the current method: The "last updated by" column would move from the log_civicrm_xxx schema into the main table (currently is log_user_id).https://lab.civicrm.org/community/feature-request/-/issues/22Create in-app tabbed dashboard2020-07-27T16:49:41Zjoshjosh@civicrm.orgCreate in-app tabbed dashboardThis is a proposal to maintain the current user configurable dashboard, but to add in:
1. a community dashboard that pulls relevant content from various sources and whose objective is to better organize content (examples https://lab.civ...This is a proposal to maintain the current user configurable dashboard, but to add in:
1. a community dashboard that pulls relevant content from various sources and whose objective is to better organize content (examples https://lab.civicrm.org/marketing/civicrm-website/issues/159 and https://lab.civicrm.org/community/feature-request/issues/21) and increase community engagement.
2. a changelog that feeds in issues from Gitlab, thereby replacing the release notes and potentially offering an easier way in-app to [file a bug report or request a feature](https://lab.civicrm.org/dev/core/issues/1356)
![community-dashboard-v2](/uploads/8c0d451e98aa0c0cd5d34aa1a1936e67/community-dashboard-v2.png)https://lab.civicrm.org/community/feature-request/-/issues/21Allow in-app messages from extension authors2023-07-22T17:44:19ZbgmAllow in-app messages from extension authorsProposal discussed at CiviCamp Brussels, for consideration by the Ext WG and Core Team:
Context: Extensions do not have a way to communicate with their users. This may be to communicate:
* that the extension is being deprecated (possibl...Proposal discussed at CiviCamp Brussels, for consideration by the Ext WG and Core Team:
Context: Extensions do not have a way to communicate with their users. This may be to communicate:
* that the extension is being deprecated (possibly in favour of another one),
* fundraising request,
* promote trainings/workshops, or other services.
Implementation:
* Partner benefit (as a way to validate that the extension author's message is compatible with CiviCRM values/branding/community).
* Currently in-app messages are fed from a google-doc. In the short term, we could open up write permissions to the google-doc to a few people/partners, who could handle the requests. The requests could be done on Mattermost or Gitlab (transparency).
* In-app messages for extensions, for now, would only be shown to administrators (in-app messages currently have options to show that message only to admins, all users, etc)
* and of course, an in-app message would only be shown if the extension is enabled.
Technically, this requires small changes to civicrm core, as well as the in-app messaging app. As the community grows, eventually, we may want to have a forms for this on civicrm.org, but that's more work, which we can address when it becomes necessary.
cc @xavier @totten @ginkgofjg @AllenShaw @josh
--
NOTE: There is another filing on this topic which also has a nice write-up: https://lab.civicrm.org/extensions/extensions-directory/issues/10 . However, there's more discussion recorded under this variant of the issue, so let's continue using this one.https://lab.civicrm.org/community/feature-request/-/issues/20Include a Payment Processor filter on the appropriate built in Reports2019-09-03T15:42:24ZhowardshandInclude a Payment Processor filter on the appropriate built in ReportsFor most persons the default contribution reports are satisfactory but don't allow you to identify income by payment processor.
See:
https://civicrm.stackexchange.com/questions/27695/report-with-payment-processor
https://civicrm.stackex...For most persons the default contribution reports are satisfactory but don't allow you to identify income by payment processor.
See:
https://civicrm.stackexchange.com/questions/27695/report-with-payment-processor
https://civicrm.stackexchange.com/questions/21990/can-we-report-on-contributions-by-payment-processor
One possible solution is to install Extended Reports but for those who prefer not to have any extensions running this can be restrictive.https://lab.civicrm.org/community/feature-request/-/issues/19General convergence in the searching space (needs:planning)2019-07-19T02:28:43ZtottenGeneral convergence in the searching space (needs:planning)There are multiple frameworks dealing with the search space:
* `Contact Query BAO` / `Advanced Search` / `Search Builder`
* Note: `Profile` is used as a storage model for the selection of fields from `Contact BAO Query`
* Note: ...There are multiple frameworks dealing with the search space:
* `Contact Query BAO` / `Advanced Search` / `Search Builder`
* Note: `Profile` is used as a storage model for the selection of fields from `Contact BAO Query`
* Note: `Smart Groups` use a `Contact Query BAO` criteria as a storage model for the search
* `Custom Search`
* Note: `Custom Search` extends the frontend/controller system from `Advanced Search` but it completely replaces the underlying search-mechanism. This gives access to some functionality (like `Smart Groups`) but not other (like customizing columns via `Profile`).
* Other `QuickForm`/`Selector` Searches (`Find Activities`; `Find Contributions`)
* `Export`
* Note: `Import/Export Mapping`s are used as a storage model for the selection of fields from `Export`. These are similar to `Profile`, except they include support for traversing relations.
* `CiviReport`
* `APIv3`/ `APIv4` / `API Explorer`
* `SQL Tasks`
To some extent, there are distinctive features in each of these areas. However, I find it questionable that these distinctive features are enough to merit the separate subsystems. Example:
* The traditional `Export` subsystem is built on the `Query BAO` and other QuickForm `Selectors`. But it's not used for reports.
* The report subsystem doesn't integrate the standard contact tasks. Arguably, this is because many reports deal with different record-types. However, one could reasonably expose search tasks in a reported -- provided you match on the *type* of the record in each row.
* One can figure out how to run a quirky search using either CiviReport or the API. But if one wants to use that same search to define a smart-group, it wouldn't work.
* If you're reading the `civicrm_saved_search` behind a `Smart Group`, it's difficult to find documentation/explanations for the semantics of those fields.
* There are code-generators for some things (like `API` entities and `API` actions and `Report`s) but not others (like `Search Tasks`)
A couple example opinions:
* I like `APIvX.get` as a layer for defining query-backend. The main gap in using it as the backend for *all* the above subsystems is the lack of aggregate/group functionality.
* A search-task is basically an `APIvX` action plus (1) a bespoke form for tweaking the inputs of the action and (2) a declaration/registration of when to display the search-task.
It's not clear that a total convergence is sensible, and this one Gitlab issue shouldn't be responsible for every detail, but it makes sense to have some space to record general/broad discussion about the convergence of these subsystems.https://lab.civicrm.org/community/feature-request/-/issues/18Role/permission mechanism for E2E/integration testing2022-04-07T23:12:15ZtottenRole/permission mechanism for E2E/integration testing## Example Use Case
Suppose you're writing an automated test which hits the end-point `civicrm/mailing/view?id=XYZ`. The behavior of this end-point depends on several variables -- such as the value of `civicrm_mailing.visibility`, wheth...## Example Use Case
Suppose you're writing an automated test which hits the end-point `civicrm/mailing/view?id=XYZ`. The behavior of this end-point depends on several variables -- such as the value of `civicrm_mailing.visibility`, whether the permission `view public CiviMail content` is active, the content of any IDs or hash-codes in the URL, and the identity of the user in the current CMS. Good test-coverage would exercise several of those permutations (by manipulating or mocking the variables involved).
Specifically, this issue is about manipulating/mocking the active permissions (`view public CiviMail content`, et al) for use in a multi-process test.
## Existing/Related Options
* For CiviCRM's `WebTest` suite, there was a long-time dependency on `civicrm_webtest.module`, which defined a role and a bunch of permissions. However, it defined exactly one role with a static list of permissions, which isn't useful for testing multiple variations -- and the implementation only worked on D7.
* It is possible to mock permissions with one of the following: `CRM_Core_Config::singleton()->userPermissionClass->permissions`, `CRM_Core_Config::singleton()->userPermissionTemp`, `hook_civicrm_permission_check`. However, these only applies to the current process - if you make an HTTP request to test an end-point, the mocking disappears.
* Each CMS has a model and an API for manipulating users/roles/permissions. The models appear similar from a 30k ft view, but they're different in a low-level view.
* The ACL system provides a fine-grained access control matrix (e.g. access to view or edit a specific list of contacts), but it doesn't provide coarse grained permissions.
## Options
* __The Stateful Concrete Option__: Define a small data-store (SQL table or setting). Expose an API for granting permissions to specific contacts. In writing a test, one might say:
```php
civicrm_api4('Contact', 'grant',[
'where' => [['id', '=', 123]],
'permissions' => ['view public CiviMail content'],
]);
```
* __The Stateless Concrete Option:__ Define a cookie or HTTP header which can be used to temporarily grant permissions. Require a signed+timestamped token. In writing a test, one might say:
```php
$jar = \GuzzleHttp\Cookie\CookieJar::fromArray([
'CIVI_PERM' => createSignedToken(['view public CiviMail content']),
], 'localhost');
$client = new \GuzzleHttp\Client(['cookies' => $jar, ...]);
```
* __The Abstract Option__: Create an abstraction which wraps around the user/role/group/permission. Implement it on every CMS.
## Considerations (General)
* It's possible to build such a system on top of existing APIs (eg `hook_civicrm_permission_check`). The functionality could be coded as an extension. However, one does need to consider the dependency-graph/distribution-mechanics. Does it make sense for a core test to depend on an external extension?
* To avoid confusion with the normal CMS-based permissioning and to prevent its use as an escalation vector:
* The mechanism should have a toggle and be disabled by default.
* Enabling it should require some kind of super-admin or sysadmin right. (Enabling this feature would have the same
## Considerations (Stateful Option)
* To be useful for testing:
* Should allow granting permissions specifically to an example contact.
* Should allow granting permissions generally to anonymous and any/all contacts.
* The following elements are *not* needed for general testing/mocking purposes. I don't have any strong objection to their existing -- they're just different/out-of-scope for my issue here.
* Providing a GUI for CRUD'ing the permissions
* Granting permissions to static-groups
* Granting permissions to smart-groups
## Considerations (Abstract Option)
* An abstract service has a larger footprint (i.e. needs to be written/tested/maintained in multiple environments, each of which are subject to change).
* CMS's generally assign permissions on per-role/per-group basis. This makes sense, but it's unnecessary indirection if your goal is to write an automated test. (*It is easier to (a) mock contact + permission than (b) mock contact + role + role/contact-assignment + role/contact-permission.*)https://lab.civicrm.org/community/feature-request/-/issues/17Better organize price set display2019-03-17T10:29:50Zjoshjosh@civicrm.orgBetter organize price set displayFor organizations using a large number of price sets the price set admin screen can be quite long and tedious to use. It essentially presents a list of active or inactive price sets, but does not allow for any filtering such as "hide dis...For organizations using a large number of price sets the price set admin screen can be quite long and tedious to use. It essentially presents a list of active or inactive price sets, but does not allow for any filtering such as "hide disabled". Ideally it would present as few price sets as possible and allow for searching for inactive ones.https://lab.civicrm.org/community/feature-request/-/issues/16Display mosaico and 'traditional' mail links on in navigation menu edit screen2019-03-04T10:28:45Zjoshjosh@civicrm.orgDisplay mosaico and 'traditional' mail links on in navigation menu edit screenUsers that have Mosaico installed have 2 new menu items in the mailing dropdown: Mosaico Templates (a/#/mosaico-template) and New Mailing (traditional) (a/#/mailing/new/traditional). Neither of these menu items appear when editing the na...Users that have Mosaico installed have 2 new menu items in the mailing dropdown: Mosaico Templates (a/#/mosaico-template) and New Mailing (traditional) (a/#/mailing/new/traditional). Neither of these menu items appear when editing the navigation menu, which prohibits users from rearranging the dropdown items.
![Navigation Menu Screenshot](/uploads/0aff974737a69396acbc8d341707e271/mailing-menu-items.jpg)https://lab.civicrm.org/community/feature-request/-/issues/15Find Activities should not pre-select an activity role2018-12-07T01:22:02ZbgmFind Activities should not pre-select an activity roleThis has been a long time annoyance for me:
* Go to 'Search > Find Activities'
* Click Search
You'll get a certain number of results. On dmaster.demo, this gives 242 activities.
However, go back to the filters and unselect 'With', and...This has been a long time annoyance for me:
* Go to 'Search > Find Activities'
* Click Search
You'll get a certain number of results. On dmaster.demo, this gives 242 activities.
However, go back to the filters and unselect 'With', and you will get 574 results.
![Capture_d_écran_de_2018-12-05_11-43-16](/uploads/61455f8cc7b04d28363127cc3bb96260/Capture_d_écran_de_2018-12-05_11-43-16.png)
This seems to have been quietly introduced as part of:
https://lab.civicrm.org/dev/core/commit/18d2d5e26c57c4667fffb40757adca5322ca4e3c
(or could have been an adaptation of the previous behaviour, but in any case, this has been there for over 5 years)https://lab.civicrm.org/community/feature-request/-/issues/14context specific WYSIWYG choice, extension?2018-12-02T04:06:02ZStoobcontext specific WYSIWYG choice, extension?civicrm/admin/setting/preferences/display allows us to select wysiwyg. The choice is global. Is there a setting or **extension** that allows us to make *different* choices depending on Civi context, i.e. within CiviMail, while editing ...civicrm/admin/setting/preferences/display allows us to select wysiwyg. The choice is global. Is there a setting or **extension** that allows us to make *different* choices depending on Civi context, i.e. within CiviMail, while editing a Note, while editing Activity Details, etc?
I know this is in violation of the rule to post on Stack Exchange first, but it is not core support, it's a desire for an extension? @AllenShaw interested?https://lab.civicrm.org/community/feature-request/-/issues/13Change project description to include link to Product Roadmap chat channel2018-11-29T16:47:45ZJoeMurrayChange project description to include link to Product Roadmap chat channelWe should try to connect this space with the chat Product Roadmap channel.We should try to connect this space with the chat Product Roadmap channel.https://lab.civicrm.org/community/feature-request/-/issues/12Civi::log()->debug() should only log if debugging is enabled2021-04-28T20:39:05ZbgmCivi::log()->debug() should only log if debugging is enabledCurrently, `Civi::log()->debug()` always logs to the `ConfigAndLog` (text log files), no matter what the `debug_enabled` setting is set to.
I would like to be able to leave some debug statements in my extension, so that it is easier to ...Currently, `Civi::log()->debug()` always logs to the `ConfigAndLog` (text log files), no matter what the `debug_enabled` setting is set to.
I would like to be able to leave some debug statements in my extension, so that it is easier to get more information about what happened, without running a debugger or temporarily inserting debug statements.
Grepping in core, only `CRM/Core/Payment/PayPalIPN.php` and `CRM/Core/Payment/PayPalProIPN.php` seem to be using `Civi::log()->debug()` and it seems indeed like debug info.https://lab.civicrm.org/community/feature-request/-/issues/11redirect to manage case screen after creating a case2018-10-20T15:47:53Zlcdwebredirect to manage case screen after creating a caseCurrently if you create a case from within a contact record, it redirects back to the contact's case tab, rather than directly into the manage case screen. I suspect in most uses cases the user would expect to be directed into the newly ...Currently if you create a case from within a contact record, it redirects back to the contact's case tab, rather than directly into the manage case screen. I suspect in most uses cases the user would expect to be directed into the newly created case.
Note: redirection into the manage case screen was the behavior in v4.4. It was changed somewhere between that version and v4.6 (it's not clear if it was intentional).https://lab.civicrm.org/community/feature-request/-/issues/10Improving quality of participation in the "Feature Request Project2018-10-15T15:00:47Zginkgomzdginkgomzd@fastmail.comImproving quality of participation in the "Feature Request ProjectI was looking everywhere for a "Comment" button...
For thousands of years, many cultures across the globe have believed that "in the beginning, was the WORD". Names matter.
I think "Requests" is the wrong framing for this project. From ...I was looking everywhere for a "Comment" button...
For thousands of years, many cultures across the globe have believed that "in the beginning, was the WORD". Names matter.
I think "Requests" is the wrong framing for this project. From the guidelines, it seems that this is intended more for discussion, brainstorming, and fleshing-out new work on CiviCRM.
Feature Specifications? Feature Brainstorms?
I think there is an implicit bias and barrier to entry for participation in this project. It gives privilege to professionals skilled in requirements gathering AND/OR people with lots of time on their hands to wrangle community participation. Do we not want ideas to be promoted on merit, not only on the resources of the backers? Honest question. If we just want to facilitate those with resources... then I guess that's what we'll do.
I think there could be a lot of benefit to having a place to attract casual "requests". A good old suggestions box. In a past life, I was taught to treasure all customer feedback because for every complaint or compliment, there were 10 other customers who think the same and won't take the time to give you the feedback. If we create a place to catch that casual feedback, we could avoid having chaos in the space for delving deep into scoping of projects.https://lab.civicrm.org/community/feature-request/-/issues/9Improve core search usability related to commas, space2019-07-21T17:06:29ZStoobImprove core search usability related to commas, spacehttps://civicrm.stackexchange.com/questions/26747/feature-request-make-search-more-forgiving-and-spaces-after-comma-and-non-primahttps://civicrm.stackexchange.com/questions/26747/feature-request-make-search-more-forgiving-and-spaces-after-comma-and-non-prima