Re: [rt-users] RT 4 - status report

2009-03-22 Thread Jo Rhett
On Mar 20, 2009, at 1:13 PM, Ruslan Zakirov wrote:
 If your crontool fails to write into file log then it's your mistake.
 File log is not designed to be used in production, use syslog and/or
 screen logging.

I never said file log.  That was easy to solve.  I can set rights on a  
file log.  The mason cache privileges get reset on every creation.

 crontool doesn't use mason cache, but dashboards mailer can and it has
 been fixed in 3.8.HEAD and the fix will be available in 3.8.3.

Awesome to hear.

 In a perfect world, I want to install RT as a single user, then run a
 separate HTTP instance as that same user, so that RT is running  
 within
 a single user account.  I'm mostly there on a dev install, but I've
 already had to modify far too many files for it to be a simple patch.
 As jesse suggested you can use --with-my-user-group option to do this.
 developers use it successfully for ages :)


Okay, if the official answer is that this should work then I'll file  
bugs against each thing that doesn't work.

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


[rt-users] RT 4 - status report

2009-03-20 Thread Jesse Vincent
It should come as no suprise to folks that we've been hard at work on
what will become RT 4.0.

We've been working hard to overhaul the entire codebase. The current
version of the web interface is only 10,000 lines of HTML shorter
(118kloc down from 128kloc), but the core libraries have shrunk from
68kloc of code to 54kloc.  

At the same time, we've moved RT from its own homegrown application
framework to Jifty, Best Practical's next-generation web application
platform.  Jifty brings with it all sorts of new features which make it
easier to build out web services and web applications with less code and
easier support for modern Web 2.0 features. 

If you download the RT 3.999 development branch today, you'll find 
a few major new features.  The most visible of those is Status
schemas.  In RT 4, you can define directed graphs of ticket states and
valid transitions between those states. You can associate one or more
queue with any status schema.   At its simplest, this means that you can
now freely add or remove statuses from your RT instance through the web
interface.  If you want to get a bit fancier, you can specify that new
tickets can move only to open or rejected and that open tickets
can only move to the testing or rejected states.   This makes it
easier than ever to adapt RT to your existing process and workflow.

