Luis Moreno wrote:
Hello RT admins
In the README file is clearly specified the procedure to make an upgrade of
RTFM (2.0.4 to 2.1.40), I ran the script rt-setup-database without any
trouble. The custom fields for the content were created too and assigned to
the article classes, but the articles content is still empty. Looking at the
database, the “old” articles content is in a table called
fm_articlecfvalues.
Are you certain you assigned the custom field to article classes? I’ve
still got the old article content in FM_ArticleCFValues, too, but the
data has been copied into ObjectCustomFieldValues and FM_ArticleCFValues
doesn’t update when I modify the content text while
ObjectCustomFieldValues does.
I ask because I actually just ran into this today and that was the
issue. I ran the migrate-2.0-to-2.1 script, did the DB schema etc.
updates, installed 2.2.0RC4 and restarted the webserver. Browsing to
RTFM shows the articles, but doesn’t display the actual contents of the
articles, though it does show up in the history. Trying to create a new
article shows a page with no text entry field to actually enter the
article body. There are a couple or three posts on the list about this,
but I didn’t see any actual answers other than “re-enter all the
articles manually”, which wasn’t quite the answer I was hoping for.
Anyway, after the usual cursing, swearing and futzing around, I did
finally get the content to display. The problem was that the Body, the
first custom field, exists, but isn’t assigned to any RTFM article classes.
In the web interface, I went to RTFM / Configuration / Custom Fields,
then selected the body CF. At this point I was at the “Editing
CustomField Body” page. I clicked on the “Applies To” link, and nothing
was selected.
My first go 'round I discounted this screen because the objects I could
select were “Support”, “Accounts”, “Abuse”, etc. – basically my RT
Queues – and I’m thinking that, no, this custom field shouldn’t apply
to my queues and so left it alone (i.e. with the CF applying to nothing).
Next time I visited the screen, in desperation I clicked the “Check All”
button and Submitted, figuring I could always just undo it if I screwed
it up. However, when I left the RTFM config and viewed my articles, the
content now showed up. At this point, after a bit of furrowed brow
thinking, I realized that “Support” and so on are my RT Queues, but
they’re also the names of my RTFM article classes, and since the Body CF
is now associated with all articles (since I applied the CF to all
article classes), the contents of the Body CF is now displayed and
available when I view the article. A blank text entry field also shows
up when I go to create a new article.
'Course I’m no RT expert and said explanation of why it now works may
actually be worth rather less than an equivalent volume of raw sewage,
but the content of my articles now display anyway so I’m happy. That’s
how I fixed it–YMMV. 
Note to Jesse et al: besides the obvious README documentation updates,
I’m pretty certain that the migrate-2.0-to-2.1 should do the SQL
equivalent of the above automatically. Other custom fields may only
belong to certain article classes, but in the old RTFM if I’m not
mistaken (again, not an expert) every article has a body, and so the
Body CF should be applied to all classes. Basically, the CF to article
class associations should be migrated by the script just as whatever
else the script migrates is migrated.
Having the Body CF present but not applied to anything and thence not
showing up at all is rather confusing, unfairly making ops doubt their
ability to comprehend simple English and/or follow a simple 5-step set
of instructions.
Oh, and an unrelated note: the docs also assume you’re upgrading RTFM in
place. I’m actually doing a fresh RT and RTFM install on a new, beefier
server, with just the DB copied over from the old server.
The migrate-2.0-to-2.1 script, however, relies on files only present in
the old version of RTFM. The script, therefore, immediately quit,
complaining about a missing module. The usual cursing, swearing and a
few find commands later and I located the missing Perl module on the old
server. I then recognized the assumption made by the devs, tar’d up and
dropped the old RTFM files into the appropriate place on the new server,
and then the script decided to run.
Well, only about halfway, actually–it bombed out complaining about an
undefined function ‘new’ in RT::FM::TransactionCollection blah blah.
This one was pretty easy: adding ‘use RT::FM::TransactionCollection;’
at the top of the script cured that, once I verified
RT::FM::TransactionCollection had actually been copied over in my
tarball of the old server’s RTFM.
All in all, it was a bit of an adventure, but the new server’s working
and holding up under light testing. Weekend, here I come… 
Cheers,
Craig.