Admin ticket assignment depending on date

Hello,

What would be the best way to setup automatic
assignment to tickets that were created through
email, sent to the general queue?

For example if I issue the following command:
“/usr/local/rt2/bin/rt-mailgate general correspond <
/tmp/simple.mail.file” The ticket gets assigned to
“Nobody”, in the general queue. What file would I
look into to edit to whom the ticket gets assinged?
The reason is that we rotate who is “oncall” on a
weekly basis, and it would be great if the tickets
can be assigned to the oncall person, instead of just
nobody.

                          Thanks

Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax

What would be the best way to setup automatic
assignment to tickets that were created through
email, sent to the general queue?

There are three methods. The first one is to use the existing
RT::Action::AutoAssign scrip which Feargal wrote
(http://www.fsck.com/pub/rt/contrib/2.0). This assigns it to a random
person.

The second one is to use the RT::Action::AutoTake scrip which I sent to
rt-devel a few moments ago (with the incorrect name the first time).
This effectively gives the Ticket to the first privileged user who voices
an opinion about the Ticket.

The third solution is to write your own varient, possibly starting with
the AutoAssign and making it read a file to get the name of the user to
assign it to.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Hi,

I’m a long time Req user from a previous life (including implementing
my own multi-queue extensions and whatnots) but I have not used RT2
before. RT looks very nice (especially to someone with too much
exposure to Req internals, shudder).

However, I do have two questions for non-standard use that would be
extremely useful to me/us.

  1. We are not a typical helpdesk. Instead we have a mix of internal
    issues, tech development, planning and customer promblems. And I
    want to funnel it all into RT.

    To make things worse, we are not always in one place. We travel, we
    lose Internet connectivity (typically in hotel rooms, airports,
    etc). At the same time such (disconnected) occasions are often the
    best to get things off your personal list of things to do.

    So what I would like to do is run RT on top of a replicated MySQL
    db with slave replicas in our laptops. I fully realize that I
    should restrict myself to read-only access to the replica, and any
    writes while disconnected had better be done via an email-updater
    (possibly enhanced-mailgate that I found in the contrib area).

    Is this idea a strong indication of someone either finally going
    bonkers or at least trying to fit a square nail into a triangular
    hole? Or would it be possible to make this work in a reasonable
    fashion? Anyone tried anything like that?

  2. Many tickets in my environment have a tendency of forking new
    "sub-tickets". I.e. the original issue stalls on identified
    subproblems and the dependency fields seem great to express this.

    However, I have not found any functionality to get an overview of
    the resulting dependency graph. This is the type of functionality
    that is traditionally found in project management systems, and I
    agree that it is possibly a little bit out of the main stream
    trouble ticket business.

    But it would be incredibly useful for people like me that have very
    convoluted dependencies and a need both to keep track of this for
    oneself and to communicate the dependencies to others, preferably
    visually.

    It would be possible to implement this outside of RT, just working
    from the raw MySQL data, but I think it would be much nicer to have
    it within the RT framework. Has anyone seen any tools doing
    anything like this anywhere close to RT?

Regards,

Johan Ihr�n
Autonomica

Johan,

I’ve got nothing on number 1.

For number 2, however, you may be interested in looking at the DTRT
stuff in the contrib/rt-addons area. More specifically:
http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/DTRT . This is some
work Jesse has done on a project management interface/extension to
RT2. Although it’s not exactly what you’re looking for, I’ve used it
as a great starting point to build an interface that lists all the
requests in a queue that are of “type” ‘project’ (as opposed to
’ticket’) and then show the children of each of those 'project’
requests. Jesse already has the part done to display one at a time, I
just had to modify it a little bit to get exactly what I want.

However, there isn’t any act-or-restrict-based-on-dependency
functionality in RT2.0, as far as I know. So, you may be able to view
your dependencies for a ticket in hierarchical fashion, but without
extending RT2.0 you won’t be able to say "don’t resolve a ticket
dependent on another unless the depended-upon ticket is also resolved"
or anything like that. But, if your group is relatively good at
following business rules, that may not be an issue.

Jesse has said that RT2.2 will have some workflow enhancements. It may
be that RT2.2 will have exactly what you’re looking for, but I’m not
sure about that.

Let me know if any of this doesn’t make sense or if you would like
additional information on my experiences playing around with DTRT and
so forth. And my apologies in advance if I’ve misrepresented anyone or
anything in this email. :slight_smile:

Matt

Ihren writes:

Matt Disney matthew.disney@fedex.com writes:

Matt,

I’ve got nothing on number 1.

Fair enough. If I get around to it I promise to let you all know
exactly how bad idea it was :wink:

For number 2, however, you may be interested in looking at the DTRT
stuff in the contrib/rt-addons area. More specifically:
http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/DTRT . This is some
work Jesse has done on a project management interface/extension to
RT2. Although it’s not exactly what you’re looking for, I’ve used it

Aha, great. I didn’t notice that one.

as a great starting point to build an interface that lists all the
requests in a queue that are of “type” ‘project’ (as opposed to
’ticket’) and then show the children of each of those 'project’
requests. Jesse already has the part done to display one at a time, I
just had to modify it a little bit to get exactly what I want.

However, there isn’t any act-or-restrict-based-on-dependency
functionality in RT2.0, as far as I know. So, you may be able to view
your dependencies for a ticket in hierarchical fashion, but without
extending RT2.0 you won’t be able to say "don’t resolve a ticket
dependent on another unless the depended-upon ticket is also resolved"
or anything like that. But, if your group is relatively good at
following business rules, that may not be an issue.

It isn’t, but I agree that is an important concern to be aware of.

Jesse has said that RT2.2 will have some workflow enhancements. It may
be that RT2.2 will have exactly what you’re looking for, but I’m not
sure about that.

Let me know if any of this doesn’t make sense or if you would like
additional information on my experiences playing around with DTRT and
so forth. And my apologies in advance if I’ve misrepresented anyone or
anything in this email. :slight_smile:

I found zero documentation on DTRT (in fact, the only thing I found
was other people asking for help with installation). So any
information on how you set it up would be very much appreciated.

Regards,

Johan Ihr�n
Autonomica

Johan Ihren writes:

I found zero documentation on DTRT (in fact, the only thing I found
was other people asking for help with installation). So any
information on how you set it up would be very much appreciated.

Ok, so there are four directories in
http://fsck.com/pub/rt/contrib/2.0/rt-addons/DTRT/

at the time I’m writing this email. They are: Elements, Scheduler,
html, and lib.

  1. Take everything in the “lib” directory and put it in your
    $PATH_TO_RT/lib directory.
  2. Take everything in the “html” directory and put it in your
    $PATH_TO_RT/WebRT/html directory (or the equivalent using
    multiple HTML::Mason component roots).

I think that’s all I did. I believe everything in Elements is
either superfluous or unnecessary for core functionality. And I
don’t know what the Scheduler stuff is.

Let me know if there is anything else you find out or any additional
questions I can answer.

Matt

Matt Disney matthew.disney@fedex.com writes:

Johan Ihren writes:

I found zero documentation on DTRT (in fact, the only thing I found
was other people asking for help with installation). So any
information on how you set it up would be very much appreciated.

Ok, so there are four directories in
http://fsck.com/pub/rt/contrib/2.0/rt-addons/DTRT/

at the time I’m writing this email. They are: Elements, Scheduler,
html, and lib.

  1. Take everything in the “lib” directory and put it in your
    $PATH_TO_RT/lib directory.
  2. Take everything in the “html” directory and put it in your
    $PATH_TO_RT/WebRT/html directory (or the equivalent using
    multiple HTML::Mason component roots).

I think that’s all I did. I believe everything in Elements is
either superfluous or unnecessary for core functionality. And I
don’t know what the Scheduler stuff is.

Nope, didn’t work. I get no reference to DTRT whatsoever from the UI
and if I reference directly I get the error “RT Error: No ticket
specified”.

But, since I see references a la “DTRT/Overview.html” in the new
Elements/Tabs I suspect that whatever.html should actually be located
in a subdirectory called “DTRT”, so I shifted everything down one
level into

$PATH_TO_RT/WebRT/html/DTRT/

and that “kind of worked”. I can create tasks and new subtasks and so
on. However, the scheduling seems to get confused by dates that do not
sufficiently overlap:

“RT Error: Something circular going on! There is nothing scheduled for day 1”

Also, I’m unable to get the Gantt chart working, that always ends up
in the following Mason error:

    error in file:  
    /usr/local/vol/rt2/WebRT/data/obj/STANDARD/DTRT/Gantt.html

    line 24: 
    Can't use string ("0") as a HASH ref while "strict refs" in use

    context:  

    ... 
    20: 
    21: my ($calendar, $ticketinfo) =$schedule->Build($id);
    22: 
    23: 
    24: my @dates = sort (keys %{$calendar});
    25: my $last = $dates[0]; 
    26: my @tasks = sort { 
    27: $ticketinfo->{$a}->{'startson'} <=> 
    28: $ticketinfo->{$b}->{'startson'} } 
    ... 

    component stack:  /DTRT/Gantt.html [standard]
                      /autohandler [standard]

    code stack:  /usr/local/vol/rt2/WebRT/data/obj/STANDARD/DTRT/Gantt.html:24
                 /usr/local/vol/rt2/WebRT/data/obj/STANDARD/autohandler:66

Possibly this is triggered by my cavalier attitude towards delivery
dates, but it is still a bug.

It seems like a more or less trivial error, that possibly even I can
figure out if I set my mind to it, but right now I at the level where
I can figure my way around my own perl code, but I’m a bit overwhelmed
by the plethora of strange and mystical perl modules like “Mason” and
whatnots that interact in devious ways in a package like RT.

I think this shows great promise and could be a really great addition
for me. But before achieving that I think that I need

a) a bit more integration. As it is, if I stumble out of DTRT then I
have to know my way back to find it.

