Dealing with “The review package does not belong to this project” error in MadCap Flare

MadCap Flare allows you to create a review package containing topics and snippets and share it with reviewers for their feedback and changes. The reviewers’ changes are automatically tracked, so you can easily see which parts of your content they modified.

After reviewers insert comments or make changes to the files in a review package with Flare or with Contributor (for non-Flare users), they can send the package back to you. You can then import the reviewed files (topics and snippets) into your project. The files will appear in the inbox of the File Reviews window pane. After that, you can view, reject and accept changes.

The entire process is quite simple. But you may come across an issue with importing a review package, especially if you work in a team of Tech Writers where you often swap projects.

Package error in MadCap Flare. What’s the problem?

If you send out a review package and then move or rename the project from which you created the package, you won’t be able to import the package back into the project. You will get an error message saying that the package doesn’t belong to the project.

Why is this happening?

The project path is hardcoded in the review package. Flare checks this path while importing a review package. If you move or rename the project, the path in the review package becomes obsolete and Flare gets stuck.

How to fix the Package Error in MadCap Flare?

You have two options to deal with this problem. Let’s check out how to fix the package error in MadCap Flare.

Option 1 – Revert the project to the original state

The first solution is to revert the project name and path to the values that were used back when you created the review package. It’s a rather easy task when you’re the person who prepared the review package. But if someone else did it and left the company in the meantime, you’re cooked. It’s hard to guess where this person stored their project when they created the review package. If this is the case, try option 2.

Option 2 – Use a workaround

If you don’t know the original name and location of the project, you can try a workaround. You’d better roll up your sleeves because you’ll have to dig in the file code. But don’t worry too much. Just follow the steps below carefully, and you should be good to go in less than 15 minutes.

• Go to the location where you keep the review package.
• Change the extension of the review package from FLTREV to ZIP.

If you can’t see the extension of the review package, it means that your Windows hides extensions for known file types. To change this setting in the Windows Explorer:

• Extract the package with the modified extension, for example, using the 7-Zip application.

• Open the extracted folder (not the zipped folder) and then open the _Meta.xml file in a text editor, like Notepad++. It’s best to use a simple text editor, because it won’t add any unwanted characters to the file code.
  

• Look for the original location of the Flare project in the SourceProject property and change it to the correct location of the Flare project on your machine. Please note that the path uses “/” (forward slash) and that the file:/// part is required.
  

• Save changes and close the file.
• Select all the files and folders within the extracted folder and compress them to a ZIP archive.

• Change the extension of the new zipped folder from ZIP to FLTREV.

You can now import the review package into the Flare project.

How to avoid the review package error in the future?

The only way (that we know of) is to create an internal company policy that requires everyone to store their Flare projects in the same location. For example, you can ask authors to have the FlareProjects folder on the C: drive where they check out all the Flare projects from the source control. You can also create a naming convention for local project folders, like using underscores instead of spaces and lowercase. This solution is easy to implement, but it may be hard to maintain, especially if you have a big team of Tech Writers working on multiple projects.