The two directories are found side-by-side. The location varies by CMS; see below. Note that you'll need access to your server's file system. If you have FTP/SFTP/SSH access, you can use that. If you have a control panel, check for a "File Manager" plugin:
Aside from the general arguments against Salesforce, which are well-detailed elsewhere - it's designed for business-to-business interactions. That results in odd architectural decisions. For instance, all individuals must have an organization they're tied to. That often doesn't make sense in the non-profit world, with individual donors, social services ...
My experience with Salesforce in particular with website integration is that it falls short and depends too much on 3rd parties to provide the conduit between the website and the Salesforce account.
I've been working with an organization who decided to go big with Salesforce and all the associated costs "because it is established and familiar" -- however ...
You can switch on the advanced logging in the Administer/System Settings/Misc, that will show you far more detailed logging. I expect it will impact your performance, so it is probably worthwhile to test it first.
The main use of those logs files is to help diagnose problems in CiviCRM. You're unlikely to want to review problems from a few years ago so you can delete them. The one without the datestamp is the current one and that should have the most recent timestamp.
However 9GB is a lot of log output! It would be worth looking at the recent ones to see if there ...
Fortunately, in CiviCRM 4.7 (and Civi 4.6.17+), installing ANY extension will recreate your missing logging tables. Not that enabling an extension isn't sufficient - you must install an extension. See CRM-15078
The reason this works: If advanced logging is enabled, extensions without a corresponding logging table will generate errors. Because an ...
I think you can safely trim the civicrm_job_log, only the latest entries are probably useful (and given how little information the cronjobs return, I'd even doubt that ;)
As for the civicrm_log (or subscription history), it might be more risky to remove as you will loose "useful" history of what happened with your contacts, but from a technical point of ...
I have discovered that the delete-this files are temporary files created by CiviCRM for the sole purpose of generating this error! This error is good, it means that these directories are not browseable, and they shouldn't be browseable.
CiviCRM's CRM_Utils_Check_Security class does these checks in order to report what would-be security errors.
It creates a ...
I finally succeeded to find the solution!
It was the VirtualHost's include_path the problem! In fact it seems that CiviCRM's install script needs to add paths in it, and if it is already set, it cannot be modified with the PHP's native function set_include_path(void).
So, I only had to comment the VirtualHost's include_path, and it worked!
My VirtualHost ...
A few orgs who use logging on fairly high volume sites have modified the logging tables to either use MyISAM or InnoDB and have had fairly good success with it. Can you please report back if you adopt this approach and your success with it
There is actually an organization who specializes in non-biased comparisons of software for nonprofits. Check out Idealware. Specifically, grab their latest report on donor management systems.
It has Civi, SalesForce's nonprofit offering, Blackbaud, DonorPerfect, and the other major players.
I think this would be a relatively simple fix. I'd suggest you file an issue for this and, ideally, provide a patch...
...actually in fiddling around with this I just wrote a patch that fixes it. Try this:
#6283 Don't force-refresh the changelog tab to avoid performance overhead
Most people who have this issue are on CiviCRM 5.3-5.6, and is caused by the "missing logging tables" check assuming that temp tables should have a logging table. There is a fix available on Github, and it's part of CiviCRM 5.7+.
Since it's coming from include_once I suspect you have two civicrm.settings.php files.
The correct location is sites/<default or example.org>/civicrm.settings.php
If there's a file in sites/civicrm.settings.php, rename or remove it and see if that ends the errors.
EDIT: OK, having reformatted your question I can see the file path isn't actually ...
It appears that the error simply is reporting that someone is trying to access a CiviCRM page and they do not have sufficient permission to access it.
This is either due to an authorized person trying to access the page, but not having sufficient permission set, or to some unauthorized person (robot?) attempting to access the page.
I would probably try to ...
It looks like civicrm is trying to record the change as being done with a different id than the contact that is trying to register (381 vs 374)
Are you sure you are properly anonymous? it might be that your site still think you are "someone else" (eg. the contact you deleted?).
Could you try creating a new account from a "clean" computer, or if you can't, ...
Is there any chance that Person 1 may have used a PayPal account or credit card belonging to Person 2? We'll frequently see payments that have different names: if I pay with your card, from PayPal's perspective, you've made the payment even though I've entered my name as the contact in CiviCRM.
I had the same problem - we run four different civi instances.
Two had detailed change logs, two did not.
Across all instances users had same privileges and all four instances had logging enabled. The difference other than civi versions was that two had change log report. So the change log tab runs off reports. Steps to fix:
1) check logging enabled in ...
See Access denied errors by server itself on uploaded files, which you refer to in your question. The answer there applies to the ConfigAndLog file too. Civi periodically runs tests to make sure that certain directories and files are not accessible via the web. These include:
the current debug log file (ConfigAndLog.xxxxxxxxxxxxxxxxxxxxxxxx.log)
the image ...
The Administer Screen Settings - Outbound Mail gives you the option to enable Redirect to Database. (You can navigate to the screen with Administer -> System Settings -> Outbound Email (SMTP/SendMail), or with civicrm/admin/setting/smtp?reset=1)The mail is spooled to the table civicrm_mailing_spool.
Update: In case of the use of cc: and bcc: it is a bit ...
The subscription history is shown in the Group tab of the Contact summary in as much as you can see Groups people 'were' in.
The the civicrm_group_contact table stores that people are 'removed' from the group, but the date that it happened is pulled from civicrm_subscription_history (as part of this function: \CRM_Contact_BAO_GroupContact::getContactGroup).
Here is summary of our situation after ours reappeared.
This was actually a wrong message shown on the status page. The logging is disabled on /civicrm/admin/setting/misc?reset=1.
The flow which can lead to this error is -
Logging is enabled on the site which generates a list of log tables in the database.
User now disables the logging functionality on ...
Your message says this several times:
[nativecode=1114 ** The table 'civicrm_temp_civireport_logsummary' is full]
Funny thing, while the Date column is filled out with a value in CiviCRM 4.6, it is empty in CiviCRM 4.7. I have checked on my customer's instances and the run_time column is in fact present but empty on 4.7. I will file a JIRA issue on this topic.
If your main concern is cleaning-up this table, you can easily do this by only keeping the last 1,000 or so ...