Mailing List Archive

Access right question
I posted a question about this recently but this time, I will try to
give it more focus.

In addition to using Trac for what it already does very well, I also
want to use it as a customer support system. But I must limit what
customers can see. I want any customer to ONLY have access to:

- login
- a report that lists the tickects that HE or SHE reported.
- view details of any of his or her tickets.

Can this be done by setting up Apache's conf file or would this require
changes in Trac itself?

Claude
Access right question [ In reply to ]
On Wednesday 19 May 2004 12:26 pm, Claude Montpetit [nertec] wrote:
> In addition to using Trac for what it already does very well, I also
> want to use it as a customer support system.

This is certainly an interesting issue and a use case I think will continue
coming up in the future.

> But I must limit what customers can see. I want any customer to ONLY have
> access to:
> - login
> - a report that lists the tickects that HE or SHE reported.
> - view details of any of his or her tickets.
>
> Can this be done by setting up Apache's conf file or would this require
> changes in Trac itself?

Whereas there is indeed 'login'/authentication facility in Trac, it's intented
use is undeniably primarily for project participants and developers.

One way, possibly the fastest way, to achieve this use case, would not be to
modify Trac itselm but rather use Trac as a 'backend' system, and then
writing a few simple cgi's to access the Trac sqlite database directly,
extracting and presenting information tailored for the customer application.

Perhaps even subclassing/deriving the Report module might be useful, if
reusing it cuts your implementation time. Whatever works for your
application. :)

As for submitting tickets, it's probably a good idea to make a simplified HTML
form and a cgi to enter the information directly into the database.

This way, you separate 'company users' from 'customers' cleanly, and can have
whatever different forms of authentication, presentation and features
necessary without modifying Trac itself, and letting apache do as much of the
work as possible.

To sum it up, don't be afraid to look behind the curtains. ;-)

--
Daniel Lundin | Edgewall Software
daniel@edgewall.com | Professional Linux & Open Source Consulting
| http://www.edgewall.com/
Access right question [ In reply to ]
Thank you Daniel, your answer is appreciated.

Claude

Daniel Lundin wrote:

>On Wednesday 19 May 2004 12:26 pm, Claude Montpetit [nertec] wrote:
>
>
>>In addition to using Trac for what it already does very well, I also
>>want to use it as a customer support system.
>>
>>
>
>This is certainly an interesting issue and a use case I think will continue
>coming up in the future.
>
>
>
>>But I must limit what customers can see. I want any customer to ONLY have
>>access to:
>> - login
>> - a report that lists the tickects that HE or SHE reported.
>> - view details of any of his or her tickets.
>>
>>Can this be done by setting up Apache's conf file or would this require
>>changes in Trac itself?
>>
>>
>
>Whereas there is indeed 'login'/authentication facility in Trac, it's intented
>use is undeniably primarily for project participants and developers.
>
>One way, possibly the fastest way, to achieve this use case, would not be to
>modify Trac itselm but rather use Trac as a 'backend' system, and then
>writing a few simple cgi's to access the Trac sqlite database directly,
>extracting and presenting information tailored for the customer application.
>
>Perhaps even subclassing/deriving the Report module might be useful, if
>reusing it cuts your implementation time. Whatever works for your
>application. :)
>
>As for submitting tickets, it's probably a good idea to make a simplified HTML
>form and a cgi to enter the information directly into the database.
>
>This way, you separate 'company users' from 'customers' cleanly, and can have
>whatever different forms of authentication, presentation and features
>necessary without modifying Trac itself, and letting apache do as much of the
>work as possible.
>
>To sum it up, don't be afraid to look behind the curtains. ;-)
>
>
>