RT 3.8.2 -> 3.8.3 Update/Changes

First, thank you to the BP team for the update. Making a good product better is always welcome :slight_smile:

Second, I just wanted to point out to folks that use WebExternalAuth, and potentially the companion WebFallbackToInternalAuth, that it has been reversed. In RT 3.8.2, it was “…is undefined, the user…” and in 3.8.3, it is now “…is defined, the user…” so please be careful.

Another change I noticed was the default-refresh for RT at a Glance (and Search too!) is now a built-in. Thank you for that. I can now remove my own /local/html/index.html file that I had in 3.8.2 for the purpose of the HomepageRefreshInterval setting. I always like it, when I can get rid of my local customizations (which I must point out, I in turn obtained from the rt-users@ mailing list, not like I invented it myself!)

Finally, I wanted to ask about the EmailSubjectTagRegex. In 3.8.2, my EmailSubjectTagRegex is qr/(?:Billing|Technical|Administrative) Support/i ); This prevented RT from changing the subject line. There’s entries in the changelog about “Fix for rewriting Ticket subjects when using Queue Subject tags”. Can I now remove my EmailSubjectTagRegex? Will RT now be able to use each queue’s Subject Tag? All my queue Subject Tag are “Billing Support”, “Technical Support”, etc.

There are lots more changes of course, but those are the ones I noticed. In case folks aren’t reading the entire changelog, I just wanted to highlight the important (imho to me) ones :slight_smile:

Thank you,
PH

Paul Hirose : pthirose@ucdavis.edu : Sysadm Motto: rm -fr /MyLife
1034 Academic Surge : Programmer/Analyst : Backup Motto : rm -fr /
One Shields Avenue : Voice (530) 752-7181 : Robot, n.: Univ. Admin
Davis, CA 95616-8770 : Fax (530) 752-4465 : rec.pets.cat.anecdotes

Second, I just wanted to point out to folks that use WebExternalAuth, and potentially the companion WebFallbackToInternalAuth, that it has been reversed. In RT 3.8.2, it was “…is undefined, the user…” and in 3.8.3, it is now “…is defined, the user…” so please be careful.

My recollection is that this was a documentation fix, not a change in
actual behaviour.

First, thank you to the BP team for the update. Making a good
product better is always welcome :slight_smile:

Second, I just wanted to point out to folks that use
WebExternalAuth, and potentially the companion
WebFallbackToInternalAuth, that it has been reversed. In RT 3.8.2,
it was “…is undefined, the user…” and in 3.8.3, it is now “…is
defined, the user…” so please be careful.

I believe this was just a documentation fix.

Finally, I wanted to ask about the EmailSubjectTagRegex. In 3.8.2,
my EmailSubjectTagRegex is qr/(?:Billing|Technical|Administrative)
Support/i ); This prevented RT from changing the subject line.
There’s entries in the changelog about “Fix for rewriting Ticket
subjects when using Queue Subject tags”. Can I now remove my
EmailSubjectTagRegex? Will RT now be able to use each queue’s
Subject Tag? All my queue Subject Tag are “Billing Support”,
“Technical Support”, etc.

Yes, 3.8.3 fixes the Scrip that was wrongly rewriting subjects, it
sounds like your
EmailSubjectTagRegex was working around the bug.

-kevin

Second, I just wanted to point out to folks that use
WebExternalAuth, and potentially the companion
WebFallbackToInternalAuth, that it has been reversed. In RT 3.8.2,
it was “…is undefined, the user…” and in 3.8.3, it is now “…is
defined, the user…” so please be careful.

My recollection is that this was a documentation fix, not a change in
actual behaviour.

I confirm, see svn 17865 and rt ticket 12478.

Is a database upgrade needed? When we went from 3.8.2 to .3 it failed
saying that group something id already exists.

Thanks.On 01/06/2009, Jesse Vincent jesse@bestpractical.com wrote:

