A new design question

RT Developers
1

What is the possibility and the impact of developing a new kind of
customization system to RT, where each queue or other bigger unit is a
directory and, inside each directory, we have sub-directories for custom
fields, scripts, templates, etc.
Doing the thing in this way the database will be really a data
repository and the code will be only into the files.

Follow an example direcotry structure:

  • Customizations
  • Queues
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Global
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Users
  • user1.usr
  • user2.usr
  • user3.usr
  • Groups
  • group1.grp
  • group2.grp

This is a little idea. I felt the dificult of transport the code (local
directory) and the scrips, etc from the development server to the
production server, where I had to dump the database without touching the
tickets and other vital data of the customer. Maybe leaving the code in
the files, inside the RT directory structure, would be a nice start.

Does anyone have an idea of the impact or how to refine this scructure?

Yours truly,

Lucas F. Rosada
lucas@dextra.com.br

Dextra Sistemas
+55 (19) 3256 6722
http://www.dextra.com.br

PS.: If you don’t understand my english don’t matter, I’m not fluent and I can try explaining again. :wink:

2

What is the possibility and the impact of developing a new kind of
customization system to RT, where each queue or other bigger unit is a
directory and, inside each directory, we have sub-directories for custom
fields, scripts, templates, etc.
Doing the thing in this way the database will be really a data
repository and the code will be only into the files.

Follow an example direcotry structure:

  • Customizations
  • Queues
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Global
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Users
  • user1.usr
  • user2.usr
  • user3.usr
  • Groups
  • group1.grp
  • group2.grp

This is a little idea. I felt the dificult of transport the code (local
directory) and the scrips, etc from the development server to the
production server, where I had to dump the database without touching the
tickets and other vital data of the customer. Maybe leaving the code in
the files, inside the RT directory structure, would be a nice start.

Does anyone have an idea of the impact or how to refine this scructure?

The only problem you mention with the current system is the work
it takes to move customizations from development to production.

I think it would be better to develop code that uses the API to
make this easier than to redesign RT.

-Todd

3

Todd,

I'm not criticizing RT structure, quite to the contrary, it was the

best on which I developed! But I think that the model of code into the
database, although to be practical when developing scrips, templates,
etc into the web interface, it is more usual develop code inside an IDE
or any other editor.
A second problem consist in the maintenance of the quoted resources
(scripts, etc): for each code that lives into the database you want to
change, you have to wait the webserver response and, when the page
arrives, there isn’t any practicity to alter the code.
Another benefit to us, developers: we could keep our customizations
fully into a CVS repository!

RT is an success system for its users but, on the other hand, there

is few confort to the developer to extend it and give continuity to the
project.

The RT idealizers may think: "Oh, God! This guy is trying to change

the way RT do the thinks!", but, because it’s an free software and it is
always in develpment and perfectioning state, threat these thread as one
informal conversation about software structure and how could apply these
techniches and improvements to RT, making it each time better!

Regards,

Lucas F. Rosada
lucas@dextra.com.br

Dextra Sistemas
+55 (19) 3256 6722
http://www.dextra.com.br

Todd Chapman wrote:>On Mon, Mar 21, 2005 at 03:28:44PM -0300, Lucas F. Rosada wrote:

What is the possibility and the impact of developing a new kind of
customization system to RT, where each queue or other bigger unit is a
directory and, inside each directory, we have sub-directories for custom
fields, scripts, templates, etc.
Doing the thing in this way the database will be really a data
repository and the code will be only into the files.

Follow an example direcotry structure:

  • Customizations
  • Queues
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Global
  • DelegatedRights.cfg
  • Scrips
  • scrip1.scp
  • scrip2.scp …
  • Templates
  • template1.tmpl
  • template2.tmpl …
  • Custom Fields
  • CF1.cf
  • CF2.cf
  • Users
  • user1.usr
  • user2.usr
  • user3.usr
  • Groups
  • group1.grp
  • group2.grp

This is a little idea. I felt the dificult of transport the code (local
directory) and the scrips, etc from the development server to the
production server, where I had to dump the database without touching the
tickets and other vital data of the customer. Maybe leaving the code in
the files, inside the RT directory structure, would be a nice start.

Does anyone have an idea of the impact or how to refine this scructure?

The only problem you mention with the current system is the work
it takes to move customizations from development to production.

I think it would be better to develop code that uses the API to
make this easier than to redesign RT.

-Todd

4

Lucas F. Rosada wrote:

Todd,

I'm not criticizing RT structure, quite to the contrary, it was

the best on which I developed! But I think that the model of code into
the database, although to be practical when developing scrips,
templates, etc into the web interface, it is more usual develop code
inside an IDE or any other editor.
A second problem consist in the maintenance of the quoted
resources (scripts, etc): for each code that lives into the database
you want to change, you have to wait the webserver response and, when
the page arrives, there isn’t any practicity to alter the code.
Another benefit to us, developers: we could keep our
customizations fully into a CVS repository!

RT is an success system for its users but, on the other hand,

there is few confort to the developer to extend it and give continuity
to the project.

A quick scan of the rt-devel and rt-users list would seem to suggest
otherwise. I suggest looking at
Carbon60: Managed Cloud Services to see how much
continuity there is to the project.

The RT idealizers may think: "Oh, God! This guy is trying to

change the way RT do the thinks!", but, because it’s an free software
and it is always in develpment and perfectioning state, threat these
thread as one informal conversation about software structure and how
could apply these techniches and improvements to RT, making it each
time better!

And on that note, you are free to do just these things and submit your
ideas back to Jesse to see what he thinks. From everything I’ve seen on
here, he is always receptive to ideas, patches, and other contributions.

So if you get something working that you think accomplishes the task a
little better, send it in.

Regards,

–
Lucas F. Rosada
lucas@dextra.com.br

Dextra Sistemas
+55 (19) 3256 6722
http://www.dextra.com.br

DB

5

Todd,

I’m not criticizing RT structure, quite to the contrary, it was the
best on which I developed! But I think that the model of code into the
database, although to be practical when developing scrips, templates,
etc into the web interface, it is more usual develop code inside an IDE
or any other editor.
A second problem consist in the maintenance of the quoted resources
(scripts, etc): for each code that lives into the database you want to
change, you have to wait the webserver response and, when the page
arrives, there isn’t any practicity to alter the code.
Another benefit to us, developers: we could keep our customizations
fully into a CVS repository!

RT is an success system for its users but, on the other hand, there
is few confort to the developer to extend it and give continuity to the
project.

The RT idealizers may think: “Oh, God! This guy is trying to change
the way RT do the thinks!”, but, because it’s an free software and it is
always in develpment and perfectioning state, threat these thread as one
informal conversation about software structure and how could apply these
techniches and improvements to RT, making it each time better!

You can do all the things you want with RT as it is. You
are looking at the web interface when you should be digging
into the code. You can keep your code in CVS, update it
in the database. Test using RT API scripts (not scrips). The
debugger is there for you.

The web interface stuff was developed to make RT customization
easier for the non-developer, but the API can be used to do
those same things.

-Todd