This document provides information pertaining to whether the packages published
by ONE/Northwest
and Groundwire
as a part of the GW Base
or GW
Template
must be uninstalled, or have a special configuration established during:
Package configuration needs for use of the Salesforce Account Model Conversion
(AMC) utility are also evaluated/documented here.
Productioninstance to a
sandboxused for testing data manipulations required as part of a upgrade or conversion to NPSP V3
Data transfers of this type may be required if:
developeror
developer prosandbox is being used for testing NPSP V3 upgrade/conversion processes
The use of these sandboxes can avoid the expense of a full sandbox in some situations.
Even though a full sandbox will include data contents, the typical full sandbox 29-day refresh cycle may result in a need to reload the sandbox if a single upgrade/conversion test doesn't suffice.
Red-colored text is used to represent critical information items that may interfere with needed operations in very important ways.
Blue-colored text is used to represent useful information which nonetheless is somewhat less than critical in importance.
Green-colored text is used to represent useful information which indicates an absence of problems or special configuation/data handling needs.
Information provided here is copyrighted by Larry Bednar and licensed under the GNU Free Documentation License. A copy of the text of this license may be found at http://www.gnu.org/licenses/fdl.html
The main points of the GNU license indicate that users are allowed to distribute the orginal licensed product, or distribute modified versions if the following conditions have been fulfilled:
If a more detailed understanding is needed, please follow the links provided above to review the actual text of the GNU licenses.
If you distribute modified copies of these items, it is both polite and useful (but not required) to provide some additional information:
[(LB) - The packages that I examined were almost entirely unmanaged.]
Publisher: ONE/Northwest. (Later known as Groundwire
)
Package Names:
(Installed twice)
Package Version: (indicated in package list provided just above)
Description: (Typically not provided with these packages. Attempts to view package
details result in a page display indicating An internal server error has
occurred
)
Package components include:
[LB - Most packages installed in the instance I worked with did
not allow viewing of "package components" in the typical expected fashion within the
Salesforce UI. (Attempts to view package details resulted in a An internal server
error has occurred
message.) Because of this, the following description is
developed from manual inspections and may be more subject to error than would usually
be the case.]
Account Relationship(API name
Interaccount_Relationship__c)
Account_Relationship__c)
NOTE: confusing collision of this API name with the label
applied to
the Interaccount_Relationship__c
object.
Contact Relationship(API name
Contact_Relationship__C)
ONEN_Household__c)
OppPayment__c)
[If an uninstall
is required, these fields and associated
data will likely be removed. Export of those data and updates after a reinstall
may be required.]
[If custom objects are provided with the package, this
may mean that a required uninstall
action would also require
export of records from these objects prior to the uninstall and reloading of
that data when the package is later reinstalled.]
Account Relationship(API name
Interaccount_Relationship__c)
Account to Contact Relationship(API name
Account_Relationship__c)
NOTE: confusing collision of this API name with the label
applied
to the Interaccount_Relationship__c
object.
Contact Relationship(API name
Contact_Relationship__C)
ONEN_Household__c)
OppPayment__c)
[May be helpful to list any standard objects on which record types are defined.]
Few or none appears to be provided with these packages.
(none _clearly_ identified as belonging to these packages)
(none _clearly_ identified as belonging to these packages)
Several are present. Naming conventions do not make the determination of whether workflow rules are from ONEN easy. Exact count would require examination and interpretation and was not undertaken.
The AMC utility is stated to require that no additional automation should execute during AMC operation.
Any package automation (Apex triggers, workflow rules, or validation rules) that execute in these situations may cause problems:
(The list of package components provided above uses blue-colored text for components types that might present problems.)
[(LB) - The publisher was not contacted about problems encountered with NPSP V3 install and/or use of the AMC utility while this package is installed. Package components did not appear to suggest problems.]
[(LB) - Because there is no populated NPSP Household
object present, use of the AMC utility does nothing. All manipulations that would
be performed by the AMC utility when starting from an earlier NPSP version must
be performed by custom transformation, record creation, and record updates.]
[(LB) - No discussions on Power of Us Hub or elsewhere were sought for information about problems encountered during NPSP V3 installation or related data processing. Package components did not appear to suggest problems.]
[(LB) - Direct discussions with former Groundwire employee Dave
Manelski on Power of Us Hub indicated that these packages may provide functions
not provided by NPSP V3. As a result, there is a possibility that a
client examining database functions after NPSP V3 conversion will identify a
need for retention of GW Base
functions that would require Apex coding
work for revision of ONE/Northwest code.]
Regarding configuration of this package during NPSP V3 installation and use of the AMC utility...
[LB - The AMC utility can not be used to benefit, unless the developer specifically loads the NPSP Households object with records previously stored in the ONEN_Households__c object. (NOTE: This approach is hypothetical and has not actually been tested.) Unless a transfer of records from ONEN to NPSP Households object is employed, custom data transformation, record creation and record updates will be required.]
[LB - My educated guess is that much of the Apex code must be
disabled during custom data manipulations required for conversion to NPSP V3.
For an overview of data transformations needed, see the Sandbox Data Loading
section below.]
Package automation that creates records in response to record insertions may create records that are not derived from the data source.
This may be important if users intend to use the sandbox for a complete
review and validation of post-conversion functionality. Especially if users
will expect to see an exact and accurate representation of records from
the source database (usually the production
instance) within the sandbox
This may not be important if the sandbox is used only to verify
correct conversion of data to a new account model (such as the new NPSP V3
household
account model), and if the sandbox will not be expected to
contain an overall faithful representation of data from the source database.
If package automation does not create new records within key objects being
handled by the AMC utility, data transfers undertaken solely to create an
NPSP V3 data processing test
environment, data transferred to the sandbox
should be acceptable for the intended uses.
The AMC utility works with records in these objects:
If the database is being converted from one-2-one or bucket to the
new household
account model, new Account records will be created
to represent NPSP Household records already present in the instance.
Contacts linkages to Accounts may be updated.
Linkage of Opportunities to Accounts may be updated.
Linkage of Tasks to Accounts may be updated
.[(LB) - The publisher was not contacted
about problems encountered during data loading with this package installed,
since GroundWire/ONEN is no longer in business. However, discussions with
former Groundwire/ONEN employee Dave Manelski were initiated for high level
overview
type information about conversion with these packages in place,
however.]
[(LB) - No discussions on Power of Us Hub
or elsewhere were started to seek input about problems encountered with sandbox
data loading (One on one Hub discussion with former ONEN/Groundwire employee
Dave Manelski). Some functions provided with GW Base
packages are not
duplicated by NPSP and custom Apex work may be required if the organization
wishes to maintain these functions after NPSP V3 conversion.]
Account Model Conversionutility:
Data held in these objects will _*not*_ be handled by the SF Account Model
Conversion
utility due to the complete absence of records in the NPSP
Households
object (API name npo02__Households__c
) - the ONE/Northwest
object used for similar functions is named differently (API name
ONEN_Households__c
). The AMC utility will not detect records
in the ONEN object as source records for AMC operations.
Data processing to convert ONEN data in these objects will need to employ custom data transformation/update/loading steps to perform functions that would otherwise be performed by the AMC utility.
(No equivalent Account->Account "association" object is provided by NPSP.)
(Data will need to be transformed to NPSP "Affiliation" records.)
(Data will need to be transformed to NPSP "Relationship" records.)
(Data will need to be transformed to NPSP "Household" records.)
(Data will need to be transformed to NPSP "Payment" records.)
The packages examined were generally unmanaged
and installed
in 2010. Because they are unmanaged, it is possible to disable many of the
provided Apex classes and triggers using an Eclipse project. However, a number of
complexities are involved:
commentingof Apex code within class definitions:
Most ONEN packages will readily allow this.
However, some packages make regular use of multi-line commenting
for function descriptions and for seemingly temporary code fixes which
were never later converted to more desirable single line
commenting.
Efforts to comment out
Apex code therefore sometimes requires a relatively
detailed examination of ONEN code to determine the proper locations for
start/end points of newly entered multi-line commenting used to completely
disable Apex code.
batchprocess functions generally did not allow use of
commenting outof Apex code to completely disable this code.
Efforts to comment out
Apex code in these classes generally resulted
in an error indicating Save error: ...Class must implement the global
interface method: Iterable<SObject> start(Database.BatchableContext)
from Database.Batchable<SObject>
Dependencies of these classes were such that it was possible to completely delete them without causing problems in other ONEN classes/triggers:
commented outto allow deployment test
code coverageresults that allow deployment of the revised triggers/classes to the
productioninstance.
If the only action taken is to set these triggers to inactive
, the
code still remains and will seemingly be tested for code coverage and assertion
errors before a code deployment to the production
instance is allowed
If Apex trigger code is completely commented out
to disable it, it may
be that setting triggers to inactive
is not needed. But I took the
extra step of inactivating even completely commented triggers, just to be on
the safe side
A number of VisualForce pages from ONE/Northwest are also present.
It might be good form
to remove many of these from the instance just to
avoid any chance of later inappropriate
uses:
[(LB) - My educated guess is that special
data loading steps must be taken for loading of sandboxes with the Groundwire
GW Base/Template
packages installed, as outlined under User Input
just above.]