[rt-users] suggestions for improvement

[Jo Rhett]

On Dec 11, 2014, at 11:26 AM, Alex Vandiver  wrote:
> Moving to the topic at hand: the links we provide are to the
> documentation of the module, not to the distribution page.  This is
> intentional, soas to provide the user with a longer description of the
> extension first, to let them make a more informed decision as to whether
> the extension suits their needs.

Linking to the documentation makes sense. Linking to the module docs without 
any clear installation instructions does not.

The concern here is that the installation process is not clear, and is 
*nowhere* made clear, that the extension is more than the single file. Many, 
many projects have extensions which are single files. Modern sysadmins install 
JS modules, Java plugins, browser plugins, Python modules, Ruby modules, Puppet 
modules, Chef cookbooks, Perl modules, etc. Even some of these configuration 
management packages are single files. The ones which aren’t contain clear 
instructions on how to install them.

Even if one is an established Perl hacker, a large majority of CPAN modules are 
a single .pm file. The fact that one must download the entire package, not just 
the singular file, is not stated anywhere. This deserves clarity.

In the current situation a person must be both an RT person and a Perl hacker 
to find their way through installing an extension. That’s a high bar that I 
don’t think helps your business. As I pointed out, I have more than 20 years of 
Perl experience and 10 years experience with RT and because I do things other 
than work on RT, and I was in the middle of a major number upgrade where 
everything could have changed, I made no assumption that extensions weren’t a 
single file. I’m a sysadmin who spent the last 16 months dealing with other 
software for which the extensions were a single file, and NOTHING IN YOUR DOCS 
TOLD ME OTHERWISE.

Every system for which a plugin is multiple files focuses on, and makes 
obvious, how to install the plugin. To pick a random example, when I find an 
extension on the Puppet forge, the largest piece of text on that very first 
page is "Use this command to install the latest compatible version:” which is a 
specific command to install that module. Beneath it in smaller text is another 
link "Learn about installing and upgrading modules” which covers the general 
case. (see links at bottom of message)

Obviously, if a confused person comes here Alex Peters’ will abuse them and 
talk down to them about how they’re stupid for not using CPAN to download an 
install the module, even though there’s no documentation for doing that either. 
You would at least need to pass -I /opt/rt4/lib to your CPAN invocation for 
this to work. So they’ll get insulted, and it still won’t work. Do you really 
think they’ll post again? Or will they hire someone like me to replace RT 
instead?

So far we have:
 1. Innocent person won’t know what to do
 2. Experienced perl hacker will probably do the wrong thing on instinct

Best Practical is a professional company who makes money selling services to 
people using RT.  In my experience as a consultant, I keep getting called out 
to sites to replace RT with “something that works”. I usually find fairly 
trivial problems in the installation which solve the customer’s problems, but 
which could not be resolved from the documentation. Experienced sysadmins 
follow the available instructions, things blow up — and they blame BP. Which 
frankly has some validity. It gives the sysadmin the impression that you can’t 
be bothered, and this attitude is projected onto your company and its support 
programs.

> I'd be open to switching existing links from
> http://bestpractical.com/rt/extensions.html to point to the metacpan
> pages, rather than the search.cpan.org ones -- I, personally, have come
> to much prefer metacpan's UI.  I'm unclear if that would address Jo's
> original confusion, however.

I believe that anything which solves the basic confusion here will be an 
improvement. Links as simple as the following would be a big improvement.
[Documentation] [Download]

Something like what Puppet’s Forge, Ruby’s Supermarket, or any of these more 
successful extension lists do would be much much better.
https://forge.puppetlabs.com/puppetlabs/stdlib
http://cookbooks.opscode.com/cookbooks/mcollective
..etc

I think the poor documentation causes BP to lose a lot of potential business, 
and you should consider this a priority.

Or you can continue to allow personal attacks in this support forum, and I’ll 
start ripping RT out everywhere instead of fixing their installations and 
promoting your services to them. I do a lot of RT promotion for free, at zero 
gain to myself. I’m not going to do that in the face of personal attacks.

