Re: [rt-users] plugins link to module file, not package file
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 a...@peters.net 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
Re: [rt-users] Make more root or administrator users?
On Wed, 9 Jul 2014, Mauricio Tavares wrote: On Wed, Jul 9, 2014 at 12:28 PM, IT Guy zachary.neub...@usu.edu wrote: As of now, the only user able to manage the system as a whole is the user called root, which was created when I set up RT. However, there are three users to whom I would like to grant all the same rights that root has, without everyone sharing that login. How can I do this? Make the as admin users. But ask yourself if you want to make them full admins or just have admin rights in specific groups. o If full admins, go to /Admin/Global/UserRights.html and set them as superuser. o If admins for a given group, go to the User Rights page for said group and knock yourself out. [ ... ] Another alternative (i.e., besides making the users admins individually) is to create an admin group, give it superuser privileges (under Group Rights rather than User Rights), and then put those users in that group. In some ways, this is easier to manage. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Customizing newest unowned tickets search with user-specific data?
Anybody have any suggestions for this? Thanks. On Mon, 23 Jun 2014, Milt Epstein wrote: Greetings. I'm trying to customize the 10 newest uowned tickets search (the one that appears on the main page by default, I believe). I get to the page to edit the predefined Search - Unowned Tickets search, and it shows the logic for the search: Owner = 'Nobody' AND ( Status = 'new' OR Status = 'open' ) I want to exclude tickets in a certain queue, which by itself is pretty straightforward, just add: AND Queue != 'somequeue' But that's not quite what I want to do. First, I should say that we have groups organized per queue, so that for instance we have a group 'rt-somequeue' with access to the queue 'somequeue'. What I really want to do in the logic above, is exclude that queue unless the user is in that corresponding group, something like: AND ( Queue != 'somequeue' OR User in group 'rt-somequeue' ) Is there a way to do this, either using the criteria listed on the Query Builder page (which seems to be all ticket-related), or by directly editing the search? Thanks. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Customizing newest unowned tickets search with user-specific data?
Thanks for that suggestion. In fact, what you say makes sense, and does work for the most part. But, we have a certain number of admin users (such as myself), who can see tickets in multiple queues. I was trying to set up something that would work for those users (we have certain queues that are separate enough that we would prefer not to see tickets in those queues). Sounds like we may just have to live with this though. On Tue, 1 Jul 2014, Alex Peters wrote: I don't believe that you can achieve this with Ticket SQL, but there is another potential solution: You mention that the users are in groups for the queues relevant to them. If you configure RT so that the users can't see tickets in queues whose groups the users don't belong to, you would get the desired result without modifying the search. Whether this is acceptable in your case depends on whether your users need to see tickets in queues outside their group memberships. On 24/06/2014 2:57 am, Milt Epstein mepst...@illinois.edu wrote: Greetings. I'm trying to customize the 10 newest uowned tickets search (the one that appears on the main page by default, I believe). I get to the page to edit the predefined Search - Unowned Tickets search, and it shows the logic for the search: Owner = 'Nobody' AND ( Status = 'new' OR Status = 'open' ) I want to exclude tickets in a certain queue, which by itself is pretty straightforward, just add: AND Queue != 'somequeue' But that's not quite what I want to do. First, I should say that we have groups organized per queue, so that for instance we have a group 'rt-somequeue' with access to the queue 'somequeue'. What I really want to do in the logic above, is exclude that queue unless the user is in that corresponding group, something like: AND ( Queue != 'somequeue' OR User in group 'rt-somequeue' ) Is there a way to do this, either using the criteria listed on the Query Builder page (which seems to be all ticket-related), or by directly editing the search? Thanks. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] non-admin user editing custom field values
OK, I see. That permission, AdminCustomFieldValues, I see in two places under Configuration: Configuration, Custom Field, the particular custom field, Group Rights Configuration, Global, Group Rights I assume the difference between these is kind of like the other case, the first is specific to the particular custom field, the second is global to all custom fields. Thanks again. On Fri, Jun 20, 2014 at 12:25:52PM -0500, Milt Epstein wrote: Thanks very much! It was the ShowConfigTab permission that did it. I had a feeling there was another access they needed in order to be able to get to the place where they could modify the custom fields' values. I found ShowConfigTab under Configuration, Global, Group Rights. BTW, the other permission is called ModifyCustomField -- apparently it was earlier called ModifyObjectCustomFieldValues, but then shortened. ModifyCustomField lets you set a value for a CF on the object where it is applied (so let's you pick a value for a CF on a ticket). The right I was thinking of is called AdminCustomFieldValues which lets you add/remove values from a select CF but doesn't let you change other things about the CF (like AdminCustomField would). -kevin Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] Customizing newest unowned tickets search with user-specific data?
Greetings. I'm trying to customize the 10 newest uowned tickets search (the one that appears on the main page by default, I believe). I get to the page to edit the predefined Search - Unowned Tickets search, and it shows the logic for the search: Owner = 'Nobody' AND ( Status = 'new' OR Status = 'open' ) I want to exclude tickets in a certain queue, which by itself is pretty straightforward, just add: AND Queue != 'somequeue' But that's not quite what I want to do. First, I should say that we have groups organized per queue, so that for instance we have a group 'rt-somequeue' with access to the queue 'somequeue'. What I really want to do in the logic above, is exclude that queue unless the user is in that corresponding group, something like: AND ( Queue != 'somequeue' OR User in group 'rt-somequeue' ) Is there a way to do this, either using the criteria listed on the Query Builder page (which seems to be all ticket-related), or by directly editing the search? Thanks. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] non-admin user editing custom field values
Kevin, Thanks very much! It was the ShowConfigTab permission that did it. I had a feeling there was another access they needed in order to be able to get to the place where they could modify the custom fields' values. I found ShowConfigTab under Configuration, Global, Group Rights. BTW, the other permission is called ModifyCustomField -- apparently it was earlier called ModifyObjectCustomFieldValues, but then shortened. On Fri, 20 Jun 2014, Kevin Falcone wrote: On Thu, Jun 19, 2014 at 02:41:53PM -0500, Milt Epstein wrote: Can the users of this queue (who are not general RT admins) modify these custom fields' values? If so, how? The ModifyCustomFieldValues right is what you want. The users will also need ShowConfigTab in order to see the right menus to get to the Custom Field editing page. On a custom field's page, I see that there is also a Group Rights link/page, with similar permissions as the above two -- View custom fields (SeeCustomField) under the General rights tab, and Add, modify and delete custom field values for objects (ModifyCustomField) under the Rights for Staff tab. How do these permissions differ from the above two? Are they needed in addition to or instead of them? Should they allow these users to modify these values? Rights granted on the Queue to a group apply to ALL CFs applied to that Queue. Rights granted to a CF apply only to that CF, but independent of which queues it is applied to. -kevin Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] non-admin user editing custom field values
Greetings. I'm using RT 4.0.2. I set up some custom fields specific to a queue. They are each of the type Select one value, and for each of them I defined a few values. Can the users of this queue (who are not general RT admins) modify these custom fields' values? If so, how? We have things set up where basically for each queue there's a group that has access to it. On the queue's Group Rights page, I gave this group View custom field values (SeeCustomField) under the General rights tab, and Modify custom field values (ModifyCustomField) under the Rights for Staff tab. Should that allow these users (i.e., members of this group) to modify the custom fields' values? One of the users tried, but couldn't see a way to do it. Do they need some other access? On a custom field's page, I see that there is also a Group Rights link/page, with similar permissions as the above two -- View custom fields (SeeCustomField) under the General rights tab, and Add, modify and delete custom field values for objects (ModifyCustomField) under the Rights for Staff tab. How do these permissions differ from the above two? Are they needed in addition to or instead of them? Should they allow these users to modify these values? Thanks. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) mepst...@illinois.edu -- RT Training - Boston, September 9-10 http://bestpractical.com/training
