[rt-users] RTFM articles content migration

[Craig Green]

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.
------