Second, I just wanted to point out to folks that use WebExternalAuth, and
potentially the companion WebFallbackToInternalAuth, that it has been
reversed. In RT 3.8.2, it was “…is undefined, the user…” and in
3.8.3, it is now “…is defined, the user…” so please be careful.

My recollection is that this was a documentation fix, not a change in
actual behaviour.


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

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

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

http://www.suretecsystems.com/services/openldap/

Is a database upgrade needed? When we went from 3.8.2 to .3 it failed
saying that group something id already exists.

Yes, there is a database upgrade involved.

Please send the full error message and the command you use
to rt-bugs@bestpractical.com so we can review it.

There were no groups created between 3.8.2 and 3.8.3 so I wonder
what happened.

-kevin> On 01/06/2009, Jesse Vincent jesse@bestpractical.com wrote:

Second, I just wanted to point out to folks that use
WebExternalAuth, and
potentially the companion WebFallbackToInternalAuth, that it has
been
reversed. In RT 3.8.2, it was “…is undefined, the user…” and in
3.8.3, it is now “…is defined, the user…” so please be careful.

My recollection is that this was a documentation fix, not a change in
actual behaviour.


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

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

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


Sent from my mobile device

http://www.suretecsystems.com/services/openldap/
http://www.suretectelecom.com


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

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

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

Will do, thanks.On 03/06/2009, Kevin Falcone falcone@bestpractical.com wrote:

On Jun 3, 2009, at 6:43 AM, Gavin Henry wrote:

Is a database upgrade needed? When we went from 3.8.2 to .3 it failed
saying that group something id already exists.

Yes, there is a database upgrade involved.

Please send the full error message and the command you use
to rt-bugs@bestpractical.com so we can review it.

There were no groups created between 3.8.2 and 3.8.3 so I wonder
what happened.

-kevin

On 01/06/2009, Jesse Vincent jesse@bestpractical.com wrote:

Second, I just wanted to point out to folks that use
WebExternalAuth, and
potentially the companion WebFallbackToInternalAuth, that it has
been
reversed. In RT 3.8.2, it was “…is undefined, the user…” and in
3.8.3, it is now “…is defined, the user…” so please be careful.

My recollection is that this was a documentation fix, not a change in
actual behaviour.


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

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

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


Sent from my mobile device

http://www.suretecsystems.com/services/openldap/
http://www.suretectelecom.com


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

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

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


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

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

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

http://www.suretecsystems.com/services/openldap/

I see a database upgrade for postgres, but nothing for mysql going from
3.8.2 to 3.8.3. Perhaps I’m missing something…

James Moseley

Kevin Falcone falcone@bestpractical.com wrote:

Yes, there is a database upgrade involved.

I see a database upgrade for postgres, but nothing for mysql going
from
3.8.2 to 3.8.3. Perhaps I’m missing something…

etc/upgrade/3.8.3/content

It isn’t a schema change, but it upgrades things in the database.

-kevin

Yeah, we use Pg.

We got 'relation ‘groupmembers1’ already exists.On 03/06/2009, jmoseley@corp.xanadoo.com jmoseley@corp.xanadoo.com wrote:

I see a database upgrade for postgres, but nothing for mysql going from
3.8.2 to 3.8.3. Perhaps I’m missing something…

James Moseley

Kevin Falcone falcone@bestpractical.com wrote:

Yes, there is a database upgrade involved.


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

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

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

http://www.suretecsystems.com/services/openldap/

Yeah, we use Pg.
We got 'relation ‘groupmembers1’ already exists.

Oh, thats ok. We added an index that existed on MySQL but not on Pg,
but if you do your own database tuning there is always a chance
we’ll conflict with you. Pointers to portable, simple and back-
compatible
ways of detecting indexes appreciated.

You may want to run

/opt/rt3/sbin/rt-setup-database --action insert --datadir etc/upgrade/
3.8.3

manually if the upgrade errored out after the failed index.
Or just delete schema.Pg and let --action upgrade do the magic

-kevin

