I love it.
Some good points in there about many aspects of our careers and lives: http://blog.jcoglan.com/2013/11/15/why-github-is-not-your-cv/
I’m not entirely sure which archaic version of Microsoft Outlook we are using, but it’s the one that neglected to ship the “Check all checkboxes” option at the top of the screen. This means bulk deleting spurious emails is worse than the emails themselves.
Then once you have deleted the emails, you have to go and select all of the emails again to delete them from the Trash folder, because Microsoft also neglected to add the “Empty Trash” button.
So, Google Chrome API to the rescue.
- Open up the console which on the mac is (ALT + CMD + i)
- Click on “Console”
- Then type in the following command:
Once you press enter it will select all the emails and then delete them
I’m not a fan of studio (another post some time), so this is here for me to remember how to do this in the future.
If you do use studio and create relate fields you will notice the rather abstract naming convention it will give to your id field.
A worked example:
You need to add a new relate field for a new type of manager that will be on the Account bean. So you go to Studio and create your relate field, linking to Users/Employees etc. If you then check in the database you will see a new field looking something like user_id1_c. Well, I guess that isn’t too bad if you have a small team and can communicate this field to everyone who needs to know, however I suspect that is unlikely. However, what if you have 10 managers/people you need to add to the Account bean, you will end up with user_id2_c, user_id3_c etc and so forth. That is headache material on a good day. If you have a developer that simply looks at the raw data to create reports outside of SugarCRM, how are they to understand the schema?
This method gets around that. I’ve created a new file in custom/Extension/modules/Accounts/Ext/Vardefs/sugarfield_supreme_manager_c.php that looks a lot like:
/** * The name we can reference in the code and views etc */ $dictionary['Account']['fields']['supreme_manager_c'] = array( 'audited' => false, 'calculated' => false, 'comments' => '', 'default' => null, 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => '0', 'ext2' => 'Users', 'help' => '', 'id' => 'Accountssupreme_manager_c', 'id_name' => 'supreme_manager_id_c', 'importable' => 'true', 'len' => '255', 'massupdate' => 0, 'module' => 'Users', 'name' => 'supreme_manager_c', 'no_default' => false, 'quicksearch' => 'enabled', 'reportable' => true, 'required' => false, 'rname' => 'name', 'size' => '20', 'source' => 'non-db', 'studio' => 'visible', 'type' => 'relate', 'vname' => 'LBL_SUPREME_MANAGER', ); /** * The actual id field we want in our database table. Note the name! */ $dictionary['Account']['fields']['supreme_manager_id_c'] = array( 'audited' => false, 'calculated' => false, 'comments' => '', 'default' => null, 'duplicate_merge' => 'disabled', 'duplicate_merge_dom_value' => 0, 'help' => '', 'id' => 'Accountssupreme_manager_id_c', 'importable' => 'true', 'len' => 36, 'massupdate' => 0, 'name' => 'supreme_manager_id_c', 'reportable' => false, 'required' => false, 'size' => '20', 'source' => 'custom_fields', 'type' => 'id', 'vname' => '', );
Once this is saved, run a Repair and Rebuild and you will see that it will ask you to create a field called “supreme_manager_id_ic” which is rather more verbose and helpful.
Please note: You have to specify the “id” field, otherwise when running a report (Reports module) SugarCRM will get confused what table to look in and probably not look in the _cstm table – This is certainly what I found.