We had one site that had 'lost' all it angular pages, eg CiviMail and System Status.
In our case the angular cache files were returning 404 on the New Mailing page. (and 'inspector' was showing a lot of red angular errors)
It was building the cache files in sites/default/files/civicrm/images, but then searching for them in sites/default/files/civicrm/...
We got this on one of the db upgrades. For us, it was due to few entries in civicrm_relationship table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.
Take a separate back up for civicrm_relationship table.
Check invalid entries using -
I am the maintainer of the statistics for CiviCRM. There are between 10,000 and 11,000 organizations actively using CiviCRM at the moment. We suffered a hardware failure on the stats server hence the little fluctuation. The statistics will soon be back to normal. More information at https://stats.civicrm.org. Thanks.
I was able to solve this, at least for now, on my WordPress 4.8/Civi 4.7.22 site using this suggestion from Tim Otten:
another work-around should be going to "Administer => System Settings => Debugging" and disabling the "Asset Cache"
Of course in the long term we'd like to take advantage of the Asset Cache. But for now at least we have our angular-based ...
CiviCRM has a "trash" feature which flags contact records as trash without actually deleting them. Contacts with the flag set to 1 are excluded from most reports, etc.
Their contributions, etc., will not be deleted but may be hidden from reports and interfaces as well. That may or may not be what you want. If you wish to see all the contributions, I don't ...
There is a helpful explanation. The numbering system changed, this is detailed here
5.0.0 is the next version after 4.7.31 and is not a major update.
In The Q&A section there is an answer to this question which explains why the limitations of the update messaging system in 4.7 led to the decision to use the End of Life message in this instance:
Here is what we usually do :
either let people change their information by logging in the system, either after sending an email with a checksum link to let them update their own information. You can use a webform but in that case, you don't have to worry about the matching rule (i.e. you match with the user logged in or the checksum)
for anonymous form, i ...
You could create a custom field for all contacts called "Status" with options of Active and Archived. That will give you the selection you need in most places to easily include / exclude the appropriate contacts, especially on many reports and Advanced Searches. Then create two smart groups - Active and Archived - which include the appropriate contacts, and ...
In general, a field can be made into select2 simply by adding the css class "crm-select2" to it.
Here is a PR to add it to the existing location field you mentioned. Please try it out and leave a comment on the PR to say you've tested it and how it works for you - that will speed along the review process and we'll be able to get that merged into the next ...
I have an extension called Constituents Only that provides this functionality. It repurposes the "Do Not Trade" checkbox as an "Exclude from Search" checkbox. Non-searchable contacts are primarily accessible via the relationships tab to other contacts.
I have a version 2.0 (which I haven't found time to make public yet) that will return the related ...
I believe you can create a modified version of the default contact page templates as described here.
Excerpt from that page:
These steps are for any "built-in" screen (e.g. the Contact Summary
Navigate to the screen you want to customize and use your browser to View Source.
Search for ".tpl" in the source. You will find a comment ...
There is an open issue related to your question https://issues.civicrm.org/jira/browse/CRM-20894. It also happens to me with a recent upgraded CiviCRM from 4.8 to 4.7.22 and it can also be replicated in dmaster.
Seems it's already solved here https://issues.civicrm.org/jira/browse/CRM-20773
The Contact API is non-standard in APIv3; a major goal of APIv4 is to remove these quirks. The behavior you're seeing on Display Name is non-standard. It also seems that a lot of the other operators (e.g. "LIKE") don't work on Display Name.
If you can, you can search on First Name and/or Last Name, neither of which display the problem described here.
You can find the tpl file which is used to build the html by viewing page source.
Go to Administer menu > System Settings > Debugging and Error Handling, select Yes for Enable Debugging.
Visit the page/form you want to check which tpl file is invoked.
Right click >> View Page Source.
Ctrl + F to find tpl
Please check that you the base page here: https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm/admin/setting/uf&reset=1
The value here
Should be an existing published WP Page.
I would then revisit the permalinks page.
That should 'fix' it.
The code quality of core is generally higher then that of the extensions. So if you can help funding it, it might improve your chances.
On the other hand, discussions lately are going in the direction to move more functionality from core to extensions then the other way around, although exceptions likely will occur.
There's not a generic extension to handle this. What you're asking for is very similar to Computed Field for Drupal - but the nature of calculated fields is that you're writing code (or some pseudo-code formula). At that point, it's not much further to writing the code in an extension.
There are three approaches you can take:
You can write an extension ...
Paul, very interested in this idea as well. Don't have a great answer, but here's an idea - since you're on Drupal, I wonder if this would work - using Views, Views Calc and Views Aggregator Plus (perhaps along with webform-civicrm) to do the calculation - add the survey answers to get a score - then saving that score back into Civi in a custom field?
When you create a User the user email, civicrm email and uf_match table are all the same.
If you then edit the civicrm email, the uf_match gets updated as does the User email.
If you edit the user email, the uf_match is updated, as is the civicrm email.
BUT I don't think this has always been the case. I can't track when the new feature came in to 4.6.x ...
I had a similar issue on an installation with PHPOffice.
PHPOffice is automatically installed via composer in CiviCRM, but apparently composer fails to check for needed PHP extensions. In my case php-zip was missing, and after installing that everything went fine.
I am not sure if composer should check the requirements, or if they aren't properly ...