b) less focus on dates. I care much more about relationships between
tasks than I care about exact delivery dates. And although I may be
confused by the things I’ve stumbled on it seems to me that the
basis for DTRT structure is time stamps more than relationships.

c) Working Gantt charts.

I don’t really need the scheduling right now. So my next step will be
to go hunting for some spare time. Hopefully I’ll find it in one of my
colleagues offices, because I really don’t have it right here :wink:

Let me know if there is anything else you find out or any additional
questions I can answer.

Question 1: do you have the gantt charts working?

Question 2: in your experience, is it possible to work with DTRT with
focus on relationships between tasks rather than time?

Question 3: have you done any integration work between RT and DTRT?

Thanks for your help getting me this far,

Johan Ihr�n
Autonomica

PS. One really great corner was “MyDay.html”. I think that one alone
will make many people happy if integrated into the base RT package.

So what I would like to do is run RT on top of a replicated MySQL
db with slave replicas in our laptops.
[…]
Is this idea a strong indication of someone either finally going
bonkers or at least trying to fit a square nail into a triangular
hole?

Yes, to both questions. That’s craaazy. Or at least way too much work
for the reward.

How about ssh tunnelling to the RT host and making updates that way; and
putting together a comma-separated table extractor to let people with no
net connection at all view their current work in excel or the like? You
get all the read-only + remote benefits in this scheme, for much less
work.

