Based on the permission settings you have described, SmarterTrack should show the tickets area in the portal, but not the button for creating new tickets. I have changed this thread to a Problem and added it to our internal issue tracking system.

Thanks!

Unfortunately this does not appear to be fixed.

What should have happened is that the Tickets section would continue to be present, but the New Ticket button would disappear from the Tickets section.

For a user who is not logged in, this is expected. If the user is not logged in, SmarterTrack is unable to determine which tickets belong to the user. Since your settings prevent users from creating tickets from the portal, SmarterTrack hides the tickets section from users who aren't logged in since the section is useless to them. Once a user logs in, the ticket section should become accessible as SmarterTrack will then be able to identify which tickets belong to the user.

Thank you for the reply Andrew.  The problem with that logic is that the option to e-mail a listing of all past support tickets is available for anyone, including people who are not logged in.  So by denying them access to the Tickets button, that feature that would normally be available is missing.

We had a lengthy meeting with our management team about this and other issues, here is what they decided:

We have decided that the ability to view the Tickets area on the portal will be determined solely by the Brand's "View Ticket Requires" setting. This means that if the Brand is configured to allow all users to view tickets in the portal, unauthenticated users will be able to see the Ticket area, regardless of the department settings for creating tickets from the portal.

Regarding the emailing of a user's tickets, for security purposes, we will be updating the way that the "Email my tickets" action works. Instead of asking for an email address and sending a list of associated tickets to that address, as it does now, the feature will require that the user is logged in and will send the authenticated user's tickets to the email address they have on file.

Sounds sensible to me, thanks for the update!

This issue was resolved in build 7005, which was released on March 7 2019.