Is there any way to grant public read-only access to an RT web site
such that anyone can see what open tickets there are and who is
working on them?
Thanks, and sorry if this is in the FAQ (I did look, but did not see
anything on public access).
BruceBruce Badger wrote:
Is there any way to grant public read-only access to an RT web site
such that anyone can see what open tickets there are and who is
working on them?
There’s no “official” way/option/etc at the moment, though something may
be in the works for the rt.cpan.org migration we’re doing. For now I
suggest you create a user “guest” with password “guest” and publicize
that on the login page. Make sure the guest user only has rights to see
things, not modify stuff (including itself, so guests can’t change the
password and lock other guests out).
Cheers,
Tom
(Forgot to send to the list the first time…)
Bruce Badger wrote:
Is there any way to grant public read-only access to an RT web site
such that anyone can see what open tickets there are and who is
working on them?There’s no “official” way/option/etc at the moment, though something may
be in the works for the rt.cpan.org migration we’re doing. For now I
suggest you create a user “guest” with password “guest” and publicize
that on the login page. Make sure the guest user only has rights to see
things, not modify stuff (including itself, so guests can’t change the
password and lock other guests out).
I was going to approach this problem at a lower level. If I’ve got this
right, the default ACLs that RT sets up (at least for MySQL and PostgreSQL)
specify that RT should be allowed to select, insert, update, and delete. If
instead the ACLs were modified so that RT could only select, I think that
would accomplish the goal. I haven’t set this up yet, so I don’t yet know
yet how RT will handle this. Perhaps that’s a question for the list. This
technique will require two RT installations sharing one db - one internal,
which has full permissions and will run rt-mailgate; and the other external,
which will only be allowed to view.
James
James Chamberlain wrote:
I was going to approach this problem at a lower level. If I’ve got this
right, the default ACLs that RT sets up (at least for MySQL and
PostgreSQL) specify that RT should be allowed to select, insert, update,
and delete. If instead the ACLs were modified so that RT could only
select, I think that would accomplish the goal. I haven’t set this up
yet, so I don’t yet know yet how RT will handle this. Perhaps that’s a
question for the list. This technique will require two RT installations
sharing one db - one internal, which has full permissions and will run
rt-mailgate; and the other external, which will only be allowed to view.
I’m not sure how RT will react to this. For one, it won’t be able to
store session information in the database, though it will still want
users to log in (unless you cut that part out). I doubt it will work as
expected/desired, but have a go at it and see what happens. 
Tom
James Chamberlain wrote:
I was going to approach this problem at a lower level. If I’ve
got this right, the default ACLs that RT sets up (at least for
MySQL and PostgreSQL) specify that RT should be allowed to select,
insert, update, and delete. If instead the ACLs were modified so
that RT could only select, I think that would accomplish the
goal. I haven’t set this up yet, so I don’t yet know yet how RT
will handle this. Perhaps that’s a question for the list. This
technique will require two RT installations sharing one db - one
internal, which has full permissions and will run rt-mailgate; and
the other external, which will only be allowed to view.I’m not sure how RT will react to this. For one, it won’t be able
to store session information in the database, though it will still
want users to log in (unless you cut that part out). I doubt it
will work as expected/desired, but have a go at it and see what
happens.
Then perhaps it would work to give the external instance of RT full
privileges on whichever tables are used for session information, but
only select on all others? I’m assuming this would be the
“sessions” table, possibly “Users” - any others?
James
There’s no “official” way/option/etc at the moment, though something may
be in the works for the rt.cpan.org migration we’re doing. For now I
suggest you create a user “guest” with password “guest” and publicize
that on the login page. Make sure the guest user only has rights to see
things, not modify stuff (including itself, so guests can’t change the
password and lock other guests out).
Also useful, user can put &user=guest&password=guest on the end of a link
and people who are not logged in will automatically view the page as guest,
and people who are logged in will stay themselves, handy in emails, etc.
www.suave.net - Anthony Ball - ant@suave.net
OSB - http://rivendell.suave.net/Beer
Great compassion is the root of all forms of worship.
Tom,
Sorry to come back to this after such a long time, but we have just
resolved a problem in getting email to our RT system. So, back to
getting the read-only access …On 8/3/05, Thomas Sibley trs@bestpractical.com wrote:
There’s no “official” way/option/etc at the moment, though something may
be in the works for the rt.cpan.org migration we’re doing. For now I
suggest you create a user “guest” with password “guest” and publicize
that on the login page. Make sure the guest user only has rights to see
things, not modify stuff (including itself, so guests can’t change the
password and lock other guests out).
We are using RT 3.4.1 as packaged for Debian stable (sarge). I am
looking at the Configuration>Users page and I can’t see how I set
things so this guest user is not able to modify their own password, or
create new requests.
Could you please point me to the relevant bit of the interface, or
system documentation?
Many thanks,
Bruce
Make the most of your skills - with OpenSkills
http://www.openskills.org/
Hi Bruce,
There’s no “official” way/option/etc at the moment, though something may
be in the works for the rt.cpan.org migration we’re doing. For now I
suggest you create a user “guest” with password “guest” and publicize
that on the login page. Make sure the guest user only has rights to see
things, not modify stuff (including itself, so guests can’t change the
password and lock other guests out).We are using RT 3.4.1 as packaged for Debian stable (sarge). I am
looking at the Configuration>Users page and I can’t see how I set
things so this guest user is not able to modify their own password, or
create new requests.
I imagine what you want is the Config > Global (or for finer-grained
control, Queues > The Queue) > User Rights. Check out the list of
grantable rights there; you probably don’t want much more than the
SeeQueue and ShowTicket rights enabled.
Keep in mind that if you’ve already enabled more generous permissions
than that on a global level, the right-inheritance model of RT’s ACLs
won’t allow you to then /limit/ those rights at a per-queue basis.
I think the ModifySelf permission is the one you’re after for users
changing their own password & details.
Cheers,
Bruce,
Andrew Foster wrote:
We are using RT 3.4.1 as packaged for Debian stable (sarge). I am
looking at the Configuration>Users page and I can’t see how I set
things so this guest user is not able to modify their own password, or
create new requests.
[snip]
I think the ModifySelf permission is the one you’re after for users
changing their own password & details.
Looks like Andrew already answered for me. This is indeed the
permission you want.
Tom