Apex Code Development You need to sign in to do that
Don't have an account?
A_Smith Want to deprecate components in managed packages? Read This!
Hi All,
I'm the Product Manager for packaging here at salesforce.com. We're currently working on a feature that would allow fields and objects to be removed from managed packages. This is a popular request and something we're hoping to deliver very soon, but we need your help. Please respond to this post with any thoughts around this topic. I've included a few questions to get the conversation going:
- Why do you want to remove these? No longer used? Customers didn't like them? Replace with a new field?
- When you deprecate a field/object, what should happen for existing customers? New customers?
- Would you have to remove all usage of a field/object in your app before you can deprecate it? What happens if you've included the field in another formula field, etc?
Thanks for your time and input!
In addition to deprecate, how about changes ? Some changes are not dangerous at all.
I made a mistake in the original design, discovered that mistake before the application went live on the AppExchange, and discovered that I could not correct that mistake. I literally had to rebuild the application from scratch in a new dev org. If this were any other platform I have ever developed on, the total time to correct this would have been about two hours. So far I've spent over 40 hours fixing this, with more to go.
It's my application, right? I should decide what happens for existing and new customers. If I don't do a good job, I lose my existing customers and don't get any new customers. If I do a good job, my customers don't know the difference. Either way, this should have nothing to do with the platform.
You should have to unwind all of the references yourself before you can remove the object -- that's just common sense. This should work the same way it does on any other platform you have every seen or heard of.
If I could summarize: As an application developer, it is my responsibility to design and develop the application -- it is not Salesforce's responsibility to hold my hand and thereby prevent me from doing my job.
In the same way that SF puts up a message whenever I delete a non-managed field or object, SF can put up a different, slightly more emphatic message whenever I delete a managed field or object. It's really that simple.
If you guys are worried about legal liability, then just change the terms and conditions and force everyone developing in the newest version to sign them. Some sort of a built-in version control system would also be nice, just in case you actually do want to hold our hands a little bit.
John
I could not agree more with John.
The whole idea of salesforce trying to prevent a developer from making mistakes that will hurt customers is something SFDC should re-examine - I think it hurts developers/customers more than it helps. Just warn me when I might make a change that hurts the customer, just warn the customer installing the package that newer version of package has incompatible changes - but don't disallow changes.
I have come to a point where a managed released package seems like a big irreversible commitment...
Frankly, so far the most common reason that something, once developed, should be changed is because Salesforce has released some new feature that makes a previous approach to a problem less desireable than the new approach.
I *certainly* think there is a whole class of behaviors that fall into the "relax restrictions" category on fields or objects that should just be allowed. John had some examples, you could also include relaxing uniqeness to non-uniqueness and perhaps others.
Regarding your questions:
Came up with a better approach; Business requirements changed; Improvements in reporting obviated the need for some fields, etc.
For new customers it should obviously just not be there.
For existing customers the concern is losing data, so you might provide some options. For example, do an automatic export of all records with an ID, and the deprecated field values, then delete the field.
Even more interesting would be if you provided a way for the developer to optionally call a "mapping function"to be called at installation which would allow the field values to be migrated to some other object/field, etc.
This idea could be extended to allow us to write an "upgrade path" sort of script for each version of the package to allow us to accomodate changes from version to version. (Yes, upgrade scripts can be the bane of developers existence. But sometimes they can be necessary.)
Yes, I think you would have to. If you wanted to allow the developers flexibility to not fully remove it, then you'd have to allow us a place to create "deprecated field defaults" in case the fields were used somewhere. That could get really ugly and it's far cleaner to just require no references.
Thanks for asking.
At the very least non destructive changes should be allowed. Here's my simple example:
I creatde a custom text field on a custom object with a limit if 20 Characters. In my mind this should be more than enough but later on a customer installs my managed package and complains that it's not enough. I think great, I'll just increase the Character limit in the next release.... except I can't.
In conclusion field changes that don't result in a loss of data should be allowed.
Philosophically, though I would urge that resources be spend in allowing programmers in making any changes they want - but providing them tools so that they can upgrade customers with minimal pain - upgrade scripts was a great idea...if I delete a field, if I could run a script at install that says what to do with existing values, developers would jump on it!
Thanks to all for the valuable feedback.
I wanted to specifically comment on the notion of just allowing deletions on upgrade. If a customer builds a component or integration that depends on the objects or fields from your package, then the problem is that we can't simply delete the field as the customer's components referring to that field would break instantly. Think about someone writing apex code that refers to your objects or fields. That's why we are exploring the deprecation approach. The concept is that existing customers would still have the object/field, but would be encouraged to stop using it over time. New customers would not receive the object/field. Any other thoughts on how you might like to see us tackle this challenge?
We're also exploring the notion of objects and fields that your customers cannot reference in which case you would be able to safely delete them during an upgrade.
I do like the idea about a mapping tool for replacement use cases. We'll have to explore that one a bit. Great idea!
Thanks again,
I agree this poses challenges.
However, an argument could be made that the code the customer has is already logically broken, the moment they do the upgrade. If new instances of the object don't have the field value in deleted field or have garbage, it is MORE dangerous to have the customer continue using their code,rather than have the code break - buggy code is worse than broken code.
My suggestion:
1.Let the code break! When customer is installing an upgrade with deleted field, the system would search for any other existing code/packages outside the current package that reference this field. If so the system would warn the installer that the extraneous code/package will break and they will either need to install an upgrade of the package that will break or modify the code to make it work or cancel the upgrade. If the installer still chooses to install, perhaps ask one more time...if they still say yes, so be it..break it...they presumably know that they need to upgrade other packages or modify their code. Perhaps not all code has to break - only the classes/trigger where the reference is made. One option might be provide a "backup" option - so that they can restore if things don't work out. Presumably, this backup would be only save the what is being deleted and not all data and reinstall all the old managed package...
2. Having a protected/private field that the customer cannot reference is a good idea. However, make sure that extension packages provided by the same vendor can reference them! However extension packages provided by third parties cannot reference them. Presumably, the extension packages provided by same vendor has an upgrade that doesn't use that field.
We need to increase a field length in one of our custom objects, but the managed packaging will not let us. What are the prospects for allowing a field length increase? It does not have the dependency issues of removing fields.
I have posted this at
http://ideas.salesforce.com/article/show/10096646/Allow_field_length_increase_in_managed_app
Please promote if you need it or think you will.
I desparately need this capability. Changes in our business operations have caused significant changes in some of the customizations we've put in place. Now, I'm stuck with a bunch of old fields running around while I have to set up new ones to meet the current needs.
One way around the problem with a customer referencing a field that is later removed would be to add a property to the field definition that says whether or not this field can be exposed to customers for access. Any field that is exposed could follow the current scheme of not being able to be removed. But if I define a field and set its property so that it cannot be exposed to be accessible by another package, I should be able to later delete or modify that field.
It would be nice to at least be able to hide deprecated fields and objects on new installations. Or have an option to
show/hide deprecated fields.
The page layout editor can get cluttered with fields no longer in use.
Hi NBlasgen,
We have added some new features in this area. Now you can deprecate any global apex identifier (class, method, etc) using the @deprecated annotation. We're also running a pilot for deprecation of objects and fields. If you are interested in this, log a case with the development org ID and please post the case number. I'll follow-up with you directly on getting into the pilot.
Thanks,
Andrew
Dear Andrew,
I have opened case #03291793 for the activation of our participation in this pilot.
We are developing a managed application for the sale of business aircraft charters, management of business aircraft and all related operational tasks such as crew and flight scheduling, flight dispatch, travel and maintenance. Quoting, expense tracking and reporting are also covered.
The app is live in production since a couple of months and as with all software developments the specifications are evolving, hence the need to make some core changes.
Many thanks in advance for your follow up.
Best rgds,
Niels
CTO, Perfect Aviation
I want remove custom tabs and static resources.
In my previous version we made a mistake putting some unwanted custom tabs and static resources in package after releasing the package we realized that we can reduce the tabs using VF tabpannel tag ,and right now we want remove the unwanted tabs and static resources and am not allowed to delete the static resource and custom tabs from my end because right now it was beta managed package I can do this type of process.
how exiting customer's instance will affect this type of changes after deleting the custom tabs and static resource with the help of salesforce at time package upgrade how my customer instace will react.
Such type of issue we need to consider deprecate the components Some expert suggested some solution for my current issue that will helpful to us.
Thanks
Gopi
Hi Andrew -
Our case number for the deprecation pilot: 03341877
Thanks,
Ron
Hi Andrew,
I'm not sure if there is still a pilot to deprecate fields, however, our company has created a managed package and I need to deprecate 2 custom fields from our managed packaged solution. Any idea on how to proceed?
Thanks,
Marc
Did you distributed yours managed package or not ?.If you are not then file a ticket with salesforce revert back all managed packages into beta then remove the unwanted components.
If yours package was distributed it was not suggestible solution .Wait for salesforce announcement.
It is really a problem if some unwanted fields exist in a package some time :smileyhappy:;
Andrew, we would love to be part of the pilot as well and I've logged Case 03446367.
Thanks,
Jon
Need urgent assistance with removing tab in a managed package. EE org limits 25 custom tabs. Packaged app created actually puts the org over the limit at 26. However one was not added it was somehow inherited.
Is there any access black tab or other that can remove an element from a package... obviously it's not available via the UI (WHY NOT>? ... seperate argument).
Anyway just need to remove the TAB ASAP so that package updates can be pushed to customers.
Hi Patrick,
Have you been able to make any progress on this? I'm in the exactly the same situation, so would appreciate any tips or insights...
I have a managed up from which I'd like to remove a tab, but am unable to do that...
Thanks!
Alex
Hi Andrew,
I was wondering if the object/field deprecation pilot was still open (in which case I'd file a case for it).
In addition, I'm wondering if you could recommend some way to remove a tab from a released/installed managed package. It seems that locking down tabs like that is extremely restrictive and forces developers into workarounds that end up eventually exhausting the common 25 tab limit. Could you offer any guidance or insights here?
Thanks in advance,
Alex
Hi Alex,
This pilot is now closed. We don't have a date for when this feature will be GA.
If you are a salesforce.com partner and have your app listed on the AppExchange, then you can request that it be enabled as Aloha which will allow your app to be installed into any org regardless of the app, tab, and object limits. Log a case in the Partner Portal.
Thanks,
What is the status of this? We've got an object that our developer accidentaly added into the managed packed. It is a duplicate of one that should be there and the problem is that they now both show up for the user to click on. We don't know what to do now. We're stuck. ANY ideas would be greatly appreciated.
Any update on the ability to deprecate fields and objects in managed packages. Its all gone very quiet on the Salesforce side, lots of noise on developer side. If Salesforce was a map Managed Packages would be at the edge of it with a label that read 'There be monsters here'
Our experiences has been build a 'beta' that is in fact a managed packaged i.e.. not a 'beta' as defined in the Salesforce packaging wizard but an actual managed package that is actually a beta version of your package as there is a difference in behavior between the two and use a specific 'staging' org to create the package.
More specifically to this topic. I think deprecation over deletion is the way to go. Storage is cheap so the fact that old data is floating around is not a big issue and it prevents integrations breaking. If a field or object is marked deprecated then the upgrade should:
1. Make the deprecated field readonly regardless of previous permissions, with the word deprecated appended to the label.
2. Remove the field from page layouts but allow the Org Admin to put them back in if required. Associated Tab's should all be hidden.
3. There should be an Exception Type called DeprecatedException that allows integraters to check for this issue and change their code as required
4. The Mapping feature is an excellent idea. It allow one Object/Field to replace the function of another and effectively act as a Rename.This stops existing code from breaking and gives Users and Integraters time to readjust.
5. Related to this you would need the Map function to remove the 'external Id' and 'unique' flag from a deprecated field in order to allow its replacement to use these flags without exceeding the limits on an object
Overall I think the Force.com platform is fantastic, I've worked with ASP.NET and C#. A great language but it requires huge effort just to get the boiler plate stuff working (Java is no different). And if anyone has worked with a n-tier design the simplest change to a database field can take a significant about of effort to bubble up to UI. This is the power Force.com has over other platforms BUT and its a big BUT to fullfil is it very significant promise deployment and Manage Packages needs to be sorted.
The development of commercial SaaS based solutions is based around short iterative development cycles not big releases. Managed Packages currently work against this approach.
More thoughts...
We happen to working through a beta of our product at the moment so the the managed package process is very much our minds. We've run into an issue with Field History Tracking. We decided to switch tracking on some custom objects and then build a new package. However when installing it via an upgrade it fails because Field History Tracking is not enabled in the target object. The problem here is that the customer has the abiility to switch Field Tracking on and off whichmay cause issues with future upgrades
So added to the list is the ability to switch field tracking on an object On, or at the very least tell the client to switch it on the required objects. At the moment installation fails and they get a meaningless error message.
The only deprecation that is supported today is around apex classes and methods. You can find information on this in the apex code guide.
You should be able change the label of your existing components. Just not your API name of them. Then you could reuse them instead of deleting and creating new ones.
Andrew,
Just to clarifiy, we can change the label of a field in a managed package and then deploy, but the subscriber to the package cannot.
The subscriber can as well - you need to use the translation workbench.
Ah, thanks.
WE NEED TO BE ABLE TO:
On deletion of a field be able to access that field during a post install script to migrate the data.
Scenerio:
Delete an existing Lookup field - to be moved to a new custom object
The field can be access in the subscriber org via dev console but no classes can acces it, either newly written in subscriber org or in the package as the version tied to the class is the new package version which the field has been deleted from.
We need a way to programatically access that field from a post install script so we can create records in a new object based off of the value in the deleted field.
This would be extremely helpful when the design of the data model changes.
The way this feature is designed, for the component types that can be deleted from a published managed package, there is a multi-step process:
1) The developer deletes the components from the managed package in the dev org (deletion succeeds as long as there are no references).
2) The developer uploads a new version of the package.
3) When a subcriber's org upgrades to this new version, the components become delete-able (i.e. the delete link is available for these componennts) by the subscriber org sys admin. But we do not delete these components at upgrade. It is up to the subscriber org sys admin to export the data, dis-entangle references if any in their org, and then delete these components. This means, at upgrade, you have access to the "deleted components" in the subscriber org.
New Updates made in Dev Org with codebase sans package
--> Test Package Org with unmanaged and managed (with test namespace) packages
--> QA Orgs (both 'internal' with unmanaged package installed & 'external' with managed package installed)
If all testing passes QA we push to the Deployment Org (which has our true managed package & namespace) and, if possible, our Patch Org for automated distribution.
The problem is you are unable to add the @deprecated keyword to classes not maintained within a managed package, meaning our flow is broken since the source code in our Dev Org is unmanaged.
I believe it is a best practice to avoid development within the Deployment Org directly so instead of using the keyword we've just commented out all logic within 'deprecated' classes; it would be great to just delete them entirely though if that is now possible.
Thanks
Davide