The review package does not belong in this project.

[vrouse]

Is there a solution for this error? Trying to collaborate with multiple authors, but we do not have access to shared network (which I suspect might be the problem)? Projects on both ends are set up identically (except complete path name -- project name, file/folder structure all the same. Any advice appreciated. Thank you.

[Msquared]

I have just got this error too, and I've raised a support case. I'll keep you posted on the reply. I think you're right about it being a multiple author issue in your case.

In my case, it happened when I moved my entire Flare project structure elsewhere because our developers needed the Flare content structured slightly differently for including with other documentation on the product CD. We work within a source control system, integrated with Flare (although not terribly well, but that's another story). I have got exactly the files that Flare wanted to put under source control (that is, almost everything below the Contents and Project folders). I checked everything back in, moved my entire folder structure using our source control system as I have done many times before, then checked it all back out again. In the process I suspect I lost an internal file that Flare created to maintain the review history. I think I have seen this file before, and noted that it was created in a location that isn't under source control, and, if I remember correctly, was under the project but in an area under my own user name. I idly wondered about the consequences of losing this and now I know!

The documentation says "Note: If you send out review packages and then rename the project, you will receive an error stating that the package does not belong to the project when you attempt to import those review packages." It doesn't tell you what to do to fix it though, and it doesn't sound as though either of us have renamed a project.

As I said, I have raised a support case. I assume they are going to tell me to make sure I keep hold of some file or other, or at least give me enough information about what to hack to fix the problem.

[techwriterkai]

I've gotten the following workaround to work for me. I have no comment from MadCap whether it's recommended or dangerous.

The point is that review packages are tied to a local copy of a project.

Here's what I did:
1. Save the review package locally and rename the file extension .fltrev to .zip.
2. Unzip the package and open the contained _Meta.xml file in a text editor.
3. Find the SourceProject attribute in the MadCapFilePackage tag and edit it to reflect the current location of the corresponding local project copy, e.g., C:/Users/MyUser/Documents/My Projects/MyProject.flprj
4. Save _Meta.xml, add the edited _Meta.xml to the zipped package and rename the extension from .zip to .fltrev.
5. Proceed to open the package in Flare as usual.

[Msquared]

Oh hello Kai!

I tried coming at it from the other side, and creating an identical review package in the new location, then importing the old one back in. No joy. So I came to the conclusion that the link was on both sides, with the project "knowing" that the review package had been created and the review package "knowing" what project it belongs to.

When you create a review package in your project, Flare creates a file in Project\Users\<yourusername> called SentItems.mcsent (or adds the review package topics to it if it already exists). This file isn't in an area that is under CM control. However, if you delete this file or some of the entries in it, you can still import the reviewed review package - you just lose the record of what you sent - I've just tried it. So that end of the link doesn't matter too much.

To come back to the original problem, looking at what Kai says, the name of the project that created it is stored in the review as an absolute file path. So the way vrouse works will mean that his/her colleagues will need to use an indentical folder structure and drive mapping (and definitely not a location specific to their user name). Otherwise they will have to do Kai's file hack.

I noticed that the review package was a binary file. I didn't know it was really a zip file. That has made my day. I'm off to unzip some review packages!

Do you know that in Flare 8 you can create a review package from the TOC? I love that feature! It's so much nicer for the reviewers to understand.

Marjorie

[Msquared]

I've now had the official response from MadCap. It is:

The path for the created review package has changed since the project has been moved. You can update the path of the *.fltrev file by following the steps below:

1. Change the file extension of the [your_filename].fltrev file to [your_filename].zip 2. Unzip the [your_filename].zip file 3. Open the _Meta.xml file contained in the folder with Notepad 4. Update the path of the SourceProject link to the new path of the project. (please see attached Capture.PNG) 5. Save the file 6. Re-zip the file 7. Re-name the [your_filename].zip file extension to [your_filename].fltrev

I'm going to suggest that they save themselves some support time and include this workaround in their documentation (which only refers to the effects of changing the project name, not the path). Better still, I'll submit a fetaure request for a utility to update the project location where necessary. This is an issue for people who work like vrouse's team, as well as those who have content under source control, where it is very likely that your workspace won't have an identical path name to anyone else's.

Incidentally, while we are on the subject of sharing files around, I have already reported similar issues with other hard-coded file paths in Flare. I think the location of globally linked projects is another that is stored as an absolute path. That means that my company can't auto-build my documentation with the software, including getting the latest from the globally-linked project. That would be wonderful, but can't happen so long as the path to the globally linked project is stored as an absolute file name on my personal PC.