Great, thanks! Will run that later and report back.On 03/06/2009, Kevin Falcone falcone@bestpractical.com wrote:

On Jun 3, 2009, at 9:20 AM, Gavin Henry wrote:

Yeah, we use Pg.
We got 'relation ‘groupmembers1’ already exists.

Oh, thats ok. We added an index that existed on MySQL but not on Pg,
but if you do your own database tuning there is always a chance
we’ll conflict with you. Pointers to portable, simple and back-
compatible
ways of detecting indexes appreciated.

You may want to run

/opt/rt3/sbin/rt-setup-database --action insert --datadir etc/upgrade/
3.8.3

manually if the upgrade errored out after the failed index.
Or just delete schema.Pg and let --action upgrade do the magic

-kevin

On 03/06/2009, jmoseley@corp.xanadoo.com jmoseley@corp.xanadoo.com wrote:

I see a database upgrade for postgres, but nothing for mysql going
from
3.8.2 to 3.8.3. Perhaps I’m missing something…

James Moseley

Kevin Falcone falcone@bestpractical.com wrote:

Yes, there is a database upgrade involved.


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

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

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


Sent from my mobile device

http://www.suretecsystems.com/services/openldap/
http://www.suretectelecom.com


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

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

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


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

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

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

http://www.suretecsystems.com/services/openldap/

Yeah, we use Pg.
We got 'relation ‘groupmembers1’ already exists.

Oh, thats ok. We added an index that existed on MySQL but not on Pg,
but if you do your own database tuning there is always a chance
we’ll conflict with you. Pointers to portable, simple and back-
compatible
ways of detecting indexes appreciated.

You may want to run

/opt/rt3/sbin/rt-setup-database --action insert --datadir etc/upgrade/
3.8.3

manually if the upgrade errored out after the failed index.
Or just delete schema.Pg and let --action upgrade do the magic

Great, worked fine. Just deleted schema.Pg

Thanks.

http://www.suretecsystems.com/services/openldap/

Is a database upgrade needed? When we went from 3.8.2 to .3 it failed
saying that group something id already exists.

Yes, there is a database upgrade involved.

Really? Documentation didn’t mention that.

UPGRADING FROM 3.8.2 and earlier - Changes:

New scrip condition ‘On Reject’.

That’s the only mention, and this seems like more of a feature than a
todo for the UPGRADING document.

UPGRADING.mysql only mentions mysql 4.0 -> 4.1 and versions prior to
3.8.0.

If upgrades from 3.8.2 to 3.8.3 are supposed to do something, it is
entirely undocumented.

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

Yes, there is a database upgrade involved.

$ rt-setup-database --action upgrade --datadir etc/upgrade/3.8.3
(snip)
Enter RT version you’re upgrading from: 3.8.2
No DB changes between 3.8.2 and 3.8.3
Done.

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

Yes, there is a database upgrade involved.

$ rt-setup-database --action upgrade --datadir etc/upgrade/3.8.3
(snip)
Enter RT version you’re upgrading from: 3.8.2
No DB changes between 3.8.2 and 3.8.3
Done.

/tmp/rt-3.8.3$ /opt/rt3/sbin/rt-setup-database --action upgrade
Enter RT version you’re upgrading from: 3.8.2

Going to apply following upgrades:

  • 3.8.3

Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:

I don’t think you’re doing this from a tarball,
you’re trying to do it from the installed directory.

It gives you an even more specific command to run
at the end of the output from make upgrade

-kevin

Except that your command is just wrong:

$ rt-setup-database --action upgrade --datadir etc/upgrade

Enter RT version you’re upgrading from: 3.8.2
Going to apply following upgrades:

  • 3.8.3
    Enter RT version if you want to stop upgrade at some point,
    or leave it blank if you want apply above upgrades:On Wed, Jun 3, 2009 at 11:17 PM, Jo Rhett jrhett@netconsonance.com wrote:

On Jun 3, 2009, at 5:30 AM, Kevin Falcone wrote:

Yes, there is a database upgrade involved.

