Apex Code Development You need to sign in to do that
Don't have an account?
bradvoy Removing items from managed package
I have a managed package which has been published to the AppExchange. I now want to remove a couple of items from the package and re-publish it. But when I look at the package detail, most of the items in the package do not have a Remove link next to them. How can I remove them?
I'm noticing a "Beta" checkbox during the package upload process with the following help related to it:
"Uploading a managed package as beta ensures that any components added since the last released (non-beta) upload are fully editable and can be removed from the package. A beta version is not publicly listed on the AppExchange Directory; it is only installable by knowing the install URL. In addition, beta versions may only be installed in a Sandbox or Developer Edition org."
Perhaps there's a correlation with your issue. This is all just a head scratcher for me...:smileyindifferent:
Yes - I am in the same place with one of my applications. It appears that once you switch from a Beta to a Managed application there is no way to go back - even if the application has never been installed by another organization. As a managed application, you cannot delete any components.
Can someone from SF comment on what steps are available to developers to "unmanage" an application?
Who do we contact? I tried the "developer" support desk but I only had the option of leaving a message...
I've noticed since converting to managed that newly installed packages from other Developers automatically add our namespace prefix to their objects and properties. This effectively kills our ability to integrate with others or build on base packages.
We frequently ask clients to upload private packages for review. This scenario now also automatically adds our namespace prefix to their objects.
As a requirement, I would expect only internally created and owned custom objects to be prefixed. I would expect the ability to manage multiple apps, or at least change which app is under management.
This particular DE org is the registered owner of our AppExchange apps and is our identity user on community sites, so abandoning it is not really an option. I too wish I could "undo" our managed status.
Uggggh. :smileysad:
This is to make sure that upgrades do not break for customers (their customizations stay in place and non-of their meta data is removed). This is also the same way that Salesforce.com does upgrades. For example, once we release an object like Account, we first beta test it with customers in pre-release, and then once we do the release - we cannot remove a released field like Account Name because that would break the customers environments.
You should be able to make destructive changes to your package if that component has only be uploaded in a beta-package.
Also, while you cannot "unmanage" a managed package, you can create an unmanaged package, and add the same components into that package.
Jim
Jim Yu
Director of Platform Product Management
Salesforce.com
As an application developer, I know how the fields, objects, etc. in my application are being used. I may have a field or object that was being used by external code (via the Salesforce API) but is no longer being used. Removing this field or object will not break anything for users who have installed my application, so I should be allowed to do so. Of course there is no way for the platform to know which items can be safely removed, but you should trust application developers to have this level of understanding of their own applications. Perhaps display a warning if I try to make a "destructive" change to a published application, but let me go ahead and do it if I really want to.
In my case I released an application that includes a custom link for the Product object. The application was successfully beta tested by several customers. But after it was released we discovered that some Salesforce Professional instances don't include the Product object. Our application can't be installed in those instances. I want to remove this link from the package so it can be installed by these customers. None of our existing customers are using this link, so making this "destructive" change wouldn't hurt anyone. But the platform won't let me do this. And I can't create an unmanaged package to do the same thing because the namespace prefix makes it so external code sees managed and unmanaged objects with different names via the API.
Please trust your developers and give us the ability to remove items from our managed packages!
Field.Archived (bool)
Field.Version (int)
I agree with the with above posts. I love the upgradability however, in two recent implementations we have found out the hard way that destructive changes are not the only functionalities that have been disabled. In my humble opinion, changes to the following object attributes do not fit into the ‘destructive changes’ category:
Custom Object Attributes
- Allow Reports
- Allow Activities
- Track Field History
- Record Name Display Format (Huge - in our sector, Auto Number IDs need to be in a customer specific format)
- Object Label - Different customers have different terminologies
Custom Field Attributes
- Field Labels (if changed from a customer’s implementation, subsequent installations should not overwrite the values)
- Default Value
- Increasing field size (Text Fields 50 to text 100).
- Require Field (Text Fields)
- Unique (Do not allow duplicates) (Text Fields)
- Number Options (Increase only – this one is probably in a grey area)
- Formula
Custom Button Attributes
- Window open properties (Size, scroll bars etc… but you can change the URL that it points to?)
I am sure that I have missed some – I urge other developers to poke around their environments and find more. I think Salesforce would greatly appreciate the feedback! Enabling these features for many developers is extremely important – even after our extensive q/a process we’ve had customers request functionality that we can’t deliver on because our packages are out of beta. Another suggestion I have is Deprecated objects. I can understand not deleting objects that are in production however, excluding them from new customer implementations would clean things up a bit.
There are several different things going on here:
Object Label and Field Label: With the current architecture, an attribute may be either developer-controlled, or subscriber-controlled, but not both - because if both can change the field, then it isn't clear what should happen in an upgrade. So, the developer can change these attributes, but the subscriber cannot (without using Translation Workbench).
Allow Reports, Allow Activities, Track Field History: These attributes are subscriber-controlled. Allowing the developer to modify these attributes after release is possible, but it would be somewhat misleading: existing subscribers would not receive the changes. As a developer, you cannot rely on a subscriber-controlled attribute having a particular value.
Record Name Display Format: In your particular use case, this should be subscriber-controlled, not developer-controlled. However, there are scenarios in which the field must be developer-controlled (ie if your app is composite and your external integration relies upon a particular id format). Again, we had to choose either developer-controlled or subscriber-controlled.
Uniqueness & requiredness: Changing a field from non-unique or non-required is a breaking change - subscribers may have external integrations that assume non-uniqueness/non-requiredness.
Increasing the size of a text field: Unfortunately, this could be considered a breaking change as well - subscribers may have external integrations that assume a certain maximum field length.
Please remember that Winter '07 is the very first version of managed packages and upgrade. We're aware that the system is currently over-constrained. Over time, we plan on relaxing the restrictions in some areas as we increase the expressiveness of packaging and upgrade, and our metadata in general.
Customizable labels are a requirement in all our solutions. Are formulas and merge templates the only 2 entities that have dependencies on labels?
Perhaps the long term solution is to support field object names in formulas and merge templates.
For example, a formula for calculating Net Profit/Loss would support both the Label and Object Name syntax:Code:
{!ObjectName.Revenue} - {!ObjectName.Costs} -or- {!PRFX__ObjectName__c.PRFX__Revenue__c} - {!PRFX__ObjectName__c.PRFX__Costs__c}Not the most user friendly syntax to look at, I'm sure, but the benefits outweigh the cons.
Customers could then change the labels without impacting the formulas and merge templates and Developers can multi-purpose their base/generic packages.
I have a similar problem
One of our custom objects uses 2 lookup fields to Products and Campaigns [prfx_related_products_c] [prfx_related_campaigns_c]
It was put in there only for ease of reporting and relating our objects to Products and Campaigns. It does not compromise the integrity of the data if they are deleted.
Our app can no longer be installed by customers using Editions that do not support Products or Campaigns.
I must fix this. What are my options?
Message Edited by GFlynn on 04-01-2008 07:17 AM
it's a 4 years old problem! I cannot imagine we are still unable to remove fields of package! It's unbelievable that we have to create a new Dev Org (because just one managed package / org...), to import all our stuff just to be able to remove a few useless fields of an old package... What a lost of time....
Is there a way to remove the unused fields, since nobody is actually using the package?