Really, if someone could reply to this, even to inform me that I should fill 
out a feature request, that would be helpful.  To restate, with goofy diagrams, 
what I was expecting:

Article Class:  PJM
Article Class:  QA
Article Class:  Ops (group perms set here)
                        |---Topic: Systems
                                |---Sub-Topic: Monitoring Services
                                |       |---Article: Introduction (Textbox)
                                |       |---Article: How to request (Textbox, 
linktoform)
                                |---Sub-Topic: Hosts
                                        |---Sub-Topic: BKP01
                                                |---Article: HostManifest 
(Textbox, IP, and stat fields)
                                                |---Article: HostWarranty 
(contacts, s/n and date fields)
                                                |---Article: HostServices 
(Various svc fields, SLA links)

How it works so far, where it appears [toplevel Topic] = [Class] = [sole 
Article Format]:
Article Class:  PJM
Article Class:  QA
Article Class:  Ops (group perms set here, and article format limited to one 
type per CLASS)
                        |---Topic: Systems
                                |---Sub-Topic: Monitoring Services
                                |       |---Article: Introduction (Textbox)
                                |       |---Article: How to request (Textbox)
                                |---Sub-Topic: Hosts
                                        |---Sub-Topic: BKP01
                                                |---Article: HostManifest 
(Textbox)
                                                |---Article: HostWarranty 
(Textbox)
                                                |---Article: HostServices 
(Textbox)

I hope this makes my dilemma a bit clearer.  If we want multiple formats, then 
we need multiple toplevel Topics?

I expected to differentiate formats of articles under sub-topics.  If my 
expectations were out of line, then I'd appreciate a reply from someone about 
how it is intended to be done, as the documentation on 4.0.5 article creation 
doesn't really go into this.

My other option would be to fill up the Article Topic toplevel with all of the 
different article formats I (and others) would wish to use, but then we lose 
the ability for viewers to browse except by article format (and I wouldn't see 
the point of topic trees).  

Most of this article creation is intended to be self-service for multiple 
groups, so I would like to keep it as simple as possible, allowing users within 
their groups to create and format articles specific to sub-topic.


William "Bill" Albertson

-----Original Message-----
From: Albertson, William (Rancho Cordova) 
Sent: Wednesday, May 16, 2012 4:31 PM
To: 'rt-users@lists.bestpractical.com'
Subject: RT4.0.5 article creation- classes and topic nesting

Howdy,

I haven't found a lot of information about creating articles under RT4.0.5 with 
nested topics.  I've recently installed this application, so I'm also not an 
expert.  I'm not sure if I would be better served by instead setting up a wiki, 
and then just linking article items instead.  Here is the problem:

I've created the class "Ops" for articles.  This is the name of our group of 
staff.  We are setting permissions for editing "Ops" related articles here.  
Also, there are other groups to be considered- this installation isn't just for 
"Ops".  There will be other teams with their own articles. 

Next, I created a tree of topics.  Let's say "Systems" and "Networks".

Subtopics under "Systems" are "Hosts", and then other overview topics like 
"Backups".

Under "Hosts" are going to be articles containing host specific info, like a 
manifest article for backupsrv01, and another article for warranty information.

Then I get into article creation.  I created a couple of custom fields called 
"Body" [wikitext] "IP Address" [ip address] and "Attachment" [one upload].

The problem I run into is that RT doesn't seem to differentiate between 
different topic custom fields within a class's sub-topics.  I need to display 
IP address information for "hosts" articles, but don't need to see that field 
for an explanation on our backup system.  Am I putting the cart before the 
horse for managing different article formats?

It seems that the Articles feature of RT is limited to exactly one type of 
article format per class, regardless of how many sub-topics you have underneath 
that class.  From my testing, I would have to create a class for every single 
article format type that I wish to use (host manifest, host warranty, service 
overview would now all be classes), which wouldn't work well with having nested 
topics underneath.  Then, my users would have to search for general keywords, 
because now they would not be able to drill down nested topics easily for topic 
specific information.  Instead of drilling down through "Ops -> Systems -> 
Hosts -> Warranties", they would have to know to select the class "Warranties" 
to browse for host warranties, or know what keywords to search for.  The last 
two options aren't very desirable.

Classes make up the root of Article topic trees, but I can't customize articles 
in topic sub-trees.  That seems very wasteful, so I'm guessing that I'm missing 
something here.  I looked up templates, but that seems to be related to ticket 
fields (see, I'm an RT novice here, really).

As I've read what few docs there are for the RT4.0.5 Articles feature, I would 
appreciate a kind explanation on how article forms, custom fields and topic 
nesting are *intended* to work.  At this point, I'm not sure if I need to 
either completely change how I am structuring articles in RT, or I if I should 
instead install a wiki/dms and point topic related article related items to 
that as links.

 
William "Bill" Albertson


Information in this email and any attachments is confidential and
intended solely for the use of the individual(s) to whom it is addressed
or otherwise directed. Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of the Company.
Finally, the recipient should check this email and any attachments for
the presence of viruses. The Company accepts no liability for any damage
caused by any virus transmitted by this email.
All SGS services are rendered in accordance with the applicable SGS
conditions of service available on request and accessible at
http://www.sgs.com/en/Terms-and-Conditions.aspx

Reply via email to