$ rt-setup-database --action upgrade --datadir etc/upgrade/3.8.3
(snip)
Enter RT version you’re upgrading from: 3.8.2
No DB changes between 3.8.2 and 3.8.3
Done.


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: sales@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.

I don’t think you’re doing this from a tarball,
you’re trying to do it from the installed directory.

Nope, from the extracted tarball in ports directory.

It gives you an even more specific command to run
at the end of the output from make upgrade

FreeBSD port doesn’t use “make install” or “make upgrade” – unless
perhaps we’re supposed to run “make upgrade” from the extraction
directory afterwards. The port doesn’t indicate this.

I’m very tempted to stop using the FreeBSD port and just run RT from a
single install directory, but I’m also aware that this will make the
installation even more tied-to-Jos-brain and less easy for others to
maintain, so…

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

Everyone has their own way of doing things, but I find upgrading RT is
easiest by essentially installing RT from scratch upon each upgrade and
then soft-linking to the new directory. In this way, upgrades are
straightforward and not hard to follow. For example:

download new RT source
untar/unzip RT source
rename RT source to rt-3.8.3.src (in this example RT 3.8.3)
cd rt-3.8.3.src
./configure --prefix=/opt/rt3.8.3 --with-web-user=apache
–with-web-group=apache --with-mysql --with-web-handler=fastcgi (or
mod_perl, etc)
make testdeps
upgrade/install any required perl modules via ‘make fixdeps’ or cpan
make install
copy RT_SiteConfig.pm from current RT installation (let’s assume /opt/rt3
and that /opt/rt3 is a soft link to, for example, /opt/rt3.8.2) to
/opt/rt3.8.3/etc/ and /opt/rt-3.8.3.src/etc
Copy any local customizations from /opt/rt3/local into /opt/rt-3.8.3/local

From within source directory:
sbin/rt-setup-database --action upgrade --datadir etc/upgrade
(The above step upgrades the database)
cd /opt
rm /rt3
ln -s /opt/rt-3.8.3/ rt3 (relinking /opt/rt3 to new source)
restart httpd

In this way, if the new version of RT breaks or doesn’t seem to work right,
I can just relink /opt/rt3 to the old installation. Of course, if the
database upgrade doesn’t go right and is the cause of breakage, you’ll need
to restore the database from a backup. A backup you hopefully just
performed prior to beginning the upgrade process. :wink: If it’s a major
schema upgrade, then I suggest testing things out by running the new RT
installation from a test server against a static/test copy of your RT
database.

James Moseley

Jo Rhett jrhett@netconsonance.com wrote:

FreeBSD port doesn’t use “make install” or “make upgrade” – unless
perhaps we’re supposed to run “make upgrade” from the extraction
directory afterwards. The port doesn’t indicate this.

I’m very tempted to stop using the FreeBSD port and just run RT from a
single install directory, but I’m also aware that this will make the
installation even more tied-to-Jos-brain and less easy for others to
maintain, so…

I don’t think you’re doing this from a tarball,
you’re trying to do it from the installed directory.

Nope, from the extracted tarball in ports directory.

It gives you an even more specific command to run
at the end of the output from make upgrade

FreeBSD port doesn’t use “make install” or “make upgrade” – unless
perhaps we’re supposed to run “make upgrade” from the extraction
directory afterwards. The port doesn’t indicate this.

I’m very tempted to stop using the FreeBSD port and just run RT from a
single install directory, but I’m also aware that this will make the
installation even more tied-to-Jos-brain and less easy for others to
maintain, so…

I have always run my RT from the tarball on FreeBSD and it installs
everything in /opt/.
Upgrading that should not cause any hell if you follow the rules. The only
deviation is the upgrade of the perl modules, which “make fixdeps” does for
you. If other people are to maintain the system, then write them a howto for
maintaining RT, but AFAICS, it’s already there for you in UPGRADING. Just
point them to it.

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223


“Clothes make the man. Naked people have little or no influence on
society.”
– Mark Twain