SAFE HARBOR: best to double check if this works on a Sandbox, before executing this on your production data. I have just written this here without explicitly testing
What you will have to do is change your profile settings to include the --master-- record type in order to "see" it, you will also have to do this for every profile on your org, to make sure your Record Type isn't being used by other profiles, else you won't be able to delete the record type
- Go to Your Name -> Setup
- Administration Setup -> Manage Users -> Profiles
- Select your profile, and go to Record Type Settings
- Choose your SObject (Product2) -> Edit
- In order to include --Master--, you will have to remove the other Record Types
- Save
- Repeat for every profile in your org
Side note:
I don't think it is actually necessary to move records to another recordtype with code, try going to your SObject -> Record Types -> Select your record type -> Deactivate -> And now try deleting it, you should get the option to move all the records with that recordtype to another.
If you would need to do it with code, this is probably the easiest way.
Now you have multiple things you can do, but either way you must update all your SObjects (Product2) with that recordtype in your database and put the RecordTypeId on (blank), you can do this via the dataloader, by first exporting, then clearing all the values in RecordTypeId, and doing an update.
But I find the easiest way to achieve this is by Apex, more precisely executing Anonymous Apex via the Eclipse IDE
- Start Eclipse
- Add your project
- Next look for the View Execute Anonymous, it can be somewhere on your screen but if you can't find it go for: Window -> Show View -> Execute Anonymous
- Make sure you select the correct Project when executing.
- Execute the following code:
List products = new List([SELECT Id, RecordTypeId FROM Product2 WHERE RecordTypeId != NULL]);
for(Product2 p : products)
{
p.RecordTypeId = NULL;
}
update products;
Now you'll need to deactivate your recordtype, and then delete it
Best Answer
If you want to develop an industrial-strength Force.com application, i.e. an AppExchange app, you CANNOT rely on either the
Id
orName
fields of RecordTypes as a means of getting at a desired RecordType for a given object. Why? Because the Id will be different in every customer's org, and the Name may be different in every customer's org AND for each Running User, depending on the user's language.Therefore, it is ESSENTIAL to request RecordTypes by
DeveloperName
.HOWEVER, it is also essential to note that there are TWO pieces of information about a RecordType that you need to know about: is it Active in the org (meaning, anyone in the org could potentially use it), and is it Available to the running user (a Profile/Permission Set setting). The
IsActive
field is available on theRecordType
object, as it is global, and user/profile agnostic. TheisAvailable
property is available through theRecordTypeInfo
object, and therefore should be acquired through the Schema methods.Here is a utility method, VERY suitable for caching, that, for a given Schema.SObjectType, returns a Map of that Object's Active AND Available RecordType Ids, keyed by DeveloperName:
TO use this to accomplish your need within a Trigger or other Apex scenario, you can just do this:
Notice that we do NOT assume that a given RecordType is either Active or Available to the running user --- we dynamically check. This is essential to consider when leveraging record types in Managed Package code.
Also notice that because we look for RecordTypes by DeveloperName, this code is completely organization and user agnostic. It will work no matter which org we are in, no matter how the org's admins have overridden or customized your expected use of your installed record types, and no matter which Translations of your RecordTypes' Names are being used.
Finally, notice that because we do a Dynamic SOQL query, this code will allow your AppExchange app to be used in Professional Edition or Group Edition, which do not have RecordTypes. Any hard-coded references to non-supported objects will cause your app to be disqualified from org editions which do not support such objects --- but use of Apex system classes and methods is fine no matter what features your org supports, therefore
getRecordTypeInfos()
can be safely used.