yippie / salesforce-renamer Goto Github PK

Renaming custom setting objects fails.

Logs are printed in XML currently, this is hard to read. Change the printing to a traditional timestamped log where each row is a message.

In an org where a managed package is being developed (an org that has a namespace) nothing gets downloaded in the zips and nothing gets renamed.

In order to prevent the application from trying to edit/rename code in a managed package where you are not allowed to, the Salesforce Renamer ignores everything with a namespace.

The fix is to detect the Organization local namespace and allow only that namespace.

If a relationship name for a Lookup is not the same as the object name being renamed, the relationship name will not change.

Two options to fix this:

1. Do not rename relationship names
2. Add ability to specify relationship renames as an additional object type along with CustomObject and CustomField.

Fields with the same API Names as other fields cause issues when deploying the renamed code.

This is caused by doing a simple find and replace in the code. Using an intelligent parser to determine the field parent object before renaming in the code would fix this.

When manually editing the deploy package to fix issues it unzips as a generic "unpackaged" folder and must be zipped up and renamed before it can be deployed again.

REQUEST: Add functionality to extract all zip deployment packages to nicely named folders and then automatically re-package them before deploy.

Do not require settings.properties to exist on startup. Instead detect if it exists. If it does, use it. If it doesn't prompt for credentials, ask if it is ok to save them, and then create the settings.properties file with the defaults.

The revert doesn't work correctly, especially if there are partial successes.

Things to fix:

• Deploy the empty code again before renaming back
• Renaming back needs to be done in the opposite order (objects first, then fields) than the normal renaming
• Deploy backup at the end, even if some renaming failed.

Currently, you must compile and run the app yourself. Each version should have a pre-compiled executable for both Windows and Mac that can be run on the command line.

Currently the java -jar method works but it would be nice to have something that is self running.