Akeeba Ticket System

Wednesday, 08 March 2017 05:41 CST

weeblr

HI

As I started using a CustomField, I'm wondering if you could add a feature whereby the visiblity of a custom field could be different from that of the ticket. Scenario is:

- ticket is public
- user needs to provide credentials
- I have a "Private information" custom field (a text area for instance), clearly labelled as "Private", where user can enter their website URL or they admin credentials

That way, we keep the ticket public (for community benefit) but we have an option to still pass private information, without having to make the whole ticket private.

What do you think? or maybe there's already a way to do this that I missed?

Rgds

Wednesday, 08 March 2017 06:28 CST

weeblr

Hi again,

Harder than I thought. It seems one can only edit those fields when creating a ticket, not later. So if they don't do it, it's not possible to edit the first post and add them later.

Hiding/showing the custom fields based on user rights is pretty easy, but it's only about displaying:

// weeblr filter showing custom fields only on author or admins
$isStaff = $this->isManager || $user->authorise('core.edit.state','com_ats');
$isCreator = !$user->guest && ($user->authorise('core.edit.own','com_ats') && ($user->id == $item->created_by));
if(!$isCreator && !$isStaff)
{
    $showCustomFields = 0;

}
// weeblr

But updating those fields is much more involved

Wednesday, 08 March 2017 07:08 CST

nicholas

Custom fields are used to collect additional information while the ticket is being filed. That information is meant to be displayed as part of the first post of the ticket with the same visibility as the ticket. They are not meant to be a way to collect privileged information on demand.

If you want to collect additional, privileged information from your users (such as login information) you can always set the ticket to private and ask them to post the information in their next reply. Works great and is far less likely for the user to screw it up.

Another way is to have all attachments displayed as private which means that only the support staff and the ticket owner will be able to see them. This applies even to public tickets. Therefore you can ask your client to attach a text file with the credentials. That's actually better than the solution above since you can periodically purge old attachments using the provided CLI script. This makes the credentials storage short lived which, considering how our clients are unlikely to bother revoking our access, is probably for the best with regards to security.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 08 March 2017 07:36 CST

weeblr

Hi

Well, I know the standard ATS way of making the ticket private, but to be honest it's a bit cumbersome compared to having a "private zone" attached to each ticket, public or private, that users can edit at any time. I have experienced that with other support forum, and it's pretty convenient for both us and users.
And it's suboptimal to make a whole ticket private just because of a username/pwd mention.

Problem with custom fields being only available upon creation is that you can always forget to fill them in, enter the wrong information, with no way to go back.

Anyway, that's too much of a change, I'll think of something else.

Rgds

Wednesday, 08 March 2017 10:18 CST

nicholas

I told you what are the design goals of ATS.

As for being cumbersome, um, no? I am doing right now the exact same thing I'd need to do to enter connection information i.e. typing text in a fairly large content area.

As for the ticket needing to be private, technically no, it doesn't. After the client provides connection information you can copy them to Manager Notes which is only available to you and remove them from the reply. The ticket can be made public again.

That said, once you get connection information the rest of the conversation will by definition refer to privileged information (how the site is set up). It's utterly irresponsible leaving that information in public. When someone lets you peek at their site's backend the only responsible thing to do is to treat all information you obtain as privileged material that's not to be shared in public. It's no longer a generic question, it's a specific site case.

I can also tell you other reasons why giving edit access to users is bad. Do you give them edit access to their ticket posts forever? No, because they tend to go back and change everything to the point that you no longer have a history of what actually happened, making the ticket system useless.

Finally, about the users getting the extra fields wrong. That would be a strong indication that you have too many or too complicated fields. When we started having that problem we pruned the custom fields to the essentials. Now we don't get wrong field contents by accident, only by ignorance. Either that or we have too many time travelers who are using Joomla! 6.4 ;)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 08 March 2017 11:08 CST

weeblr

Well as often it's a matter of viewpoint I guess...

As for being cumbersome, um, no? I am doing right now the exact same thing I'd need to do to enter connection information i.e. typing text in a fairly large content area.

Not really. The actual workflow would be, from a user standpoint:

1 - ask you to make the ticket private (considering about 30% of my users spontaneously offer credentials, by experience).
2 - Wait for an email saying your replied
3 - Make a new post with the credentials
4 - You copy/paste them and remove them from the thread into the Manager's note, then answer
5 - Maybe make the ticket public again (everyone knows they are using sh404SEF or wbAMP, that's what they are asking support for. Only a handful of tickets actually disclose real information - besides credentials)

Compare that workflow to: nothing

With a a private custom fields, user can post sensitive information at any time, without you doing any copy/pasting, changing ticket status, and most importantly having to wait a back-and-forth post to go ahead.

why giving edit access to users is bad.

Didn't say anything like that. Indeed, we also consider tickets as a historical record of exchanges, that should not be modified. But a single private and editable field does has nothing to do with that.

Finally, about the users getting the extra fields wrong. That would be a strong indication that you have too many or too complicated fields. When we started having that problem we pruned the custom fields to the essentials. Now we don't get wrong field contents by accident, only by ignorance. Either that or we have too many time travelers who are using Joomla! 6.4 ;)

Actually so far I dont have any such field. I dropped the J!; PHP and such questions a long time ago, and ask them only if relevant.

No worries, that was only a suggestion. I quickly put that together using a plugin. You can close the ticket now.

Rgds

Support