Support

1. Unfortunately not. It requires very inefficient changes in the database schema and code to add a label of very limited use. It just doesn't make business or architectural sense to implement such a feature.

To give you an idea, it would require not only a new database field in the ticket (e.g. created_on_behalf_by) but also deep changes in every single model, helper class and template to detect if this is non empty and belongs to a valid user. This will have a major impact not only in efficiency (every time we load another user in Joomla! it gets painfully slow) but would also require every client of our software to completely rewrite all their template overrides. Too much hassle, not much gain, let's just not go there. Instead, the support staff can simply type a note "Ticket filed on behalf of the user by XYZ, reference phone conversation such and such", giving much more detailed information than we could ever do by modifying our code.

2. No. This is simply not possible in any efficient manner in Joomla!. It would require us to load each and every user on the site and query their access privileges against every ATS category. On a site with just 100 users that would take slightly over 10 seconds. It goes downhill from there.

The use case could be if we offer support for users of Company 1 and also for users of Company 2 but we don't want the Support Team for Company 1 to accidentally create ticket on Company 2 user.

They shouldn't be able to do that anyway, on a properly configured system. Company 2's users don't have Create privileges on the categories managed by Company 1. That's what access controls (ACLs – the privileges you define in Joomla! itself) are for.

1. OK

2. Yes, that's the setup I was talking about. No, the user list cannot be filtered.

That's a Joomla! limitation. You can't limit users by those who have a specific privilege allowed to them. This is due to the way privileges work in Joomla!. In order to determine a user's privileges Joomla! has to look, for each and every group the user belongs to, the same privilege in the category, its parent categories, the component options and –if it's a system (core) privileges– the global privileges you set up in Global Configuration. It has to do that recursively, for every group, because of a. inherited privileges; b. explicit deny always trumps allow; and c. Super User privilege trumps all other privileges (it becomes forced Allow). This is exactly where is the problem I described before: we'd have to query the privileges for every user. This takes about 100 msec per user. At 1000 users your site is unresponsive. At 75,000 users your CPU usage goes up so far and so fast that you may have to actually reboot the server. Don't ask me how I found out...