Re: [rt-users] quick-set Starts date
This is a great starting point! Thanks very much. I intend to modify the code you've provided in the following ways: - provide an option not to stall the tickets - use free-form dates and times (e.g. "8pm today", "midnight tomorrow") - define the desired buttons via RT_SiteConfig.pm - make the dates/times relative to the time of the button being pressed, not the time of the Display page being loaded When I get around to that, and if I can do these changes in a way that would make sense for that plugin, I'll gladly send you a GitHub pull request. 2014-12-02 22:01 GMT+09:00 Brumm, Torsten / Kuehne + Nagel / Ham GI-ID < torsten.br...@kuehne-nagel.com>: > Hi Alex, > > just spent a few minutes to change the original RT-Extension-DueButtons to > StartsButtons: > > > > https://github.com/tbrumm/RT-Extension-StartsButtons > > > > Have fun. > > > > *Von:* rt-users [mailto:rt-users-boun...@lists.bestpractical.com] *Im > Auftrag von *Alex Peters > *Gesendet:* Dienstag, 2. Dezember 2014 03:23 > *An:* rt-users@lists.bestpractical.com > *Betreff:* [rt-users] quick-set Starts date > > > > I want to be able to quickly adjust a ticket's Starts date from the > ticket's Display view without going to the ticket's Dates page and manually > entering the date. > > > > For example, having a "Starts" top-level menu item next to "Actions" with > sub-entries "tomorrow morning," "next week" etc. would achieve this nicely. > > > > Has anyone already done something like this? Any recommended approaches? > Is there a best-practice way for submitting a POST request from that menu, > or would I have to do it as a GET request? Is anyone aware of a plugin > that works in a similar manner? Any pointers on which callbacks I should > target? > > > Kühne + Nagel (AG & Co.) KG > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE > 812773878. > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Dirk > Blesius, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Christian > Marnetté, Christian Solf, Jens Wollesen. > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. > Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Hans-Georg > Brinkmann (Stellv.), Richard Huhn, Björn Johansson, Bruno Mang, Stefan > Paul, Tim Scharwath, Dominic Edmonds, Peder Winther. > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen > Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen > insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von > Ziffer 23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen > gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com > einsehen. Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen > internationaler Übereinkommen weder unsere Haftung noch die Zurechnung des > Verschuldens von Leuten und sonstigen Dritten zu Gunsten des Auftraggebers > erweitert, und (2) wir in den im deutschen Seehandelsrecht aufgeführten > Fällen des nautischen Verschuldens oder Feuer an Bord nur für eigenes > Verschulden und (3) im Sinne der CMNI genannten Voraussetzungen nicht für > nautisches Verschulden, Feuer an Bord oder Mängel des Schiffes haften. >
Re: [rt-users] plugins link to module file, not package file
Could you please clarify what you're asking here? How to install the plugins? The plugins can be installed like any other CPAN module. Given a link to a specific .pm file: http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm you can hit the Download link on the right side of the page to receive a .tar.gz file of the distribution, which can either be fed directly into the cpan or cpanm utilities, or unpacked and installed manually using Makefile.PL and make. With RT extensions, you may find it useful to set environment variable RTHOME to the root directory of your RT installation before installing the plugin: $ RTHOME=/opt/rt-4.2.7 cpanm RT-Extension-MandatorySubject-0.05.tar.gz On 3 December 2014 at 16:19, Jo Rhett wrote: > Hey, dunno if this got overlooked during the short vacation week. This is > a pretty serious issue… asking users to manually hack up the URL in their > browser bar is not accessible. > > On Nov 26, 2014, at 2:22 PM, Jo Rhett wrote: > > Hey guys and gals, been a long time. > > I’m doing an upgrade from 3.8.5 to 4.2. It seems to be going well. I’m > liking the changes. Other than some confusion about what order to do things > in (see my other message) the one thing I can’t seem to wrap my head around > is the new plugin setup. > > First, yay! I like the idea of what you’ve done with plugins, keeping them > local and the simplified syntax in RT_SiteConfig.pm. > > [in which I wander in the wrong direction… read and giggle] > > However, I can’t find any plugins other than yours which are built in > these new packages you document at > https://www.bestpractical.com/docs/rt/4.2/writing_extensions.html > > What is the fallback method for installing the other style modules? How do > I get from a .pm file to an installed module. Can I manually create the > directory structures and copy these into place? I see some details there > but it doesn’t inspire confidence that everything I need to know is there. > A breakout of the directory structure would be really helpful. > > [forehead slap] > > I was almost done with this e-mail when I realized the problem. If you go > to http://bestpractical.com/rt/extensions.html and you find the extension > you are looking for, the link to the Homepage for the extension actually > links to the main module, and not to the extension package. Example for one > > Homepage link takes you to: > > http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm > > If you’re a bit tired and under-caffeniated, or just plain new to RT, it > may not be clear to you that you need to remove a bunch from the URL to > find the extension package. In my opinion, it would be much better to link > to the package instead of the module file, like so: > http://search.cpan.org/dist/RT-Extension-MandatorySubject/ > > I did some random spot checking, and this appears to be true for every > module shown there. > > -- > Jo Rhett > +1 (415) 999-1798 > Skype: jorhett > Net Consonance : net philanthropy to improve open source and > internet projects. > > > -- > Jo Rhett > +1 (415) 999-1798 > Skype: jorhett > Net Consonance : net philanthropy to improve open source and > internet projects. > >
Re: [rt-users] unordered mismash of upgrade instructions
Likewise on this one. I’d appreciate a response from Best Practice as to the proper ordering for an upgrade… On Nov 26, 2014, at 2:32 PM, Jo Rhett wrote: > Hey guys and gals, been a long time. > > I’m doing an upgrade from 3.8.5 to 4.2. It seems to be going well. I’m liking > the changes. Glad to see RTFM integrated. My one big question here that I > think the documentation could definitely improve upon, is what order to do > the changes in? There are changes in every one of these pages and there’s no > clear outline for which ones go first. > > https://www.bestpractical.com/docs/rt/4.2/README.html > https://www.bestpractical.com/docs/rt/4.2/UPGRADING-3.8.html > https://www.bestpractical.com/docs/rt/4.2/UPGRADING-4.0.html > https://www.bestpractical.com/docs/rt/4.2/UPGRADING-4.2.html > https://www.bestpractical.com/docs/rt/4.2/UPGRADING.mysql.html > > I build the new installation on a new system so I’ve done a test upgrade the > following way — totally just guessing which things to do in which order. Can > someone take a moment to validate if I did it right? > > 1. Loaded a backup of the running system's database, renamed to rt4 > 2. Installed apache2 and mod_perl2, set up vhost according to > https://www.bestpractical.com/docs/rt/4.2/web_deployment.html > 3. Download 4.2.9, extract, ./configure --with-web-handler=modperl2 > --with-web-user=apache --with-web-group=apache > 4. sudo make fixdeps > 5. make install > 6. perl etc/upgrade/upgrade-mysql-schema.pl rt4 rt_user password > > ~/update.sql >(read and saw only changes to utf8) > 7. mysql -u rt-user -p rt4 < ~/update.sql > > 8. Cleanup from UPGRADING-3.8 > $ cd /opt/rt4 > $ perl -I /opt/rt4/local/lib -I /opt/rt4/lib > etc/upgrade/shrink_transactions_table.pl > $ perl -I /opt/rt4/local/lib -I /opt/rt4/lib etc/upgrade/vulnerable-passwords > $ perl -I /opt/rt4/local/lib -I /opt/rt4/lib etc/upgrade/vulnerable-passwords > --fix > $ perl -I /opt/rt4/local/lib -I /opt/rt4/lib > etc/upgrade/split-out-cf-categories > > 9. Database upgrade > $ perl -I/opt/rt4/local/lib -I/opt/rt4/lib sbin/rt-setup-database --action > upgrade --prompt-for-dba-password > $ perl -I /opt/rt4/local/lib -I /opt/rt4/lib etc/upgrade/upgrade-articles > $ sbin/rt-validator --check > $ sbin/rt-validator --check --resolve > > I’m thinking that perhaps step 8 should have been done before 6 and 7, but it > seems to have worked and it displays the tickets and seems to operate > properly. > > -- > Jo Rhett > +1 (415) 999-1798 > Skype: jorhett > Net Consonance : net philanthropy to improve open source and internet > projects. > -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: [rt-users] plugins link to module file, not package file
Hey, dunno if this got overlooked during the short vacation week. This is a pretty serious issue… asking users to manually hack up the URL in their browser bar is not accessible. On Nov 26, 2014, at 2:22 PM, Jo Rhett wrote: > Hey guys and gals, been a long time. > > I’m doing an upgrade from 3.8.5 to 4.2. It seems to be going well. I’m liking > the changes. Other than some confusion about what order to do things in (see > my other message) the one thing I can’t seem to wrap my head around is the > new plugin setup. > > First, yay! I like the idea of what you’ve done with plugins, keeping them > local and the simplified syntax in RT_SiteConfig.pm. > > [in which I wander in the wrong direction… read and giggle] > > However, I can’t find any plugins other than yours which are built in these > new packages you document at > https://www.bestpractical.com/docs/rt/4.2/writing_extensions.html > > What is the fallback method for installing the other style modules? How do I > get from a .pm file to an installed module. Can I manually create the > directory structures and copy these into place? I see some details there but > it doesn’t inspire confidence that everything I need to know is there. A > breakout of the directory structure would be really helpful. > > [forehead slap] > > I was almost done with this e-mail when I realized the problem. If you go to > http://bestpractical.com/rt/extensions.html and you find the extension you > are looking for, the link to the Homepage for the extension actually links to > the main module, and not to the extension package. Example for one > > Homepage link takes you to: > > http://search.cpan.org/dist/RT-Extension-MandatorySubject/lib/RT/Extension/MandatorySubject.pm > > If you’re a bit tired and under-caffeniated, or just plain new to RT, it may > not be clear to you that you need to remove a bunch from the URL to find the > extension package. In my opinion, it would be much better to link to the > package instead of the module file, like so: > http://search.cpan.org/dist/RT-Extension-MandatorySubject/ > > I did some random spot checking, and this appears to be true for every module > shown there. > > -- > Jo Rhett > +1 (415) 999-1798 > Skype: jorhett > Net Consonance : net philanthropy to improve open source and internet > projects. > -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects.
[rt-users] [rt-announce] RT for Incident Response 3.2.0 Released
RTIR 3.2.0 is the first release of RTIR compatible with RT 4.2. It is only compatible with RT 4.2.9 and later and will refuse to install on earlier versions of RT 4.2. You should be sure to review both core RT's UPGRADING-4.2 as well as RTIR's UPGRADING-3.2 documentation and any other UPGRADING documentation which may be relevant to your older version. https://download.bestpractical.com/pub/rt/release/RT-IR-3.2.0.tar.gz https://download.bestpractical.com/pub/rt/release/RT-IR-3.2.0.tar.gz.asc SHA1 sums d37288b2bf8d04f3791a15e82323b40e6eaf9837 RT-IR-3.2.0.tar.gz 2fd61f47ff639e3a38e4b5c14ffc1cd6b1d23945 RT-IR-3.2.0.tar.gz.asc Numerous internal updates have been made for compatibility with RT 4.2. If you have local modifications to RTIR you will want to ensure that you update them for compatibility. RT 4.2 renamed many components and introduced a new /static/ root for CSS/JS etc. As a result, many components and callbacks in RTIR have also been modified to align with core renames. You should be sure to review UPGRADING-4.2 in core RT. RTIR makes use of RT's Custom Field Grouping feature, you can read more about it in RTIR_Config.pm and make use of it to organize both RTIR's core Custom Fields as well as your site-specific fields. RTIR's Constituencies have been refactored and will now provide better error messages and will make better use of caching and other performance enhancements. This release also includes recent bugfixes from 3.0 to ensure that Constituency does not lose state during ticket creation and editing. RTIR's linkification of ticket histories will be cached by default on 4.2 which will assist with ticket history rendering on second load. RTIR now also uses RT's delayed-load for history, causing history to be loaded via JavaScript after the rest of the page is rendered, improving page load times. When linking an Incident Report to an Incident after Incident Creation, the IR IP Custom Fields will be automatically copied. Framework now exists to easily add new Scrips to copy other Custom Fields. Particularly useful if you link IRs to Incidents using the API. When splitting a ticket, you can now change Due and Starts. In addition, you can now manually change an Incident's Due Date. RTIR now uses core's Forward functionality, allowing a message to be included with a forward, as well as forwarding of a full ticket in addition to transactions. Forwards are recorded in the history of a ticket. RTIR now has access to core's improved charting, allowing grouping by multiple attributes and calculation of some ticket statistics. The $RTIR_OldestRelatedTickets will now apply to tickets updated in the last n days for any Lookup search. In addition to GnuPG support, RTIR can now leverage RT's S/MIME integration. See the core RT documentation for specifics and configuration. Users who are members of a DutyTeam will now be redirected to the RTIR Homepage on login. Additionally many bugs were squashed, performance enhancements made, doc cleaned up and new callbacks added. A complete changelog is available from git by running: git log 3.0.4..3.2.0 or visiting https://github.com/bestpractical/rtir/compare/3.0.4...3.2.0 pgpyDof8gECHK.pgp Description: PGP signature ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
[rt-users] how to provide the forward option to a user
I have two users who are asking for the forward option within RT. I already have this option as part of my ability to reply-comment-forward so I am surprised it is not available to these other users. How would I assign this option to these other users? Thanks. Jeff Fioravanti Desktop Support Analyst jfiorava...@primax.us P 781-756-8247 (direct) | Fax 781-246-5609 Primax logo autosignature 516 Edgewater Dr., Wakefield, MA 01880 ▪ www.primax.us Confidentiality Statement This e-mail and any attachments are for use by the intended recipient only and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient any disclosure, distribution or other use of this content is prohibited. If you received this e-mail in error, please immediately notify the sender and delete
Re: [rt-users] quick-set Starts date
Hi Alex, just spent a few minutes to change the original RT-Extension-DueButtons to StartsButtons: https://github.com/tbrumm/RT-Extension-StartsButtons Have fun. Von: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] Im Auftrag von Alex Peters Gesendet: Dienstag, 2. Dezember 2014 03:23 An: rt-users@lists.bestpractical.com Betreff: [rt-users] quick-set Starts date I want to be able to quickly adjust a ticket's Starts date from the ticket's Display view without going to the ticket's Dates page and manually entering the date. For example, having a "Starts" top-level menu item next to "Actions" with sub-entries "tomorrow morning," "next week" etc. would achieve this nicely. Has anyone already done something like this? Any recommended approaches? Is there a best-practice way for submitting a POST request from that menu, or would I have to do it as a GET request? Is anyone aware of a plugin that works in a similar manner? Any pointers on which callbacks I should target? Kühne + Nagel (AG & Co.) KG Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878. Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Dirk Blesius, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Christian Marnetté, Christian Solf, Jens Wollesen. Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Hans-Georg Brinkmann (Stellv.), Richard Huhn, Björn Johansson, Bruno Mang, Stefan Paul, Tim Scharwath, Dominic Edmonds, Peder Winther. Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteursbedingungen (ADSp), jeweils neuester Fassung. Wir verweisen insbesondere auf die vom Gesetz abweichenden Haftungsbeschränkungen von Ziffer 23 und 24 ADSp. Den vollständigen Text der ADSp übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter http://www.kuehne-nagel.com einsehen. Ergänzend wird vereinbart, dass (1) Ziffer 27 ADSp im Rahmen internationaler Übereinkommen weder unsere Haftung noch die Zurechnung des Verschuldens von Leuten und sonstigen Dritten zu Gunsten des Auftraggebers erweitert, und (2) wir in den im deutschen Seehandelsrecht aufgeführten Fällen des nautischen Verschuldens oder Feuer an Bord nur für eigenes Verschulden und (3) im Sinne der CMNI genannten Voraussetzungen nicht für nautisches Verschulden, Feuer an Bord oder Mängel des Schiffes haften.