If you really want what you’re asking for, I’d recommend looking at
disconnected rowsets in Java or C# as a way of getting a database extract,
mucking around with it on a disconnected client, and updating the source
database when connectivity is restored. Still a lot of work, but more
likely to perform than complete replication.

Marc Hedlund
e: marc at precipice dot org

Johan Ihren writes:

Nope, didn’t work. I get no reference to DTRT whatsoever from the UI
and if I reference directly I get the error “RT Error: No ticket
specified”.

But, since I see references a la “DTRT/Overview.html” in the new
Elements/Tabs I suspect that whatever.html should actually be located
in a subdirectory called “DTRT”, so I shifted everything down one
level into

$PATH_TO_RT/WebRT/html/DTRT/

and that “kind of worked”. I can create tasks and new subtasks and so
on.

Ah, yes. That’s actually what I did. Sorry for the poor directions!

I think this shows great promise and could be a really great addition
for me. But before achieving that I think that I need

a) a bit more integration. As it is, if I stumble out of DTRT then I
have to know my way back to find it.

b) less focus on dates. I care much more about relationships between
tasks than I care about exact delivery dates. And although I may be
confused by the things I’ve stumbled on it seems to me that the
basis for DTRT structure is time stamps more than relationships.

c) Working Gantt charts.

That’s reasonable. Keep in mind, though, that this is basically just
contributed work that wasn’t finished. I think this began as a
financially sponsored extension, but then the potential sponsors
disappeared. But that doesn’t mean your requirements are invalid at
all, I just wanted to raise that point to be sure we keep our
expectations in perspective.