-- 
Jo Rhett
+1 (415) 999-1798
Skype: jorhett
Net Consonance : net philanthropy to improve open source and internet projects.

[rt-users] moderation and personal attacks

[Jo Rhett]

On Dec 11, 2014, at 11:26 AM, Alex Vandiver  wrote:
> And I'm going to step in before this gets any further out of hand.  The
> amount of high dudgeon in this thread is not acceptable.  If it
> continues, I _will_ turn on list moderation.  Don't make me turn this
> car around, etc, etc.

I would appreciate it. I don’t come here to be personally insulted and 
attacked. What happened today is completely unacceptable in any business forum.

> One concept to bear in mind is that replies to the mailing list are not
> merely addressed to the author of the previous post, but for the
> entirety of the mailing list, as well as any who come across it in
> searches later.  If one finds a post overbearingly patronizing, remember
> that others who are less well-educated may yet find it useful.

Did you read that multi-paragraph personal assault he posted? Do read that and 
find a single sentence in the first page of his reply that isn’t a personal 
attack. Please do find and share with me a single statement in those first 
three paragraphs that is educational or helpful to new members. (other than 
perhaps to warn them that they’re going to be abused if they ask questions 
here?)

I had a very real point to make based on reality, with Alex Peters took and 
deliberately misrepresented so that he could check off every single box on the 
“how to be a complete and total jerk to a sincere request” bingo card. That is 
what happened here.

This is completely unacceptable in any forum. I am explicitly requesting that 
you enable moderation of this forum and prevent further attacks like this.

-- 
Jo Rhett
+1 (415) 999-1798
Skype: jorhett
Net Consonance : net philanthropy to improve open source and internet projects.

Re: [rt-users] *Some* attachments not clickable links?

[Alex Peters]

Are you getting any strange output in RT's debug log when you display the
ticket?

Would you be willing to paste what HTML is being generated for the affected
Attachments links?