Under the hood, we've begun to generalize other parts of RT.  While role
groups are still limited to Requestor, Cc and AdminCc, we've
mostly completed work that will allow you to define custom role groups.
(Exposing that functionality isn't currently slated for RT 4.0)

There are a few fairly major projects in progress which we're currently
planning for RT 4.0:

- Most application configuration will move into the database, making it
  easier for RT administrators to fully manage RT using the web interface.

- TicketSQL has been extended as 'tisql', a new, more powerful query
  language which will be available internally for all objects in RT, not just
  tickets.

- Scrips are being replaced with a new workflow engine codenamed
  'Lorzy'.  Lorzy makes it possible to build out much more complex rules
  than Scrips' simple If __ Then __ conditionals.  Under the hood,
  Lorzy is a fully sandboxable lisp-like functional minilanguage with
  named, typed arguments and the ability to detect runaway rules and
  limit individual rules by actor.  In the future, we hope to also
  expose Lorzy as a user-level scripting engine for RT. 

- Date and Time rationalization - We've been ripping out RT's old and
  fairly adhoc implementations of various bits of date and time and
  replacing them with a shiny, new implementation based around Perl's
  DateTime suite.

There are a dozen other projects we want to undertake - We're going
to try to hold out so we have something cool to show for 4.2, 4.4
and beyond.

We have a few additional bits of backward-compatibility we want to
break before declaring something as a 4.0 beta that we'd actually
like folks to test in production.  We're not there yet. I'll tell
you as soon as we get there.

4.0 is a major new release of RT. Like the transition from RT 2.0
to 3.0, 4.0 represents a major break in backwards compatibility
with older versions of RT.   When you look under the hood in RT 4,
you'll see that the entire API has been overhauled to match more
common Perl style guidelines. The most obvious change is that the
API has been rationalized to lower_case_style from the previous
CamelCaseStyle, but there are numerous other changes throughout the
product's internals.  We've written more RT extensions than anyone
out there (as far as I know) and we're very, very aware of just how
painful a major API change is.  We have the beginnings of tools and
guidelines to help you make the transition with as little pain as
possible.

It should come as no surprise to you that I'm not announcing a
release date for RT 4.0.0 today, nor will I be doing so in the
immediate future.  We have a _long_ way to go before RT 4 will be
the recommended version of RT for a production or evaluation
deployment. Even once that happens, Rest assured that we'll continue
to support RT 3.x for a good long time.  Best Practical's business
is built on helping our users make good use of RT and our other
products -- We're not about to cut off those of you using RT 3 in
production.

Best,

Jesse

RT4 Release MicroFAQ



Q: How can I help?

A: I'm glad you asked.  http://wiki.bestpractical.com/view/RT4 has a
   pointer to the RT4 source code. Check out the source. Then do any 
   of the following:

- Clean up code that you think needs cleanup.
- Add or improve documentation. Find bugs. 
- Fix bugs.

   Mail patches or bug reports to r...@bestpractical.com.



Q: When will RT 4.0 be released?

A: How much money do you have?



Q: Why doesn't RT 4.0 have feature XXX? 

A: Please send patches to r...@bestpractical.com.  
   Please send RFPs to sa...@bestpractical.com.


pgptkX5NANFDD.pgp

Re: [rt-users] RT 4 - status report

2009-03-20 Thread Jo Rhett
On Mar 20, 2009, at 9:29 AM, Jesse Vincent wrote:
 At the same time, we've moved RT from its own homegrown application
 framework to Jifty, Best Practical's next-generation web application
 platform.  Jifty brings with it all sorts of new features which make  
 it
 easier to build out web services and web applications with less code  
 and
 easier support for modern Web 2.0 features.


That's good.  Would this change improve the ability to run RT in a  
virtual server environment, instead of having to pretty much commit an  
entire machine to it?   The number of things which must be done by  
root which don't actually need root permissions, and could run under  
a more limited user is quite large.  But they are difficult to  
overcome with hacking the source due to assumptions built into the code.

I've got RT working entirely within a virtual/shared web server  
environment, but it's a lot of work.  And honestly, the lot of work  
has entirely to do with built-in-assumptions rather than actual  
problems that prevent its implementation that way.  I'm trying to  
figure out how to document all of the work required for this.

If I was to grab to 4.0 codebase and start finding and sending patches  
to prevent these kind of assumptions from being made, it would make me  
a lot happier.  I'm also certain it would broaden the potential  
userbase and resolve a great many of the questions that come up on  
this list.

Not that OTRS is as good as RT.   But you can untar OTRS inside a  
shared virtual server and have it up and running without ever becoming  
root in 5 minutes.

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT 4 - status report

2009-03-20 Thread Jesse Vincent

 That's good.  Would this change improve the ability to run RT in a  
 virtual server environment, instead of having to pretty much commit an  
 entire machine to it?   The number of things which must be done by  
 root which don't actually need root permissions, and could run under  
 a more limited user is quite large.  But they are difficult to  
 overcome with hacking the source due to assumptions built into the code.


Such as?

I run RT configured --with-my-user-group all the time.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT 4 - status report

2009-03-20 Thread Jo Rhett
On Mar 20, 2009, at 10:28 AM, Jesse Vincent wrote:
 That's good.  Would this change improve the ability to run RT in a
 virtual server environment, instead of having to pretty much commit  
 an
 entire machine to it?   The number of things which must be done by
 root which don't actually need root permissions, and could run under
 a more limited user is quite large.  But they are difficult to
 overcome with hacking the source due to assumptions built into the  
 code.

 Such as?

 I run RT configured --with-my-user-group all the time.


Such as rt-crontool.   I fought through a week of trying to be able to  
run rt-crontool as any user other than root, and it never succeeded.   
If the mason-cache stuff was created using a consistent userid then we  
could run rt-crontool as that user.

In a perfect world, I want to install RT as a single user, then run a  
separate HTTP instance as that same user, so that RT is running within  
a single user account.  I'm mostly there on a dev install, but I've  
already had to modify far too many files for it to be a simple patch.

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness



___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT 4 - status report

2009-03-20 Thread Tom Lahti
 At the same time, we've moved RT from its own homegrown application
 framework to Jifty, Best Practical's next-generation web application
 platform.  Jifty brings with it all sorts of new features which make it
 easier to build out web services and web applications with less code and
 easier support for modern Web 2.0 features. 

My big question here should be obvious: will RT 4.0 maintain the exact same
/REST/1.0/ API as RT 3.x?

Secondarily, will it expose additional web services beyond that?  /REST/2.0/
perhaps?

-- 
-- 
   Tom Lahti
   BIT Statement LLC

   (425)251-0833 x 117
   http://www.bitstatement.net/
-- 
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT 4 - status report

2009-03-20 Thread Jesse Vincent

On Fri, Mar 20, 2009 at 12:32:44PM -0700, Tom Lahti wrote:
  At the same time, we've moved RT from its own homegrown application
  framework to Jifty, Best Practical's next-generation web application
  platform.  Jifty brings with it all sorts of new features which make it
  easier to build out web services and web applications with less code and
  easier support for modern Web 2.0 features. 
 
 My big question here should be obvious: will RT 4.0 maintain the exact same
 /REST/1.0/ API as RT 3.x?

Yes. And if it doesn't, it's a bug. Once we get to usable beta status,
please beat hard on it to make sure we cover all your cases.

 
 Secondarily, will it expose additional web services beyond that?  /REST/2.0/
 perhaps?

Yes. That's one of the things Jifty gets us 'free'.

___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com


Re: [rt-users] RT 4 - status report

2009-03-20 Thread Ruslan Zakirov
On Fri, Mar 20, 2009 at 9:05 PM, Jo Rhett jrh...@netconsonance.com wrote:
 On Mar 20, 2009, at 10:28 AM, Jesse Vincent wrote:
 That's good.  Would this change improve the ability to run RT in a
 virtual server environment, instead of having to pretty much commit
 an
 entire machine to it?   The number of things which must be done by
 root which don't actually need root permissions, and could run under
 a more limited user is quite large.  But they are difficult to
 overcome with hacking the source due to assumptions built into the
 code.

 Such as?

 I run RT configured --with-my-user-group all the time.


 Such as rt-crontool.   I fought through a week of trying to be able to
 run rt-crontool as any user other than root, and it never succeeded.
 If the mason-cache stuff was created using a consistent userid then we
 could run rt-crontool as that user.
If your crontool fails to write into file log then it's your mistake.
File log is not designed to be used in production, use syslog and/or
screen logging.

crontool doesn't use mason cache, but dashboards mailer can and it has
been fixed in 3.8.HEAD and the fix will be available in 3.8.3.



 In a perfect world, I want to install RT as a single user, then run a
 separate HTTP instance as that same user, so that RT is running within
 a single user account.  I'm mostly there on a dev install, but I've
 already had to modify far too many files for it to be a simple patch.
As jesse suggested you can use --with-my-user-group option to do this.
developers use it successfully for ages :)



 --
 Jo Rhett
 Net Consonance : consonant endings by net philanthropy, open source
 and other randomness



 ___
 http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

 Community help: http://wiki.bestpractical.com
 Commercial support: sa...@bestpractical.com


 Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
 Buy a copy at http://rtbook.bestpractical.com




-- 
Best regards, Ruslan.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sa...@bestpractical.com


Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
Buy a copy at http://rtbook.bestpractical.com