2

In a managed package, on a Custom object, I have a lookup to contacts. This lookup simply returns all contacts from an org.

Now I have a use case, where a client of ours (which has the package installed) would like to limit the results the lookup has access to, to a certain record type of contacts. Is there a way to define a lookup filter outside of a managed package, to a lookup inside a managed package? I don't want to go and add a filter to my lookup inside the managed package, because some clients won't have any record types on contact.

Doesn't have to be a solution with a clean working method, can also have some hacking involved if needed.

1
  • 1
    How about a custom setting (Hierarchical if you choose Validation Rule) to hold the RT ID/ Name and a Validation Rule / Before Insert/Update Trigger to enforce the validation? Commented Jul 2, 2013 at 8:58

3 Answers 3

2

The only thing I can think of is to add a org wide custom setting with some kind of override telling the package what field to use. They would create the field on your object, restrict the lookup appropriately, then use the custom setting to specify the newly created fieldname.

The real suck of this is that you will have to make everything dynamic as it relates to that field name. This would mean dynamic soql, .get('s, abstracting any visualforce references back to a custom controller, you name it. This could wind up being a pretty major refactor of the existing code base.

Sorry I didn't come up with any magic bullets, but figured it'd be worth contributing.

1

If you really want to allow just a client-managed SFDC-standard filtered lookup to override your package, there isn't a clean way I can think of, but I can think of a sneaky way that still uses standard functionality.

In your code, allow for a specially named custom field to be defined, say Account.Filtered_Contact__c, where if it exists, the client can specify their own filter logic. In your controller code for the page you are describing, you call the Describe API, and if that field exists, you use it and expose it as a set/get, otherwise you expose your standard packaged field (e.g. My_Object_c.Contact_c).

In your controller, you set/get either the override field allowed for, or your normal custom field.

In your VF page, nothing much changes - but in practice, if the client has overridden the field, they will get a filtered lookup, otherwise, they will get your normal non-filtered lookup. Standard VF component behavior prevails based on the underlying field.

You will probably need some code to copy the value from your overridden object to your "standard" object upon save/edit, but otherwise, the UI should just work. Disclaimer/source: I have not done this exact thing, but many similar things.

1

I ended up going for the following solution, at this point this Managed Package isn't going to be published on the appexchange, and only limited clients are going to work with the package, I can handle what happens to all installs (for now), this isn't really clean and another solution must be found when facing large deploys.

In my package I defined a checkbox field, Filtered_Contact__c, on the lookup to the custom object, I defined a lookup filter, to only include contacts which have the Filtered_Contact__c set to true.

On my client's org, I created a trigger on contact, which sets the checkbox to true or false, based on the conditions I want.

I also dit a mass update for all existing contacts matching the filter criteria my client needs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .