I have a customer with more than one department each with it's own person in charge to open tickets specific to that department.
So I would see something like:

CLIENT
|---------Department1 (Permission to submit tickets only for User1)
|_______Departmant2 (Permission to submit tickets only for User2)

User3 can read and/or write tickets for CLIENT (all departments)
User4 can only read all tickets for CLIENT (all departments)

This should involve only the ability to have nested JOB TICKETS groups because access read/write restrictions should remain compatible with current implementation.

Tnx.

Comments

jeremy’s picture

jeremy commented
Status: Active » Postponed

It would not be overly difficult to do this, you'd just need another database table to allow associations like you describe. You'd also need to improve the admin interfaces to handle this nesting.

I do not have a need for this and thus will not be implementing it myself. I do welcome patches. You may also want to experiment with building something using Views.

Moving into a postponed state awaiting a patch.

jeremy’s picture

jeremy commented
Status: Postponed » Closed (won't fix)

I have no need/desire for this complexity. Closing ticket rather than migrating it to new project.