Question 1: do you have the gantt charts working?

No, I also experienced the same problems you did. And actually, I’m not
really using the DTRT stuff in a production capacity. But, I soon may
be using my own extensions based on DTRT (merely the hierarchical view
stuff, actually) in production for project management.

Question 2: in your experience, is it possible to work with DTRT with
focus on relationships between tasks rather than time?

Definitely. You can create a page that shows you a task and its
dependencies, but not any of the time data.

Question 3: have you done any integration work between RT and DTRT?

No, and the integration work I do will probably be queue specific. I
doubt I’ll be adding any Tabs or anything like that. It will be more
like “only a couple of people will want this and they will access it
directly via a bookmark”. Basically, we’re going to have a "Projects"
queue that DTRT stuff is applicable for, but otherwise we probably
won’t use it.

I’d be interested to hear what your design goals for RT and project
management would be. Maybe we could work together to iron out some of
the issues we’ve been experiencing with certain DTRT functionality and
then target some of the same goals.

Thanks,
Matt

Marc Hedlund marc@precipice.org writes:

So what I would like to do is run RT on top of a replicated MySQL
db with slave replicas in our laptops.
[…]
Is this idea a strong indication of someone either finally going
bonkers or at least trying to fit a square nail into a triangular
hole?

Yes, to both questions. That’s craaazy. Or at least way too much work
for the reward.

Thank you, sir. I will not deny that you are most probably right here :wink:

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

How about ssh tunnelling to the RT host and making updates that way; and
putting together a comma-separated table extractor to let people with no
net connection at all view their current work in excel or the like? You
get all the read-only + remote benefits in this scheme, for much less
work.

Ssh tunneling: not relevant, if I have net access, then I have net
access. This is for not having net access.

Excel: well, we are not a Windoze persons, we’re Unix people. I have
lots of respect for Excel, which is a fine tool running under the
wrong OS (not a religious point, merely an observation of the
cumbersomness of dualbooting etc).

But why does it have to be more trouble to set up automatic
replication than to muck around with selective extraction into a
different tool? To me it seems like replication is something you get
right once and then it (hopefully) just works, while all kinds of
extraction scripts will just have to be kept forever in sync with RT
changes and will even then only provide a bleak copy of the original
RT environment.

  • I can easily spare a few GB of disk in the laptop if needed (not
    that I think we will get there anytime soon), so space is not the
    issue. Nor is bandwidth when I have connectivity.

  • MySQL, as I understand (I have not tried this) supports replication
    where the slave both changes addresses and just tells the master
    from where to respool the log. In fact, the master doesn’t even
    track the slaves, it just spews out data at clients that provide the
    right credentials regardless of where they are. This is actually the
    main point to me.

  • I would have exactly the same interface to the data locally
    (i.e. the same hierchy of webpages accessible through my browser
    instead of switching to a different tool).

If you really want what you’re asking for, I’d recommend looking at
disconnected rowsets in Java or C# as a way of getting a database
extract, mucking around with it on a disconnected client, and
updating the source database when connectivity is restored. Still a
lot of work, but more likely to perform than complete replication.

I have a lot of respect for the technical problems with replication.
But at the same time one interesting characteristic of a trouble
ticket system is that although we may hug along many thousands of
tickets the “active set” is usually a rather small subset. I.e. most
of the data is static, which very much simplifies replication, given
reasnoably frequent updates (typicall lagging a few days behind, not
weeks or months).

So, you’re probably correct. There are people who claim that my main
purpose in life seems to be having craaazy ideas, and this may be one
of them.

But to become convinced I would like to hear why replication wouldn’t
work in this scenario.

Regards,

Johan

To make things worse, we are not always in one place. We travel, we
lose Internet connectivity (typically in hotel rooms, airports,
etc). At the same time such (disconnected) occasions are often the
best to get things off your personal list of things to do.

So what I would like to do is run RT on top of a replicated MySQL
db with slave replicas in our laptops. I fully realize that I
should restrict myself to read-only access to the replica, and any
writes while disconnected had better be done via an email-updater
(possibly enhanced-mailgate that I found in the contrib area).

Is this idea a strong indication of someone either finally going
bonkers or at least trying to fit a square nail into a triangular
hole? Or would it be possible to make this work in a reasonable
fashion? Anyone tried anything like that?

