Salesforce IdeaExchange
Control the Packaged installed (DOT with LMA)
Good Morning,
We have many ORG’s that were created using DOT. Unfortunately we don’t have a control in which package is installed in each ORG.
I know that it is possible using the LMA, but with DOT they doesn’t work. I suggested to created a way to control the packaged installed with DOT.
I'm available to provide more information.
Best Regards,
Roberto Kaiser
Ability to use formulas when creating select criteria
Many time when I want to create new field such as roll up summary I want to only calculate the amount for future revenue or current revenue stream, there fore I need to populate expiration dates but they are not accepted as a formula so I have to hard code it, which means that in time it will no longer be valid, if I could use (NOW) function for example this problem would be resolved
Data Loader Update Notification!
Here is a simple one. It would be great if somewhere within the Data Loader download page it would indicate the current release.
Mini-Profiles for Applications
Have you ever been challenged with installing and upgrading packages? Have you ever needed a more granular set of controls and permissions for users on a per package or application basis? When downloading applications from the AppExchange, have you ever wanted to delegate your administrative capabilities over just that one package to a user or group of users?
If you've ever answered yes to any of these questions, you may be interested in reading further. Access to package contents is currently the the domain of a profile. When you install a package into an org, you must specify either a full or no access model on a profile basis. Of course, there may be times when you want to provide more granular control of which user's get access to which portions of package functionality. For instance, a designated SFA user may also need to be an administrator for a set of dashboards that have been downloaded from the Appexchange. Or a Support manager may need to also be a hiring manager for a recruiting application. Or an HR business partner may need to submit their own PTO requests through the Time Off Manager application and, at the same time, perform data administration tasks such as managing the Holiday schedule. In all three use cases, it's impossible to increase or decrease access without affecting all of the users who share the same profile.
Access Controls for packages would allow you to better associate the sets of permissions and access that are necessary when distributing new applications and application components within an organization. Each new set of controls could be packaged and distributed throughout an organization. And each set of controls, which may resemble a subset of profile controls, would allow for better scoping of permissions on a per package or application basis. In addition, each package might have multiple levels of access including, but not exhaustive of, a package administrator, manager, end-user, or really any different set of responsibilities that a user might need to have.
Cannot include validation rules for standard objects in package
I have created some validation rules for fields in opportunity, but when I create a package for my application and install into another salesforce instance there appears to be no way to include these validation rules. I therefore have to add them manually each time my application is installed.
Document Organization level Options that Affect Apex Code
Some organization level options can hide public properties on sObjects, which can make working these objects difficult if your goal is to support as many environments as possible. For example, disabling "Enable Activity Reminders" under Setup->Customize->Activites->Activity Settings, will remove the "isReminder" property from the Task class in Apex Code.
These types of options that can affect Apex code objects should be fully documented in one place. The documentation should also have examples on determining the state of the option and gracefully handling different states with Dynamic Apex.
Allow Managed Packages to Manage Page Layout Assignment
I created an app that controls the page layout based on record type, a very common use case, and found that the layout assignment was not installed with the app. This needs to be installed along with the page layouts and record types! It's really annoying that my users have to configure this when I already have.
Intellectual Property Rights- Code Protection
One of the major drawbacks of Salesforce is that the s-controls which we code are exposed to the clients, who if are resellers they tend to be at an disadvantage.
A partial solution that we can have by "Manage Packaging" our code in which we mode as much as we can on to Apex as then it is hidden from users.
With Visual force around , will it help us in sheilding our code from the users?
We have tried "Obfuscation" but it at times causes some issues. We would suggest Salesforce comes up with some in built API for hashing code.
Thanks and regards,
Ispita Saha.
Pre-release improvements
The current pre-release process is broken in a few ways
1. No code freeze
The pre-release environment is very different from the eventual release. When we find a bug in pre-release, we're never certain if it's an artifact of pre-release or if it's actually a new bug.
Conversely - and much, much worse - things that work perfectly in pre-release suddenly break when the new release actually goes live because salesforce's developers are adding new features & new code long after pre-release is available.
2. Namespace changes
Changing the namespace of our code makes it much more difficult to actually develop or bugfix on pre-release. We would have to fork our existing code with the new namespace, and then eventually merge changes back into the mainline while being careful not to bring the mangled namespace back with.
3. Inability to test packaging
I want to be able to build a package in pre-release, upload it to a private AppExchange package, and then install it onto a separate org (maybe sandbox?) to test that entire cycle.
The Winter09 release in particular has shown just how important each of these items is, as many partners and ISVs have had to deal with a two week period of breakage since the release.
These past two weeks have entailed a lot of late nights for partners and for salesforce's own developers; this could have been avoided with a better pre-release process.
Share a Namespace and/or Multiple Managed Packages per DE
Partners/Developers looking to release more than 1 Managed Package must have multiple DE accounts, since DE only allows 1 MP. As a result, they need to manage and maintain multiple namespaces. This can become difficult to manage if there is shared code they want to leverage in multiple apps. They would need to rework the code to handle these various namespaces. I see two possible solutions:
1. Allow a DE to have more than one Managed Package
or
2. Allow a Namespace to be share by another DE org
Rollback Managed Released Package to Managed Beta
Developers/Partners need an easy way to rollback a Managed Released Package back to Managed Beta if there is something that needs to be changed. Since Managed Released Packages are so tightly locked down, there are instances where the developer may have released the MP too early. If the developer can confirm that it's not installed anywhere, they should be able to roll this back to Beta on their own, without SFDC intervention.
This is also valuable if the Partner wants to work on the AppExchange listing, while the package is in Beta. Since you cannot create a listing on a Beta MP, the partner can release it, make the listing and then roll it back.
Error Importing Package
I'm getting an error while I'm trying to install a package in this org. Could you please tell me what's the problem? Here is the error displayed:
Your requested install failed. Please try this again.
None of the data or setup information in your Salesforce organization should have been affected by this error.
If this error persists, contact Support through your normal channels and reference number: 853917081-442 (1271179729)
Subscribe
POST IDEA