Question: Custom permissions checks per-queue?

[volundmush]

Is your feature request related to a problem? Please describe.
A team I am working with is looking for a helpdesk solution that can integrate with our pre-existing Django setup. We have our own extensive permissions controls for accounts already integrated however and would like to be able to control access to different queues using our own arbitrary function calls. It doesn't look like there is any support for such; nothing I can see, anyways. there are a few function calls like is_helpdesk_staff but they don't seem to have any awareness of the ticket they're operating on or the queue it belongs to, so I cannot monkey-patch in anything...

Describe the solution you'd like
Some configurable (settings.py ? ) way to do a permissions check on whether a user has access to a specific ticket where the call receives both the request/user and the ticket in question?

I can think of two levels of checks that are needed:
A) who is allowed to create a ticket in this queue?
B) Who is allowed to list and manage tickets in the queue?

Describe alternatives you've considered
I really haven't, sorry. Am jumping around through lots of ideas right now.

[timthelion]

This was originally planed as a feature of the teams feature but it wasn't implemented (due to lack of resources). Currently tickets associated with specific KBItems are autoshown as assigned to members of the team associated with the kbitem but there isn't any sort of secure permission system around this.

[uhurusurfa]

In my opinion the whole permissions aspect of Helpdesk could probably do with a rewrite so that enhancing permissions becomes a much simpler and more easily understood implementation that can be easily configurable to suit different business processes. There are other enhancement requests logged that surround the whole permissions thing and the current implentation will make it very difficult to implement a configurable solution to accomodate the different needs of users. The best way to do this is to create an API for the web interface which makes the job even bigger since we would need to rework all the templates. An API would also make it easier for users of Helpdesk to plug in their own UI implementation.

[timthelion]

Yes, a well tested REST api with proper permissions management would be far easier to audit for security and could also allow for much better UX in terms of zero page reload helpdesking.

I imagine it would be cool to implement a ticket tinder view that allowed you to swipe left on tickets that weren't relevant to you and swipe right to reply. This would be easy to implement wit ha good API and is now impossible.

[timthelion]

I wasjust looking through the code and noticed this

django-helpdesk/helpdesk/models.py

Line 252 in 2b6ad7a

permission_name = models.CharField(

perhapse this was implemented at some point?

[timthelion]

It seems like this might already be supported,some should test it and document it... https://github.com/django-helpdesk/django-helpdesk/blame/2b6ad7a2cffaf36d30a8414e6864a886bc135668/helpdesk/user.py#L33

[timthelion]

Reading the code it looksif you give a nonstaff non super user permission to access a queue using the django permissions system then they should have access to that queue only...

[timthelion]

Though all the relevant views are 'staff member required'

django-helpdesk/helpdesk/decorators.py

Line 37 in 2b6ad7a

helpdesk_staff_member_required = user_passes_test(is_helpdesk_staff)

so your nonstaff users still won't be able to doanything... Sorry permissions are a bit of amess now 🤡

[timthelion]

What would ya'll think of replacing most of the permissions system with a single custom manager on the Ticket model which would take a user parameter in its initializer and automatically filter the queryset based on either django permissions, team membership or any custom logic the integrator desired? https://docs.djangoproject.com/en/4.2/topics/db/managers/

[volundmush]

Ooooh, thank you @timthelion for digging this all up. This is majorly helpful.