If you could get this to work (for easy-to-use definitions of work)
and work well, you could sell RT2 implementations all over the world for
many many dollars. Companies all over are dying for this sort of a
thing for their sales crew to be able to use. Look at the CRM field,
and note that there are offerings there from everyone and their brother,
and at ridiculous costs as well.

When I was at VA Linux Systems, they needed disconnected functionality
(with auto-updates with re-connect) for their CRM. I thought that the
convolutions were amazing to see, it was so important to the sales guys.

With disconnected operations, how do you create a new ticket? Have my
userid in the name of it? I don’t know, myself, I haven’t put that much
brainpower into it.

rob

Matt Disney matthew.disney@fedex.com writes:

Johan Ihren writes:

Nope, didn’t work. I get no reference to DTRT whatsoever from the UI
and if I reference directly I get the error “RT Error: No ticket
specified”.

But, since I see references a la “DTRT/Overview.html” in the new
Elements/Tabs I suspect that whatever.html should actually be located
in a subdirectory called “DTRT”, so I shifted everything down one
level into

$PATH_TO_RT/WebRT/html/DTRT/

and that “kind of worked”. I can create tasks and new subtasks and so
on.

Ah, yes. That’s actually what I did. Sorry for the poor directions!

No problem.

I think this shows great promise and could be a really great addition
for me. But before achieving that I think that I need

a) a bit more integration. As it is, if I stumble out of DTRT then I
have to know my way back to find it.

b) less focus on dates. I care much more about relationships between
tasks than I care about exact delivery dates. And although I may be
confused by the things I’ve stumbled on it seems to me that the
basis for DTRT structure is time stamps more than relationships.

c) Working Gantt charts.

That’s reasonable. Keep in mind, though, that this is basically just
contributed work that wasn’t finished. I think this began as a
financially sponsored extension, but then the potential sponsors
disappeared. But that doesn’t mean your requirements are invalid at
all, I just wanted to raise that point to be sure we keep our
expectations in perspective.

Certainly. I fully understand this and I was not complaining, merely
reporting initial observations.

Question 1: do you have the gantt charts working?

No, I also experienced the same problems you did. And actually, I’m
not really using the DTRT stuff in a production capacity. But, I
soon may be using my own extensions based on DTRT (merely the
hierarchical view stuff, actually) in production for project
management.

Ok.

Question 2: in your experience, is it possible to work with DTRT with
focus on relationships between tasks rather than time?

Definitely. You can create a page that shows you a task and its
dependencies, but not any of the time data.

Ok. Good.

Question 3: have you done any integration work between RT and DTRT?

No, and the integration work I do will probably be queue specific. I
doubt I’ll be adding any Tabs or anything like that. It will be
more like “only a couple of people will want this and they will
access it directly via a bookmark”. Basically, we’re going to have a
"Projects" queue that DTRT stuff is applicable for, but otherwise we
probably won’t use it.

Ah, of course that is an easy way of managing this.

I’d be interested to hear what your design goals for RT and project
management would be. Maybe we could work together to iron out some
of the issues we’ve been experiencing with certain DTRT
functionality and then target some of the same goals.

I’ll think about it. Right now I admit that I was mostly out shopping
for “added value” to increase the value of switching to RT from
certain other solutions. So I really don’t have specific design goals
yet, although I should be able to produce some if I just and think
about it some more.

Regards,

Johan Ihr�n
Autonomica

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

I don’t know.

  • I would have exactly the same interface to the data locally
    (i.e. the same hierchy of webpages accessible through my browser
    instead of switching to a different tool).

If you get it to work, then each person could just hit their local RT2
instance all the time, with updates being taken care of by the back-end.

I think that this is what ACT! does.

rob

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

I think there would be a lot of work with resolving conflicts between
a disconnected user and the master db, or between two or more
disconnected users. If the state of the system changes during
disconnection (for instance, a new ticket is created) or if
conflicting changes are made to a ticket state (for instance, two
people set the status of a ticket differently, or if someone merges a
ticket), you would have to do some amount of work (I think a fair bit)
in order to get those conflicts resolved. Also, you’d have to coerce
the disconnected RTs into knowing they are disconnected (queueing mail
for later delivery, etc.). I do think it would change a fair bit for
each RT version, and I don’t think it would be as simple as “turn on
replication.”

