groundwire / gwbase Goto Github PK

On the Lead Importer, I think it would be helpful to be able to click "Next page" or "More" in order to see more unconverted leads for the particular Lead Source view. Sometimes, for whatever reason, we are not ready to convert a particular lead but we are prevented from loading additional leads into the converter because it always indiscriminately loads the first 20, and then won't let us see more until those 20 have been converted.

The ability to use filters beyond just Lead Source to be more specific about which leads to load would be helpful as well.

Currently running reports that reference rollup fields is confusing, because we have the exact same set of fields with the exact same names on Contact and Account. It becomes very tricky for the user to know whether a field on a report is from contact or org, since SF does not in general include the object name. This is especially hard when selecting fiters.

I propose changing the org field labels to include the string "Org" at the beginning, and leave the contact fields as-is. We should be able to update field labels in managed pkg, although we can't update the names.

The one problem here would be that anyone who had created merge documents and SF email templates against these fields would need to update them. I think it may be still worth doing, as: a) a lot of clients won't have any merge documents against these fields on Account (Contact is much more common), and those that do shouldn't have a lot of them. It may be worth it for those few clients to have to make a few tweaks, in order to make this less confusing permanently for everyone.

Should probably warn the user and prevent save until they fix it.

Open a household with more than one Contact.

Remove a Contact

Find removed Contact using interface and add

Save

Contact is not added back.

currently we have fields on the contact for: Household Membership End Date, and Household Membership Join Date. We should include a formula field as well for HH Membership Status, following same logic as the one for Contact.

Saving a Household with no members renders:

List has no rows for assignment to SObject

Should probably hide the save button if the household is empty. Also, code should not attempt to insert/update empty list.

The Add Installments Wizard does not currently read the installments that already exist on the Opportunity, and it just blindly adds more installments and does not update Opp.Amount.

So it really doesn't work if the Opp already has installments. So this also means that for a normal single payment Opp, you can use Add Installments successfully. But if you go back to the wizard, you are out of luck.

When you use the NewOppWizard, we correctly setup Opp.Amount to be the sum of installments.

Later, if the user adds or removes installments from the Opportunity, Opp.Amount is not changed, and thus is no longer in sync with the sum of installments. This is just using the standard New button on the installments related list, or doing delete on an installment.

When converting a lead, add the contact to a new account that is marked in the Company field on the lead. This is a one-step process for changing employee affiliation which is not possible now.

Rectypes offered in the picklist seem to be in no particular order - looking at the code, they're fetched via Describe, and not sorted in code anywhere.

These should be be alpha sorted. When a group has a lot of rectypes, it looks very haphazard, and it's hard to spot the rectype you need.

We have a list setting for handling different contact roles per opp record type for Opps created for individuals. But if the Opp is an organizational opp, we use just our single setting for the default contact role (Organizational Donor). ifPeople would like to specify the default contact role per record type.

currently we have 3 list buttons on opp:

• Mark as Lost
• Mark as Thanked (Closed Won)
• Mark as Won (Won, Not Thanked)

I'm finding those are a little too coy, and confusing to users. They should just spell out what they do. So I propose those last two should read:

• Mark as Closed Won
• Mark as Won, Not Thanked

This will allow users to see if a contact's employee association needs to change after lead conversion.

the field Prospect Level on Contact in GWBase is a formula that is hard coded to return a value (Donor/Major Donor/etc) based on hard coded criteria (total lifetime giving, giving last year & current yr, etc.) The criteria is very specific and not likely to apply to many clients.

This field should either be removed (hidden in the DOT, renamed w "Deprecated" in the name), or should be changed to rely on settings and/or code. It's hard to imagine a series of settings that would cover the necessary breadth of options that might be needed here, but we could probably cover an acceptable range of options, understanding that some clients would still need custom logic using a different field.

As it is, I have hidden this field for every client I've worked with since it was put into the DOT.

When we go to the lead converter page, we get the default acct id in the constructor. In the case that there is no default account, our clever code tries to create one - but DML is not allowed at that point.