A quick look at the Ticket/Elements/ShowAttachments Mason component
suggests that the links should always be clickable, even if they're
malformed (and wouldn't necessarily go to an attachment).  Seeing the HTML
for a bad one might help someone in identifying what else might be
contributing to the problem.

On 12 December 2014 at 02:17, Jeff Blaine  wrote:
>
> We're experiencing something odd. Some tickets are not allowing the
> attachments under "Attachments" to be clicked in any way. Just the base
> filename is displayed.
>
> Some (most) tickets work fine.
>
> Any ideas for which rabbit hole to head down in order to figure this out?
>
> RT 4.2.5
>

Re: [rt-users] Disable creation of tickets via email

[Alex Peters]

I see that you want to still accept email replies, so disabling the email
address is not suitable.

You might be able to play with rights, e.g. disabling the Create Ticket
right for the Everyone group, but RT might still link incoming ticket
creation mail to a privileged user by looking at the "From:" address of the
email.

I guess you want web creation only because the web interface presents
custom fields.

You could write a scrip that runs on ticket creation, checks for the
correct entry of custom fields, and if there's a problem, sends a reply
instructing the user to try again using the web form and closes the ticket
as rejected.  Would that be suitable?

On Sat, 6 Dec 2014 12:20 am Fredrik Rambris 
wrote:

> Hi, everybody.
>
> We run an old RT3 and we would like to change how users submit tickets.
> Today they mail in tickets. We want to force them to submit via a web
> form that then create the tickets with the required information.
>
> They should be able to add correspondance to an existing ticket as usual.
>
> I know how to make the webform thingy create tickets via CLI. I just
> want to disable ticket creation via email.
>
> rt: "|/usr/sbin/rt-mailgate --queue 'General' --action correspond 
>
> How can this be done?
>
> [CDON.COM] 
>

Re: [rt-users] Outgoing email text of a closing incident

[Alex Peters]

I'm not familiar with RTIR but for RT, this text would be in a template. Do
templates exist with RTIR?

On Mon, 8 Dec 2014 9:55 pm "Tamás, Szép"  wrote:

> No answers yet so it is still an open question.
>
> More precisely: where can I change the default outgoing email message
> sent by the system to whom the Incident Report came when a whole case
> (e.g. Report,Incidents and Investigations are all solved) is closed?
> Is there a file for it (could not find it yet) or is it in the RT
> database somewhere?
>
> Any help would be appreciated.
>
> Tamas
>
> on 2014.12.03. 14:32 "Tamás, Szép" wrote:
> > Hello all,
> >
> > where can I find and modify the text of the outgoing email when I close
> > a whole Incident?
> >
> > Best regards,
> > Tamas Szep
> > GovCERT-Hungary
> >
>

Re: [rt-users] plugins link to module file, not package file

[Alex Peters]

I support the idea of switching to MetaCPAN, which seems to be in active
development and seems to generally get a lot more right in terms of modern
website development.  Plus, Download links are on the left there instead of
the right.  We've established that this is important. ;)

Since RT extensions can come from many sources, I'd suggest that any RT
documentation on how to download them shouldn't be too specific because
then it might need to be updated when someone finds a new way to host
them.  Maybe "most of them are on CPAN/MetaCPAN and here's a link to a
search that lists most of them" is enough?

Since extension installation procedures are specific to each extension, I
think installation documentation on RT's side would need to be nothing more
than the sentence "consult the downloaded extension's documentation for
installation instructions, especially whether any database changes need to
be made."  I must admit that I'd forgotten about potential database changes
when I wrote everything above.

Re: [rt-users] plugins link to module file, not package file

[Alex Vandiver]

On 12/11/2014 01:14 PM, Milt Epstein wrote:
> Thought I'd chime in here. [...]

And I'm going to step in before this gets any further out of hand.  The
amount of high dudgeon in this thread is not acceptable.  If it
continues, I _will_ turn on list moderation.  Don't make me turn this
car around, etc, etc.

One concept to bear in mind is that replies to the mailing list are not
merely addressed to the author of the previous post, but for the
entirety of the mailing list, as well as any who come across it in
searches later.  If one finds a post overbearingly patronizing, remember
that others who are less well-educated may yet find it useful.

Milt: To clarify, Alex Peters, like the vast majority of the folks on
this list, is a volunteer.  Only those who post from @bestpractical.com
addresses are Best Practical employees.


Moving to the topic at hand: the links we provide are to the
documentation of the module, not to the distribution page.  This is
intentional, soas to provide the user with a longer description of the
extension first, to let them make a more informed decision as to whether
the extension suits their needs.

I'd be open to switching existing links from
http://bestpractical.com/rt/extensions.html to point to the metacpan
pages, rather than the search.cpan.org ones -- I, personally, have come
to much prefer metacpan's UI.  I'm unclear if that would address Jo's
original confusion, however.

We do not currently have a documentation page explaining how to download
and install extensions.  We quite probably should; patches accepted,
bearing in mind that the exact installation steps vary from extension to
extension.

We generally do _no_ recommend using the cpan or cpanm command-line
client to install RT extensions.  Not only does this not suffice for RT
installs that do not live in /opt/rt4, but -- more importantly -- it
skips any database initialization steps that may be documented.  Our
suggested installation path is always to download the .tar.gz from CPAN,
unpack it, and follow its README.

 - Alex

[rt-users] *Some* attachments not clickable links?

[Jeff Blaine]

We're experiencing something odd. Some tickets are not allowing the
attachments under "Attachments" to be clicked in any way. Just the base
filename is displayed.

Some (most) tickets work fine.

Any ideas for which rabbit hole to head down in order to figure this out?

RT 4.2.5

Re: [rt-users] plugins link to module file, not package file

[Milt Epstein]

Thought I'd chime in here.  My background: I've been on this list for
several months; I work at a site that's been using RT for several
years -- I co-manage our installation; I joined the list because I
needed to figure out a few things, and then stayed on it because it
was low volume and generally helpful and informative; mainly I'm a
software developer, and I've been using Perl for over 20 years; I've
also been on many product support mailing lists, for both commercial
and open-source products.

That said, I don't have any problem with what Alex said in this thread
(or any other), and I think the one being out of line here is Jo.
There may have been some inkling of legitimacy to Jo's issue, but I
had never seen it mentioned on the list, and I'd never run into it
myself (I install lots of modules from CPAN, but not too many
RT-related ones).  Alex took the patience to craft a long,
substantial, polite reply to Jo's issue, and Jo responded with
unjustified indignation.  C'mon, if he wasn't trying to be helpful,
would he have wasted his time writing a 130-line long substantive
reply!

What's ironic about this is that Alex is one of the most helpful
people on the list.  Not sure if he works for Best Practical (although
I'm guessing he does), but he replies to many posts on the list.
Looking over the posts I've saved from the list, the posters that
occur most are Alex, Kevin Falcone, and Alex Vandiver (the latter two
post from bestpractical.com email addresses).

If Jo does file a complaint with Best Practical over this, I'd be
happy to file an amicus brief countering it.

Milt Epstein
Applications Developer
Graduate School of Library and Information Science (GSLIS)
University of Illinois at Urbana-Champaign (UIUC)
mepst...@illinois.edu


On Thu, 11 Dec 2014, Jo Rhett wrote:

> The levels of abuse and rudeness here are phenomenal. Alex has got his A-hole 
> meter turned up to full strength. And if this list is moderated at all, I?m 
> asking for Alex to be moderated. I?m filing a formal complaint with Best 
> Practical over this.
> 
> The funniest bit is that his instructions are simply wrong, which further 
> goes to the point that the documentation needs fixing.
> 
> On Dec 11, 2014, at 2:50 AM, Alex Peters  wrote:
> > I don't think there's anything to misunderstand here any more.
> > 
> > The gist of what Jo conveyed is basically this (and it's all verifiably 
> > conveyed in earlier messages):
> > 
> > "I have 20 years of experience with Perl and use CPAN fairly often, yet 
> > when I'm presented with a CPAN link to the main module of a distribution, a 
> > common practice pretty much everywhere, I complain that the links are bad, 
> > ignore the provided Download link because it's on the right side of the 
> > page, manually adjust URLs, manually fetch .pm files, complain about the 
> > usability of this process (which no one else performs), understandably fail 
> > to install the module, admit that I don't know how to install Perl modules, 
> > and somehow attribute this to a fault with RT's documentation, all while 
> > failing to visibly consider that hundreds of people before me have used 
> > this RT Extensions page in its current form without a problem, and that 
> > thousands of people use CPAN in its current form without a problem."
> > 
> > Despite this, I invested quite a bit of time in clarifying the whole 
> > modules-vs.-distributions deal, and that the installation of modules has 
> > nothing to do with downloading individual .pm files.  I intended no offence 
> > or malice, even though I wanted to just come out and say, "this method of 
> > yours for attempting to install a module is completely ill-informed."  I 
> > feel that I was entirely cordial and tactful in my earlier responses; if 
> > anyone else disagrees, I'd definitely appreciate some offline coaching as 
> > to how I could have prevented coming across as rude or insulting in this 
> > instance.
> > 
> > I won't bother to exercise tact here: the crux of the matter is that Jo 
> > didn't/doesn't know how to properly install a module distribution from CPAN 
> > (a fact verified by him asking the questions "How do I get from a .pm file 
> > to an installed module?  Can I manually create the directory structures and 
> > copy these into place?"), and when he was politely alerted to that, he 
> > launched into a sarcastic, snide, ingracious attack on me, seemed to ignore 
> > any advice from multiple people on how to properly install CPAN modules, 
> > and ignored all my other questions geared towards actually improving RT's 
> > documentation for everyone's benefit.  He then topped all of that off by 
> > complaining about being "treated like shit."
> > 
> > While I accept that my responses were clearly not to Jo's taste, I expect 
> > that my explanation of modules vs. module distributions will at least help 
> > others either now or in the future (even though I'm sure I didn't write 
> > anything not already available in Perl's o

Re: [rt-users] plugins link to module file, not package file

[Jo Rhett]

The levels of abuse and rudeness here are phenomenal. Alex has got his A-hole 
meter turned up to full strength. And if this list is moderated at all, I’m 
asking for Alex to be moderated. I’m filing a formal complaint with Best 
Practical over this.

The funniest bit is that his instructions are simply wrong, which further goes 
to the point that the documentation needs fixing.

On Dec 11, 2014, at 2:50 AM, Alex Peters  wrote:
> I don't think there's anything to misunderstand here any more.
> 
> The gist of what Jo conveyed is basically this (and it's all verifiably 
> conveyed in earlier messages):
> 
> "I have 20 years of experience with Perl and use CPAN fairly often, yet when 
> I'm presented with a CPAN link to the main module of a distribution, a common 
> practice pretty much everywhere, I complain that the links are bad, ignore 
> the provided Download link because it's on the right side of the page, 
> manually adjust URLs, manually fetch .pm files, complain about the usability 
> of this process (which no one else performs), understandably fail to install 
> the module, admit that I don't know how to install Perl modules, and somehow 
> attribute this to a fault with RT's documentation, all while failing to 
> visibly consider that hundreds of people before me have used this RT 
> Extensions page in its current form without a problem, and that thousands of 
> people use CPAN in its current form without a problem."
> 
> Despite this, I invested quite a bit of time in clarifying the whole 
> modules-vs.-distributions deal, and that the installation of modules has 
> nothing to do with downloading individual .pm files.  I intended no offence 
> or malice, even though I wanted to just come out and say, "this method of 
> yours for attempting to install a module is completely ill-informed."  I feel 
> that I was entirely cordial and tactful in my earlier responses; if anyone 
> else disagrees, I'd definitely appreciate some offline coaching as to how I 
> could have prevented coming across as rude or insulting in this instance.
> 
> I won't bother to exercise tact here: the crux of the matter is that Jo 
> didn't/doesn't know how to properly install a module distribution from CPAN 
> (a fact verified by him asking the questions "How do I get from a .pm file to 
> an installed module?  Can I manually create the directory structures and copy 
> these into place?"), and when he was politely alerted to that, he launched 
> into a sarcastic, snide, ingracious attack on me, seemed to ignore any advice 
> from multiple people on how to properly install CPAN modules, and ignored all 
> my other questions geared towards actually improving RT's documentation for 
> everyone's benefit.  He then topped all of that off by complaining about 
> being "treated like shit."
> 
> While I accept that my responses were clearly not to Jo's taste, I expect 
> that my explanation of modules vs. module distributions will at least help 
> others either now or in the future (even though I'm sure I didn't write 
> anything not already available in Perl's own documentation).
> 
> Anyway, to keep things on topic, my summarised view on this thread's actual 
> subject matter is as follows:
> RT's documentation currently doesn't mention that RT extensions are in fact 
> Perl modules/distributions.  It should.
> RT's documentation currently doesn't state that the majority (but not all) of 
> RT extensions can be found on CPAN.  It probably should, with a link to CPAN 
> search results within the appropriate namespace/s (RT::Extension, RTx, ...?).
> RT's documentation currently doesn't state where non-CPAN-sourced RT 
> extensions can be found.  It probably could, but that probably wouldn't be 
> very useful.
> RT's documentation currently doesn't detail how to install modules from CPAN. 
>  It shouldn't.  Installation of CPAN module distributions is a Perl concern, 
> not an RT concern.  I would consider a link to Perl documentation describing 
> the process to be the most documentation required at RT's level on this.
> RT's documentation currently doesn't detail how to install modules from 
> non-CPAN sources.  It shouldn't.  Installation of non-CPAN-sourced module 
> distributions is a Perl concern, not an RT concern.
> I don't suppose anyone is interested in patching the docs to that effect, or 
> suggesting other edits related to this issue?
> 
> 
> On 11 December 2014 at 17:35,  wrote:
> Jo, I honestly think that Alex simply misunderstood you. That's not
> uncommon in these kind of lists. Better to not attribute to malice what
> can be explained by miscommunication. Even in the very rare occasion that
> it _is_ malice, you are better off assuming the best of people.
> 
> - Rick
> 
> > I’ve been using Perl for 20 years now. I grok perl.
> >
> > Good run with the insults and rudeness. Because yeah, that’s a great way
> > to treat someone who’s pointing out a way to improve the usability of
> > something. Treat them like dirt, and 

Re: [rt-users] REST and umlauts in Custom Field names

[Christian Loos]

Am 11.12.2014 um 15:31 schrieb Jasper Olbrich:
> Hello,
> 
> I'm trying to use REST to create tickets in a queue that uses Custom
> Fields. It works well for CFs without umlauts, but I couldn't find a way
> yet to fill the CF "Größe".
> 
> I'm sending the data with Python's urllib module, the request body looks
> like
> 
> content=id%3A+ticket%2Fnew%0AQueue%3A+Test-Queue%0ARequestor%3A+jasper.olbrich%40students.uni-marburg.de%0ASubject%3A+Encoding+von+CustomFields%0AText%3A+%3CThe+ticket+content%3E%0ACF-Gr%C3%B6%C3%9Fe%3A+A0%0ACF-working%3A+working&user=$user&pass=$pass
> 
> 
> where CF-Gr%C3%B6%C3%9Fe is the urlencoded CF name. I also tried to
> circumvent urlencoding for this particular CF name:
> 
> content=id%3A+ticket%2Fnew%0AQueue%3A+Test-Queue%0ARequestor%3A+jasper.olbrich%40students.uni-marburg.de%0ASubject%3A+Encoding+von+CustomFields%0AText%3A+%3CThe+ticket+content%3E%0ACF-working%3A+working%0ACF-Gr\xc3\xb6\xc3\x9fe%3A+A0&user=$user&pass=$pass
> 
> 
> "\xc3\xb6\xc3\x9" is the byte sequence for utf-8 encoded unicode "öß".
> 
> I also tried to add "charset=utf-8" to the content encoding header, but
> to no avail.
> 
> Is it possible to write CFs via REST? Reading works fine.
> 

Hi,

use CF-123 (with 123 being the CF id).

Chris

[rt-users] REST and umlauts in Custom Field names

[Jasper Olbrich]

Hello,

I'm trying to use REST to create tickets in a queue that uses Custom 
Fields. It works well for CFs without umlauts, but I couldn't find a way 
yet to fill the CF "Größe".


I'm sending the data with Python's urllib module, the request body looks 
like


content=id%3A+ticket%2Fnew%0AQueue%3A+Test-Queue%0ARequestor%3A+jasper.olbrich%40students.uni-marburg.de%0ASubject%3A+Encoding+von+CustomFields%0AText%3A+%3CThe+ticket+content%3E%0ACF-Gr%C3%B6%C3%9Fe%3A+A0%0ACF-working%3A+working&user=$user&pass=$pass

where CF-Gr%C3%B6%C3%9Fe is the urlencoded CF name. I also tried to 
circumvent urlencoding for this particular CF name:


content=id%3A+ticket%2Fnew%0AQueue%3A+Test-Queue%0ARequestor%3A+jasper.olbrich%40students.uni-marburg.de%0ASubject%3A+Encoding+von+CustomFields%0AText%3A+%3CThe+ticket+content%3E%0ACF-working%3A+working%0ACF-Gr\xc3\xb6\xc3\x9fe%3A+A0&user=$user&pass=$pass

"\xc3\xb6\xc3\x9" is the byte sequence for utf-8 encoded unicode "öß".

I also tried to add "charset=utf-8" to the content encoding header, but 
to no avail.


Is it possible to write CFs via REST? Reading works fine.

--
Jasper

[rt-users] How to delete a asset record from the Asset Tracker using shredder

[Shrikant Mhatre]

Hi Team,

I wanted the steps to delete a wrongly created asset from the Asset 
Tracker ( 1.02) Database in RT 4.2.9


I cannot find any write up apart from the "delete" section of the asset 
tracker extension documentation.


--

*Shrikant Mhatre*

*IOT InfraStructure & Energy Services Ltd*

Plot Y2, CEAT Tyre Road,

Near Nahur Railway Station,

Bhandup (West), Mumbai 400078.

Contact : +91 22 61524 500/600/700/800/900

_www.iotinfraenergy.com _





Disclaimer: This e-mail transmission and any documents, files, or previous 
e-mail messages appended or attached to it, may contain information that is 
confidential or legally privileged. If you are not the intended recipient, or a 
person responsible for delivering it to the intended recipient, you are hereby 
notified that you must not read this transmission and that any disclosure, 
copying, printing, distribution, or use of the information contained or 
attached to this transmission is STRICTLY PROHIBITED. If you have received this 
transmission in error, please immediately notify the sender by return e-mail 
message (shrikant.mha...@iotgroup.in) and delete the original transmission, its 
attachments, and any copies without reading or saving in any manner. Thank you.

Re: [rt-users] Default Configuration RT

[Alex Peters]

That's the correct utility for dropping a MySQL database, but not the
correct command line arguments.  A quick Google search for "mysql drop
database" should help you achieve this:

http://www.wikihow.com/Delete-a-MySQL-Database

On 10 December 2014 at 23:36, Renato Gentil 
wrote:

> Alex,
>
> I'm trying to drop but I'm getting the error attached.
> I'm using the following command:
>
> mysqladmin -u root -p  drop
>
> but then I got the error attached and I also tried:
>
> mysqladmin -u root -p drop
> password: 
>
> another error attached.
>
> Thanks,
>
>
> Renato Gentil
>
>
> --
> Date: Wed, 10 Dec 2014 23:20:30 +1100
> Subject: Re: [rt-users] Default Configuration RT
> From: a...@peters.net
> To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com
>
>
> Hi Renato,
>
> What exactly did you try, and what happened?  Going into MySQL, dropping
> the database (or all of its tables) and running the sbin/rt-setup-database
> script would restore all of your templates and scrips.  Specifically, you
> would probably do this if your MySQL user has the permissions to drop the
> database:
>
> $ cd 
> $ sbin/rt-setup-database --action drop,create,schema,acl,coredata,insert
> --dba  --prompt-for-dba-password
>
> You can pass "--help" to the rt-setup-database script for further
> details.  Remove "drop,create," from the above line if you'd like to
> manually remove all of the tables first (using mysql).
>
> Please let us know how you go (using "Reply All").
>
> On 10 December 2014 at 23:02, Renato Gentil 
> wrote:
>
> Hi Alex,
>
> I tried it but didn't work for me. Basically I'm trying to restore the
> default templates and scripts because I have deleted some of them and now
> some of our features have been gone with them.
>
> Can you help me with that ?
>
> thanks,
>
>
>
> Renato Gentil
>
>
> --
> From: a...@peters.net
> Date: Wed, 10 Dec 2014 01:12:06 +
> Subject: Re: [rt-users] Default Configuration RT
> To: renatorodrigo...@hotmail.com; rt-users@lists.bestpractical.com
>
> You could drop the database and set it up again, or also completely
> uninstall and reinstall RT.
>
>
>

Re: [rt-users] plugins link to module file, not package file

[Alex Peters]

I don't think there's anything to misunderstand here any more.

The gist of what Jo conveyed is basically this (and it's all verifiably
conveyed in earlier messages):

"I have 20 years of experience with Perl and use CPAN fairly often, yet
when I'm presented with a CPAN link to the main module of a distribution, a
common practice pretty much everywhere, I complain that the links are bad,
ignore the provided Download link because it's on the right side of the
page, manually adjust URLs, manually fetch .pm files, complain about the
usability of this process (which no one else performs), understandably fail
to install the module, admit that I don't know how to install Perl modules,
and somehow attribute this to a fault with RT's documentation, all while
failing to visibly consider that hundreds of people before me have used
this RT Extensions page in its current form without a problem, and that
thousands of people use CPAN in its current form without a problem."

Despite this, I invested quite a bit of time in clarifying the whole
modules-vs.-distributions deal, and that the installation of modules has
nothing to do with downloading individual .pm files.  I intended no offence
or malice, even though I wanted to just come out and say, "this method of
yours for attempting to install a module is completely ill-informed."  I
feel that I was entirely cordial and tactful in my earlier responses; if
anyone else disagrees, I'd definitely appreciate some offline coaching as
to how I could have prevented coming across as rude or insulting in this
instance.

I won't bother to exercise tact here: the crux of the matter is that Jo
didn't/doesn't know how to properly install a module distribution from CPAN
(a fact verified by him asking the questions "How do I get from a .pm file
to an installed module?  Can I manually create the directory structures and
copy these into place?"), and when he was politely alerted to that, he
launched into a sarcastic, snide, ingracious attack on me, seemed to ignore
any advice from multiple people on how to properly install CPAN modules,
and ignored all my other questions geared towards actually improving RT's
documentation for everyone's benefit.  He then topped all of that off by
complaining about being "treated like shit."

While I accept that my responses were clearly not to Jo's taste, I expect
that my explanation of modules vs. module distributions will at least help
others either now or in the future (even though I'm sure I didn't write
anything not already available in Perl's own documentation).

Anyway, to keep things on topic, my summarised view on this thread's actual
subject matter is as follows:

   - RT's documentation currently doesn't mention that RT extensions are in
   fact Perl modules/distributions.  It should.
   - RT's documentation currently doesn't state that the majority (but not
   all) of RT extensions can be found on CPAN.  It probably should, with a
   link to CPAN search results within the appropriate namespace/s
   (RT::Extension, RTx, ...?).
   - RT's documentation currently doesn't state where non-CPAN-sourced RT
   extensions can be found.  It probably could, but that probably wouldn't be
   very useful.
   - RT's documentation currently doesn't detail how to install modules
   from CPAN.  It shouldn't.  Installation of CPAN module distributions is a
   Perl concern, not an RT concern.  I would consider a link to Perl
   documentation describing the process to be the most documentation required
   at RT's level on this.
   - RT's documentation currently doesn't detail how to install modules
   from non-CPAN sources.  It shouldn't.  Installation of non-CPAN-sourced
   module distributions is a Perl concern, not an RT concern.

I don't suppose anyone is interested in patching the docs to that effect,
or suggesting other edits related to this issue?


On 11 December 2014 at 17:35,  wrote:

> Jo, I honestly think that Alex simply misunderstood you. That's not
> uncommon in these kind of lists. Better to not attribute to malice what
> can be explained by miscommunication. Even in the very rare occasion that
> it _is_ malice, you are better off assuming the best of people.
>
> - Rick
>
> > I’ve been using Perl for 20 years now. I grok perl.
> >
> > Good run with the insults and rudeness. Because yeah, that’s a great way
> > to treat someone who’s pointing out a way to improve the usability of
> > something. Treat them like dirt, and talk down to them like they’ve never
> > used Perl before.
> >
> > I’ll stop offering advice on ways to improve the UI. Unintelligible and
> > prone to confusion on the part of people isn’t my problem. I’m not going
> > to be helpful if I get treated like shit when I’m trying to make
> someone’s
> > profit-making production better and more likely to be used.
> >
> > I forgot why I dropped this list. Thanks for reminding me.
> >
> > On Dec 9, 2014, at 5:10 AM, Alex Peters  wrote:
> >> I feel that there are actually several issues to di

Re: [rt-users] RT-Extension-AceEditor

[Rémi]

Hi Torsten,
You're right, thanks for the feedback,
I made a correction for the display order.

Rémi

2014-12-11 8:12 GMT+01:00 Brumm, Torsten / Kuehne + Nagel / Ham GI-ID <
torsten.br...@kuehne-nagel.com>:

>  Hi Remi,
>
> nice work, love this, but the Custom Action Prep Code and Custom Condition
> are changed in the display order?!?
>
>
>
>
>
> Torsten
>
>
>
> *Von:* rt-users [mailto:rt-users-boun...@lists.bestpractical.com] *Im
> Auftrag von *Rémi
> *Gesendet:* Mittwoch, 10. Dezember 2014 18:23
> *An:* rt Users
> *Betreff:* [rt-users] RT-Extension-AceEditor
>
>
>
> Hi list,
>
> Here is an extension that replace the default scrip edition textarea with
> the embeded Ace editor (http://ace.c9.io)
>
>
> https://github.com/valmiRe/rt-extension-aceeditor
>
> Rémi
>
>
> 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.
>