Richard Evans - 8 years ago
I'd really like to see this. I recently wanted to refactor an App but found that the majority of things I wanted to change were locked down. I tried going down the 'push update' route but this requires that your App has gone through the paid for security review, which it was not ready for.
Larry Wieskopf - 8 years ago
Definitely required. As our package evolved it was necessary to change the name field from AutoNumber to Text. Logically there shouldn't be any reason why not. (Obviously going from Text to AutoNumber would have issues) Not being able to do this means we have to create a new object, redo all our triggers, & relationships, build a migration script to move the main table and remap all relationships. Not fun :(
Jordan Baucke - 8 years ago
Any progress on this one? I would really like to see managed package owners be able to developer their iterative process so that new package members can be intelligently changed.
Grant Liu - 8 years ago
Max length of text fields needs to be edit-able too. Say, for instance, the SFDC platform increases the max allowed length for long text fields. To take advantage of this, managed pkgs would have to be re-released with new fields, deprecating old ones. All existing customers then need to undertake a migration of data from old to new fields.
Grant Liu - 8 years ago
Another example is changing the max length of fields. For example, if SFDC ups the max length of, say, a long text field in the platform, the only option for managed packages to take advantage of this is to re-release with new fields, deprecating the old fields. This means existing customers must undertake a risky migration of data from old to new fields. Painful. Risky.
Kerry Desberg - 8 years ago
Make Workflows More Flexible Too!
I have found Outbound Messages extremely limiting. For example, why does the endpoint URL have to be hard-coded? There is no way to change endpoint Urls between Sandbox and Production instances. Very limiting indeed.
Also, the ability to add and remove Workflow Actions from a Workflow Rule seems reasonable. I have done some testing and found out that you can add Unmanaged Workflow Rules to a Managed Workflow Action. But you have to go a round-about way to remove it. I think it would be slick to give customers a "base" set of Workflow Rules with Workflow Actions in a package, and also include some un-used Workflow Actions that they could attach to Workflow Rules at-will.
Luke Kozakewycz - 8 years ago
What I find most annoying is that if I made a release and was not aware that a feature is unavailable in a specific edition, I come to a dead-end and I am unable to delete the component which is restricted from my managed package.
I've already had to completely re-build an application in order to make it available on more editions and with the new release, I still don't have full compatibility.
PLEASE implement this. This is a must!
iHance Devs - 9 years ago
The package restrictions (and their cousins, the list of things you can & can't do in a push upgrade) are focused on syntactic compatibility across versions. So I can't, say, delete a WebService method ever, because that would be a breaking API change ... but I can utterly gut the method, or change its internals to be "delete [select Id from Contact]", or whatever.
Given that salesforce cannot protect against semantic changes, why are they so hung up on restricting syntax-level changes?
To take the whole thing up another level, why are there even separate versions for packages? Salesforce doesn't maintain multiple versions for customers - everyone gets upgraded at the same time, and only one version of Salesforce is ever running at once. But for partners, we have to do all this package management and version management. It's a ton of make-work, and a ton of pain, but for what benefit? If multiple versions really were such a good idea, why doesn't the platform itself do it?
Take a page from the Heroku guys - each package has only one version. When you publish new code, all existing deployments are upgraded together. Package providers who need to provide backwards compatibility will do so; those who do not will not.
Richard D Boyd - 9 years ago
We should be allowed to:
(a deprecate custom objects and fields. The effect is to still give client access to existing data but prevent new data being added. It should also hide associated tabs. It also allows clients to move away from using the field or object. Allowing deprecation of custom fields and objects could be the first step SF make in allowing it more control - its at least a step in the right direction
(b delete custom fields and objects and expecially Master/detail relationships. Next phase in process. However for Dev's there is the challange of ensuring client data is not deleted by a destructive change
Keith Clarke - 9 years ago
Another surprising restriction http://force201.wordpress.com/2011/03/04/auto-number-fields-you-had-better-get-them-right-in-version-1-0/.