Might be easiest to update the database is_default field. Works for me on a 4.6 site:
update civicrm_option_value set is_default=0 where option_group_id=26 and name='Scheduled';
update civicrm_option_value set is_default=1 where option_group_id=26 and name='Completed';
You may need to change the 26 but it's a stock option group. To confirm first can do:
So after plenty of back and forth, the issue seems to be the fact I am specifying a Source folder in my IMAP account.
When I created a brand new account for testing, found same issue with a folder named CRM. Tried crm in case there was case sensitivity, still the same.
Only when I removed source and let it read from the Inbox directory did it work ...
You can use the buildForm hook on an activity to check if the activity belongs to a case (in which case case_id will not be empty I think) and then set the default status to Completed.
There is an example here, although it sets different statuses for different types it basically does the same thing. Copy and change I would say :-): https://github.com/PUMNL/...
Not sure if it's the same problem but it could be the submitOnce problem which has a temporary fix in 5.14.1 and a fuller fix pending but is an easy change you can make:
i.e. remove the "submitOnce" line.
Is this your production or test environment?
You could try to switch off logging, save and remove the logging tables, try to delete your contribution and see if it now works. At the end switch logging back on.....
Not sure if this is the root but potentially worth a try. (The already exists might be pointing at an entry in the log table?)
When I tried in the demo site, I did an Advanced Search->Display Results as Activities and filter by the field you want and search.
If you export the result and check either Export primary fields or Select fields for export, in the csv created will be the contact and activity information. You will see Activities in the lasts columns.
If you tried that and ...
Disabling the activity is what you want. That removes an activity as a live option moving forward, but maintains the historical data.
Deleting the activity removes it as an option and erases the historical data.
The creation date of an activity is not, by default, stored in CiviCRM. Depending on what you want to do, you can:
Create a custom field like you suggested, and write an extension that fills in the value on creation.
Create a custom field, then define a MySQL trigger to fill in the date. This is less portable, but higher-performance.
You can enable binary ...
You could use the CiviRules extension (https://civicrm.org/extensions/civirules) for this. Every time an incoming email activity is created in CiviCRM civirules could create a follow up activity in the future.
You need to configure CiviRules in such a way that the trigger is "activity is added", and that you have a condition on the incoming email activity ...
Use search builder to search for all contacts with the activity field: activity date of "not null" and add them to new group "has activities". Use the include/exclude custom search to find any contact not in the "has activities group and add them to a new group "no activities".
You might be interested in this:
CiviCRM: Hide Activity Types (com.joinery.hideactivitytypes)
Hide activity types in one or more ways:
Remove the activity type from the "Actions" list on the Activity Summary.
On a per-contact-type basis: activity type will be removed from the "New Activity" list under a contact's Activities tab, based ...
I've found that deleting any emails with attachments prior to running Civi's scheduled allowed the processing to complete normally. While SOME small attachments are ok, generally attachments do not process well with Civi.
In general I use this rule of thumb:
- the core activity types that I do not use I will disable so I am sure they are still in the system and I do not disrupt anything without meaning to
- if I added my own activity types and I know I no longer need them and have no active activity of that type in the system I delete the activity type
Disabling is certainly ...
If the IMAP account is a Gmail or Google Apps account, it is likely you will have to enable a setting, "Allow access by less secure apps". That solved my authentication errors with a Google Apps account. More info can be found here: https://support.google.com/a/answer/6260879?hl=en
We had a similar issue and tried several tests to resolve the issue. Checked all Anonymous Roles to YES, not this problem. Turned off all WordPress Plugins, not this problem. Changes theme, BINGO!
There was a conflict with one of the JQuery/Lightbox type page overlay option within our theme that cause the forms not to submit. Removing that option fixed the ...
Did a bit of googling and figured this one out -- I didn't realize I needed to visit the access control screen [Administer / Users and permissions / Permissions (access control)] in order to enable the form to accept user input on submit.
I think by "tag" you mean put their name in the "reported by" field or something like that. Case activities don't appear in "non-case" contexts. This was originally a design goal to both keep case data more private and force people to keep case data inside cases instead of a mix of places.
So the short answer is you need to go to the Manage Case screen to ...
If you want to find all the users with Notes, you could use Advanced Search, expand the Notes section and enter '%' in the Notes text box (don't type in the quotes, just %) % means 'match anything' but there must be a note there to match against.
If you want to limit that to those changed last week you can expand the Change Log section and set the Modified ...
For the engagement index to show you need to have CiviCampaign enabled. For details on how to set up the index and other useful guidance you can also see the latest user guide
Hopefully it's just as simple as that to solve.
I don't think you will find a process to undelete a deleted activity via the UI. If you have access to the database then you could try finding the relevant entry from the log_civicrm_activity and log_civicrm_activity_contact to reconstruct your missing item.
When recording a new activity, the duration field indicates "minutes", but this is just a label within the form itself - activity reports will provide you with the duration column, but without indication of whether you are talking about minutes or hours, so this leaves you with two options:
(preferred) if you know your way into the code of the record ...
Ah, you have the answer in your question. If you look at your reference to the current code, it should be recognizing that MysqlColumnNameOrAlias instead of generating the error in the default clause of the switch.
So I checked the history of that file, and the MysqlColumnNameOrAlias case was only added mid-last year.
Conclusion - upgrade your Civi to the ...
So I'm fairly sure this issue was actually a dev environment specific issue. The dev database wasn't using the full 'activity' table (as it was so large) and thus creating some oddities.
If I see it again on a live env I'll have to investigate in future though.