service/crm.md

@@ -52,11 +52,11 @@ in yellow and errors (bounces) in red.
 
 A few commands to inspect the email queue:
 
- * list the queue, with more recent entries first
+ * List the queue, with more recent entries first
 
         postqueue -j | jq -C .recipients[] | tac
 
- * find how many emails in the queue, per domain:
+ * Find how many emails in the queue, per domain:
  
         postqueue -j | jq -r .recipients[].address | sed 's/.*@//' | sort | uniq -c | sort -n
 
@@ -114,15 +114,15 @@ to find the victim's email:
 
 Once you have the email address:
 
- 1. head for the [CiviCRM search interface](https://crm.torproject.org/civicrm/contact/search?reset=1) to find that user
- 2. remove the from the "Tor News" group, in the `Group` tab
+ 1. Head for the [CiviCRM search interface](https://crm.torproject.org/civicrm/contact/search?reset=1) to find that user
+ 2. Remove the from the "Tor News" group, in the `Group` tab
 
 Another option is to go in Donor record > Edit communication
 preferences > check do not email.
 
 Alternatively, you can just send an email to the `List-Unsubscribe`
 address or click the "unsubscribe" links at the bottom of the email.
-The [handle-abuse.py](https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/HEAD/handle-abuse.py) script in `fabric-tasks.git` automatically
+The [`handle-abuse.py`](https://gitlab.torproject.org/tpo/tpa/fabric-tasks/-/blob/HEAD/handle-abuse.py) script in `fabric-tasks.git` automatically
 handles the CiviCRM bounces that way. Support for other bounces should
 be added there as we can.
 
@@ -130,7 +130,7 @@ Special cases should be reported to the CiviCRM admin by forwarding
 the email to the `Giving` queue in [RT](howto/rt).
 
 Sometimes complaints come in about Mailman lists. Those are harder to
-handle because they do not have individual bounce adresess... 
+handle because they do not have individual bounce addresses...
 
 ## Granting access to the CiviCRM backend
 
@@ -227,7 +227,7 @@ about the error:
 To debug this, first find the "Scheduled Job Logs":
 
  1. Go to Administer > System Settings > Scheduled Jobs
- 2. Find "Torcrm Resque Processing"
+ 2. Find "TorCRM Resque Processing"
  3. Click "view log"
 
 Here's a screenshot of such a log:
@@ -301,7 +301,7 @@ stack.
 
 The Puppet classes used on the CiviCRM server is
 `roles::civicrm_int_2018`. That naming convention reflects the fact
-that, before [donate-neo][], there used to be another roled named
+that, before [donate-neo][], there used to be another role named
 `roles::civicrm_ext_2018` for the frontend, retired in
 [tpo/tpa/team#41511](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41511).
 
@@ -383,7 +383,7 @@ Apache answers to the following virtual hosts:
  * `staging.crm.torproject.org`: staging site
  * `test.crm.torproject.org`: testing site
 
-The monthly newsletter is configured on CiviCRM and also archived on
+The monthly newsletter is configured on CiviCRM and archived on
 the <https://newsletter.torproject.org> static site.
 
 ## Storage
@@ -449,7 +449,7 @@ Upstream also has their own [GitLab instance](https://lab.civicrm.org/).
 
 CiviCRM has a `torcrm` extension under
 `sites/all/civicrm_extensions/torcrm` which includes most of the CiviCRM
-customizations, including the Resque Processor job. It replaces the
+customization, including the Resque Processor job. It replaces the
 old `tor_donate` Drupal module, which is being phased out.
 
 ## Related services
@@ -551,12 +551,12 @@ civicrm_torcrm_resque_processor_status_up 1
 ```
 
 Those show the last timestamp of various jobs, the status of those
-jobs (`1` means ok), and whether the "kill switch" has been raised
-(`1` means ok, that is: not raised).
+jobs (`1` means OK), and whether the "kill switch" has been raised
+(`1` means OK, that is: not raised).
 
 Authentication to the CiviCRM server was particularly problematic:
 there's an open issue to convert the HTTP-layer authentication system
-to basic auth ([tpo/web/civicrm#147](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/147)).
+to basic authentication ([tpo/web/civicrm#147](https://gitlab.torproject.org/tpo/web/civicrm/-/issues/147)).
 
 We're hoping to get more metrics from CiviCRM, like detailed status of
 job failures, mailing run times and other statistics, see
@@ -573,7 +573,7 @@ Note that the donate front-end also exports its own metrics, see the
 
 TODO: what to test on major CiviCRM upgrades, specifically in CiviCRM?
 
-There's a [test procedure in donate.torproject.org](service/donate#tests) that should
+There's a [test procedure in `donate.torproject.org`](service/donate#tests) that should
 likely be followed when there are significant changes performed on
 CiviCRM.
 
@@ -602,8 +602,8 @@ documentation](#mysql-backup-system).
 
 Upstream has a [documentation portal](https://docs.civicrm.org/) where our users will find:
 
- - [user guide](https://docs.civicrm.org/user/en/latest)
- - [sysadmin guide](https://docs.civicrm.org/sysadmin/en/latest/)
+ - [User guide](https://docs.civicrm.org/user/en/latest)
+ - [Sysadmin guide](https://docs.civicrm.org/sysadmin/en/latest/)
 
 # Discussion
 
@@ -631,7 +631,7 @@ TODO:
 CiviCRM's deployment has simplified a bit since the launch of the new
 [donate-neo](service/donate) frontend. We inherited a few of the complexities of
 the original design, in particular the fragility of the coupling
-between frontend and backend through the Redis / ipsec tunnel.
+between frontend and backend through the Redis / IPsec tunnel.
 
 We also inherited the "two single points of failure" design from the
 original implementation, and actually made that worse by removing the
@@ -655,7 +655,7 @@ separation between the CiviCRM backend and the middleware API evolved
 from an initial strict, two-server setup, into the current three-parts
 component after the static site frontend was added around 2020. The
 original two-server separation was performed out of a concern for
-security: we were worried about exposing CiviCRM to the public,
+security. We were worried about exposing CiviCRM to the public,
 because we felt the attack surface of both Drupal and CiviCRM was too
 wide to be reasonably defended against a determined attacker.