Ssh tunneling: not relevant, if I have net access, then I have net
access. This is for not having net access.

Okay, my mis-read.

Excel: well, we are not a Windoze persons, we’re Unix people. I have
lots of respect for Excel, which is a fine tool running under the
wrong OS (not a religious point, merely an observation of the
cumbersomness of dualbooting etc).

Whatever. Consider “Excel” to be a variable and define it however
people of your religion do. The point is, a dump of readable data
would be trivial in mysql:

SELECT query INTO OUTFILE “filename” …

and there you are. That file can be delimited with whatever you want and
read in anything that reads delimited files (like Excel, perl, emacs, blah
blah blah…). Set up that query once and it will likely continue to work
quite well through RT revisions. The point was not which tool to use, but
instead that a read-only extract would take a couple of minutes to put
together, and would work for many cases.

But to become convinced I would like to hear why replication wouldn’t
work in this scenario.

I didn’t say it wouldn’t work – I just said it would be a lot of work
to do, and it isn’t clear to me the benefit would be that great.

But hey! It’s not my implementation time we’re talking about. You
asked for an opinion and I gave it, now do whatever makes you happy! :wink:

Cheers,

Marc Hedlund
e: marc at precipice dot org

-----Original Message-----
When I was at VA Linux Systems, they needed disconnected
functionality (with auto-updates with re-connect) for their
CRM. I thought that the convolutions were amazing to see, it
was so important to the sales guys.

With disconnected operations, how do you create a new ticket?
Have my userid in the name of it? I don’t know, myself, I
haven’t put that much brainpower into it.

To be honest, this sounds like a job for a system implemented on
Commence or another database designed for disconnected operations. I
haven’t seen any general-purpose SQL DBMSes which do even half as well
at disconnected ops; they’re designed for systems which are always
connected, and the big deal is synchronizing operations over an
always-connected but relatively slow WAN. (Contrariwise, none of the
systems designed for disconnected operations are especially general, and
applications developed on top of them must be designed differently —
the database engines are that different.)

