Is PublicTicketForm exactly public?

[argoyal]

I was implementing a helpdesk for my organization and I had few things to discuss with the developers about this project. I was thinking of contributing to the code with exactly some of the thought process that I feel should be an appropriate choice.

1. The PublicTicketForm isn't exactly public. A logged in user also uses PublicTicketForm. Is there any important logic that I am missing or is it the choice developers made.

2. An authenticated user creating a ticket, who is not a staff should not be concerned about the Priority and Due date fields in the ticket. I think its the job of the staff members replying to the tickets as a response to provide due dates and priority to a particular ticket.

3. An authenticated user logged in to the platform and creating ticket should not be able to edit the Email field. This might prevent spams from authenticated users and get a better understanding of our authenticated users. (I have actually done this, will submit a pull request shortly).

4. All the email tasks are currently run inside the view. Sending emails via an SMTP server takes time and should rather be made asynchronous (Celery and Redis).

5. Options to move the attachments to a cloud service should be provided.

All the above options seem to be a good fit for the product and I am currently working on some of these for my own organization.

Thanks!

[gwasser]

Hello! I'll try to answer:

1. Not sure the reason but the project goes back to older versions of django. The templates and forms could use some modernizing. Probably the Public and the logged in forms should be two different forms that inherit from a base one.
2. I think a non-staff user might want to set a Due date if there's a deadline of some sort. Priority is probably an internal staff user only thing though, I agree. The user permissions still need some work to make this happen.
3. Do you mean the submitted email? I think it's ok for an authenticated user to edit the email if needed. Possibly we can do more work with better user permissions.
4. Yeah the views need some modernizing too.
5. I think the software is meant to be completely self-hosted to avoid use of cloud services. That said, if that's a useful feature, I don't see any reason it can't be added as an optional feature.

PRs for the above or anything else are welcome! Thanks for the feedback.

[timthelion]

1 The PublicTicketForm isn't exactly public. A logged in user also uses PublicTicketForm. Is there any important logic that I am missing or is it the choice developers made. → Not sure of what you mean here.

2 An authenticated user creating a ticket, who is not a staff should not be concerned about the Priority and Due date fields in the ticket. I think its the job of the staff members replying to the tickets as a response to provide due dates and priority to a particular ticket. → You can easily use a django template to change this.

3 The spam issue is valid we need to think about securing the public submission form better, I've opened a new ticket: #1141

4 Options to move the attachments to a cloud service should be provided. → This is in Django already