Repro:
1 Create a sandbox (it won't have an individual account)
2 Create a lead
3 Click convert (or click the importer tab)

Result:

• DML Not Allowed

The solution is to move that code to a page load action instead of the constructor.

ifPeople would like to only have households created for contacts who do not have an organization. They are able to turn off our Household trigger support, but in order for them to provide their own trigger to do this conditionally, we need to make the GW_Householding class Global, along with appropriate methods.

We should also verify that our code in general is robust in the face of contacts without Households. I'm not sure that it is. I think we even have an already logged bug that the lead converter fails if it comes across contacts without households.

Test issue!

If the lead first matches an existing contact, and you change the choice to new contact, the account field doesn’t get enabled to allow you to create new account. It is disabled on Individual. If the lead doesn’t match a contact, this problem doesn’t happen. This also doesn’t happen if logged in as sys admin, or before I made Leads private.

a low priority edge case:

If an acct has only one contact, and that contact is deleted and later undeleted, it should theoretically become the primary contact of that acct. Undelete is currently not handled.

Should probably have a min-height.

Clicking the Household button will render a "Page does not exist" error. This is because the formula for the button URL does not contain the prefix "gwbase__".

For an existing household selecting "Change" button for address does not allow actually changing the existing address, only select from a list (which isn't helpful) and enter new address. It would make sense to be able to modify existing address as a third option.

we should add a trigger so that when the last installment/payment for a pledge opportunity is saved, we change the pledge opp's stage from Pledged to Closed Won. This will bump up its probability to 100%.

From Matthew Scholtz:

" I think the little red remove from HH buttons need a bit more context – either a tooltip, or an “are you sure” dialog, or a notice on screen after clicking listing “Contacts to be removed”, or fading out the name card until Save? As is, the contact is gone almost before you realize what you did.."

Would be helpful to show the members of the existing HH. Especially helpful when adding a contact that is in a Household with one member where merging is really not an issue. Currently it seems like it "might" be.

Just ran into a client's instance with GWBase, and they have a bunch of unique rectypes on Opportunity. Our three show up in the list when you have to pick your record type, but we haven't provided any description for them.

From David Habib:

"I just installed the latest GWBase in Groundwire's instance. it installed successfully. I then went to a contact record, and clicked on that person's existing household. I got the following error:

No such column 'GWBase__recognition_name__c' on entity 'GWBase__ONEN_Household__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.

I'm taking off for several hours and can't look into this now, so let me know if someone knows what the problem is."

I'd like to see the ability to drag/drop cards to re-order which results in Household Greeting order changing as well.

Trying to merge to a contact you don’t own silently fails. One might say the converter shouldn’t even show those matches, however it is good as a speed bump to prevent the user from accidentally creating dups.

Currently, the Matching Gift Wizard does not specify any record type when it creates the Opp. This is problematic if the user's profile has a default opp record type that isn't appropriate. For example, Sean Pender just tried this wizard, and it created a Project opp.

My only question is whether we need a setting for this, or should always use the "Opp Rectype Contact Gift" custom setting? Also, does this setting make sense, since the Opp is going to get saved on the Org?

CURRENT: This program is released under the GNU Affero General Public License, Version 3. http://www.gnu.org/licenses/

NEW: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 3 as published by the Free Software Foundation. http://www.gnu.org/licenses/gpl.html

Currently Total Paid evaluates = Amount by default for any Won opp stage, unless you create installments. That worked great in the past, but now that we have a dedicated Pledged stage, it should work differently IMHO.

I propose:

• Total paid continues to work the same for all Won stages besides Pledged and Pledged, Not Thanked
• For Pledged stages, Total Paid evaluates to $0 by default, unless installments exist

In the scenario where a donor initially agrees to make a pledge, but hasn't yet decided on a payment schedule, this would allow a user to put the opp into a Pledged stage for the time being, without adding installments, and have SF evaluate the situation correctly (committed but not paid). Then once a schedule is determined, the user can add the installments. (Or if the donor unexpectedly pays it all off, just switch it to Closed Won.)

currently, if plone passes in a new subscription transaction w/ status Declined, our code creates a RPP and an opp as if it were a successful transaction. It should probably log the notification and that's it, or perhaps log a single Closed Lost opp.

Some of our clients will have many special record types of their own. I propose that in the newOppWizard, if the rectype isn't one of ours (gift, grant, membership), we just bail out and go to the standard salesforce ui. this way they will get the appropriate page layout for their rectype.

In the DOT we have dups of a bunch of the report folders as an artifact of installing GWBase, these should be removed before next stamp

we need to make lead converter more robust to handle no households, or at least gracefully fail with an appropriate error message. We will hit this too often when migrating old customers to GWBase.

I marked this high priority, because multiple team members have hit this when trying to upgrade a client to GWBase, and the error is never obvious and takes a bunch of time to track down.

Currently defaults whatever it finds as the first contact.

Decide if this feature should be in GWBase or as an add-on.

Code and test Auto Membership Dates to be compatible with DupeBlocker auto-merged Contacts created with online payment integrations.

Testing is only possible by uploading the managed package, installing to an instance with DupeBlocker.

First draft of code is currently commented out in GWBase: GW_ContactTriggerAfter.trigger and GW_AutoMemberDates.cls

Difficult to prevent this.

If an org name is long enough, you can't create an opp. Opp name class should check length of resulting name string. If it is too long, it should cut off the org name to the max length that fits with the rest of the name data.

We should not list any opps that are marked as Closed/Lost. Currently, they show up if they have an unpaid balance.

Would like to tweak opp rollups so you could add or modify what gets rolled up - for example, to add another year back in time. Probably implemented not on the current code but on the abstract class instead.

When adding a contact role to an opp, if you provide an ambiguous name an error message correctly tells you multiple contacts found and select from the picklist. However, the save link is gone so there is no way to save your selection.

Chrome 13.0.782
OSX 10.6.8

Need to wrap or add '...'