brandon s allbery [openafs/solaris/japh/freebsd] allbery@kf8nh.apk.net
system administrator [linux/heimdal/too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [better check the oblivious first -ke6sls]

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too
much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

I don’t know.

Too much design work, and too much maintenance required: batching and
synchronizing operations for a DBMS not designed for offline
transactions is painful, cranky, tricky, hard to get right, and tend to
go out of sync such that someone needs to go in and edit and apply
offline transactions manually. It’s been done, many times, and it’s
always painful.

If you get it to work, then each person could just hit their
local RT2 instance all the time, with updates being taken
care of by the back-end.

I think that this is what ACT! does.

Yup; products like ACT! and Commence, and to some extent Lotus Notes,
are designed for this kind of use. But there’s a tradeoff: you have to
live with other restrictions to get offline operations to work
relatively painlessly.

brandon s allbery [openafs/solaris/japh/freebsd] allbery@kf8nh.apk.net
system administrator [linux/heimdal/too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [better check the oblivious first -ke6sls]

“Brandon S. Allbery KF8NH” allbery@ece.cmu.edu writes:

-----Original Message-----
When I was at VA Linux Systems, they needed disconnected
functionality (with auto-updates with re-connect) for their
CRM. I thought that the convolutions were amazing to see, it
was so important to the sales guys.

With disconnected operations, how do you create a new ticket?
Have my userid in the name of it? I don’t know, myself, I
haven’t put that much brainpower into it.

To be honest, this sounds like a job for a system implemented on
Commence or another database designed for disconnected operations. I

Thanks to everyone for all your comments. It seems that the general
consensus is that I’m somewhere between bonkers and a hard place…:wink:

However, most of the replies are based upon the assumtion that I will
make updates to the replica while offline. As soon as that happens
everything get way more complicated and I agree with all of you.

While that would be nice (and likely an unsolvable problem in the
general case, since automatic conflict resolution is impossible), I
explicitly said that I’m willing to restrict myself to only read-only
access while disconnected.

I.e. what I need is to have my replica get up to date on what is the
present status of all subprojects, tasks, customer tickets, etc, so
that I can browse this while disconnected.

Look at it like my personal email archive: I have my entire email
baggage with me in my laptop too, all “incoming” that I haven’t
deleted and all “outgoing” for more years than I care to remember.
The reason I carry that around is that, from time to time, I need to
browse it to find out what actually was said. Not necessarily to
immediately reopen old email conversations all the time (although that
happen too, of course).

Read-only access while disconnected is ok, since what I need is access
to the ticketing system for reference, to catch up on status and
recent comments, not primarily to immediately respond to customer
tickets (and thereby changing the state of the db). What I want is the

    "state of the company" tool,

including dependencies, and this actually seemed like a rather
simple way of achieving that. And the dependencies is another reason
that I don’t see export of tables into Excel as a solution here.

I agree that the fully fledged, disconnected mode ticketing system
with automatic resynchronization and conflict ressolution would be
very nice, but that is not really needed and not what I’m looking for
here.

Regards,

Johan Ihr�n
Autonomica

So what I would like to do is run RT on top of a replicated MySQL
db with slave replicas in our laptops.
[…]
Is this idea a strong indication of someone either finally going
bonkers or at least trying to fit a square nail into a triangular
hole?

Yes, to both questions. That’s craaazy. Or at least way too much work
for the reward.

Thank you, sir. I will not deny that you are most probably right here :wink:

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

A simple solution would be to mysqldump the database on the server,
and rsync the data over to your laptop, and then make an import on your
local setup.

I do that to mboxes to always have a local copy of my mail, if net
access wouldn’t allow me to read it.

patrik_wallstrom->foodfight->pawal@blipp.com->+46-709580442

Patrik Wallstrom pawal@blipp.com writes:> On Tue, 16 Apr 2002, Johan Ihren wrote:

So what I would like to do is run RT on top of a replicated MySQL
db with slave replicas in our laptops.
[…]
Is this idea a strong indication of someone either finally going
bonkers or at least trying to fit a square nail into a triangular
hole?

Yes, to both questions. That’s craaazy. Or at least way too much work
for the reward.

Thank you, sir. I will not deny that you are most probably right here :wink:

I realise this, and I want to make that clear. Also, I am not
experienced with real databases. So I have to ask: way too much work
to whom? To me to make it work? To the master db keeping update
logs? To the client (my laptop) trying to stay in sync?

A simple solution would be to mysqldump the database on the server,
and rsync the data over to your laptop, and then make an import on
your local setup.

Yes, that would do it. However, that would lead to all of the data
being brought over the network (and imported) each time, while using
replication would bring this down to just deltas. Yes, with
sufficiently infrequent deltas the update log may actually be larger
than the end result, but that is not the environment I’m interested in
and not typical of a ticketing system with thousands of old (hopefully
resolved) tickets laying around in the database.

Regards,

Johan Ihr�n
Autonomica

-----Original Message-----
From: Johan Ihren [mailto:johani@autonomica.se]
Sent: Tuesday, April 16, 2002 1:02 PM
To: Patrik Wallstrom
Cc: Marc Hedlund; rt-users@lists.fsck.com
Subject: Re: [rt-users] RT to go? Dependency graphs?

A simple solution would be to mysqldump the database on the server,
and rsync the data over to your laptop, and then make an import on
your local setup.

Yes, that would do it. However, that would lead to all of the data
being brought over the network (and imported) each time, while using
replication would bring this down to just deltas. Yes, with
sufficiently infrequent deltas the update log may actually be larger
than the end result, but that is not the environment I’m interested in
and not typical of a ticketing system with thousands of old (hopefully
resolved) tickets laying around in the database.

I am also interested in this feature.

In our case, we consider to offer a “read-only” RT system,
which will be accessible to our customers via Internet.
More precisely, that system will be web-housed at an
ISP, whereas the “read-write” RT system will be in
our company network (the company network is connected
to Internet via dial-on-demand).

IMO MySQL replication should not be any problem.
Not that I am a MySQL expert but I just had a look at the documentation :

http://www.mysql.org/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#Replication

One-way replication (since MySQL 3.23.15) should suffice for our needs…
Moreover, the Q&A says:

Q: Does the slave need to be connected to the master all the time?

A: No, it does not. You can have the slave go down or stay disconnected for hours or even days,
then reconnect, catch up on the updates, and then disconnect or go down for a while again.

Comments are welcome.

Personally I will have to wait for some time until I can try out
such a set up (waiting for another machine). If anybody tries out
something similar I would love to hear about it.

Regards,

Patrick De Muynck, CCIE
DreamTech – Athens