Microsoft had issues exporting all the parts of a root cert that was
needed for working on computers not in the AD domain in Server 2003.
I think they resolved this issue in Server 2008 and forward but we
ended up having multiple CAs (one for MS and one for everything else)
to resolve this back in
Am 03.02.2015 um 10:57 schrieb Vas:
So none of provide a web interface to view the status of there tickets?
If yes how do you do it?
Because from the user side If I send requests on a regular basis and decided
to see the status of them I would not remember the username and password
that was
Hi,
I have 4 queues with staff being able to assign tickets between the queues.
Sometimes when they get passed to a different queue people forgot to assign
the ticket to someone who works on that queue.
This messy when you run stats on that queue
Does anyone have a script that requires users
On Tue, 3 Feb 2015 16:27:02 -0500 Mitch Kyser mky...@albion.edu wrote:
Thanks for the response. We tried that and could not get it to work
either. Turns out our CA is pretty old and still running on a 2003
box.
We were going to roll out RT to our staff first who all use domain
machines
I need to a queue to my existing rt system. I created the queue, and a
group of users to go with it. However ticket email is not being sent to
anyone but the requestor. Obviously missing something which is
hopefully simple.
On Tue, 03 Feb 2015 12:09:48 + Mauricio Leite Ferreira da Silva
mauricio.le...@planalto.gov.br wrote:
Does anybody Know what can be happening?
Upgrading to 4.2.7 or higher will resolve
https://issues.bestpractical.com/Ticket/Display.html?id=22991 and allow
you to see the actual error.
On Tue, 3 Feb 2015 15:43:05 + Guadagnino Cristiano
guadagnino.cristi...@creval.it wrote:
I did this: I took a backup of my production RT and restored it on
our testing environment. I perused rt-validator till I had no more
warnings (well, I still have a few warnings related to articles: it
Le 19/05/2014 15:02, k...@rice.edu a écrit :
On Mon, May 19, 2014 at 02:41:19PM +0200, Olivier Lumineau wrote:
Hi,
we are using RT 3.8.7, and to filter spam more efficiently, I wanted
to know if there was an easy way in RT to limit ticket recipients
(to + cc + bcc) .
I don't want more than 10
Alex,
I did this: I took a backup of my production RT and restored it on our testing
environment.
I perused rt-validator till I had no more warnings (well, I still have a few
warnings related to articles: it seems rt-validator cannot fix them).
Then I created a test ticket and resolved it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/02/15 11:02, Sam Wilson wrote:
As with Nathan, we use Shibboleth SP and apache to authenticate
users via our internal SSO connected to LDAP. This will provision
their accounts as well as provide them with up to date
passwords.
It sounds
Does anybody Know what can be happening?
I am using rt-crontool Action:
rt-crontool --search RT::Search::FromSQL --search-arg (Status='stalled' AND
Queue=3 AND Priority!=75) --action MyAction::RT::Action::Verify
I am having a critical ERROR:
[Tue Feb 3 11:56:42 2015] [critical]: ERROR when
Well we finally figured out that the mailgate did not like our local CA.
Went and bought a Thawte cert for RT and now everything is working as it
should. The lesson here is spend the money and get a real cert!
--
View this message in context:
On 02/03/2015 12:09 PM, mkyser wrote:
Well we finally figured out that the mailgate did not like our local CA.
Went and bought a Thawte cert for RT and now everything is working as it
should. The lesson here is spend the money and get a real cert!
I wish I had gotten to this earlier. There's
Thank you Alex for the reply.
Do you think there is a way to make it instead to create an initial password
for every ticket it receives? Regardless if the sender has send a request
before?
Thank you
Vas
--
View this message in context:
As with Nathan, we use Shibboleth SP and apache to authenticate users
via our internal SSO connected to LDAP. This will provision their
accounts as well as provide them with up to date passwords.
It sounds like external auth might be an option worth considering.
Sam.
On Tue, Feb 3, 2015 at 8:15
So none of provide a web interface to view the status of there tickets?
If yes how do you do it?
We do provide our users access to the self-service web UI. We have the
usernames and
passwords in LDAP, and RT uses RT::Authen::ExternalAuth for
authentication. Of course,
the users must remember
I believe that what you're asking is not possible.
RT doesn't store passwords, and so it can't retrieve previous passwords for
display in an email.
It can only display the initial password because it manages the creation of
that initial password, and therefore can take a copy.
On 3 Feb 2015 8:30
So none of provide a web interface to view the status of there tickets?
If yes how do you do it?
Because from the user side If I send requests on a regular basis and decided
to see the status of them I would not remember the username and password
that was generated on my first ever request which
Has anyone else come across this ?
Thank you
Vas
--
View this message in context:
http://requesttracker.8502.n7.nabble.com/Autoreply-Template-Script-tp59459p59505.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.
And in the process reset user passwords on every ticket? That sounds wrong too
On 3 Feb 2015, at 19:39, Vas vk...@cam.ac.uk wrote:
Thank you Alex for the reply.
Do you think there is a way to make it instead to create an initial password
for every ticket it receives? Regardless if the
Hi Tim
Thanks for the response. We tried that and could not get it to work
either. Turns out our CA is pretty old and still running on a 2003 box.
We were going to roll out RT to our staff first who all use domain machines
that include our root CA cert already. The web portion worked fine. We
21 matches
Mail list logo
