Tickets Plugin 🎟

Hi @merefield and @angus thanks for the clarification above.

I assume that the resources to fix this before month end were not there but I hope that it’s still within the support policy will mean that this is looked at in the first five days of December - just checking as it’s now 3rd so wanted to give you a heads up.

@Ellibereth you feel that this support is something that needs payment for please say!

Thanks.

J

2 Likes

Just a friendly prompt to consider allocating a bit of time to fixing this plugin at the start of January. Thanks!

1 Like

We’re going to start using this plugin internally at Pavilion, so I’ll be working on it over the next few weeks.

4 Likes

Hey @angus, I’m just wondering if you’ve been able to make any progress with this? I’m looking to set up a workflow soon for my community and really would love to use Discourse Tickets! Any estimate of when we might see an updated version? Thanks for all your hard work and contributions to the community!

2 Likes

The filtering of tags seems to be causing a problem for me. I am at bb019aab5d if it matters. Stacktrace is below.

NoMethodError (undefined method id' for #<Array:0x00007f2c08ca79f8>) app/controllers/tags_controller.rb:249:in search’
app/controllers/application_controller.rb:404:in block in with_resolved_locale' app/controllers/application_controller.rb:404:in with_resolved_locale’
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:368:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:202:in `call’

Backtrace

plugins/discourse-tickets/plugin.rb:47:in block in filter_allowed_tags' plugins/discourse-tickets/plugin.rb:47:in select’
plugins/discourse-tickets/plugin.rb:47:in filter_allowed_tags' app/controllers/tags_controller.rb:249:in search’
actionpack (6.1.4.7) lib/action_controller/metal/basic_implicit_render.rb:6:in send_action' actionpack (6.1.4.7) lib/abstract_controller/base.rb:228:in process_action’
actionpack (6.1.4.7) lib/action_controller/metal/rendering.rb:30:in process_action' actionpack (6.1.4.7) lib/abstract_controller/callbacks.rb:42:in block in process_action’
activesupport (6.1.4.7) lib/active_support/callbacks.rb:117:in block in run_callbacks' app/controllers/application_controller.rb:404:in block in with_resolved_locale’

Env

HTTP HOSTS: forums.librehealth.io

A problem has been reported with the Tickets plugin and it’s unfortunately currently marked as a #plugin:broken-plugin. If you remove the plugin from your app.yml and rebuild it should allow the rest of the site to use tags as normal.

(I’ve moved these posts across to the Tickets topic so they can better track the issue :+1:)

2 Likes

@JammyDodger I completely missed that – thank you!

2 Likes

It’s disappointing to see that this has hit the graveyard - surely a lot of work went into it and it had so much potential! I hope it will get revived at some point…

2 Likes

In the topic where the move to #plugin:broken-plugin was discussed

2 Likes

I’ve also identified problem with TIckets plugin, causing “Internal Sever Error” when trying to add tag to any PMs, have disabled the plugin and back to normal

Error log:

plugins/discourse-tickets/plugin.rb:47:in `block in filter_allowed_tags'

plugins/discourse-tickets/plugin.rb:47:in `select'

plugins/discourse-tickets/plugin.rb:47:in `filter_allowed_tags'

app/controllers/tags_controller.rb:249:in `search'

actionpack (7.0.2.4) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'

actionpack (7.0.2.4) lib/abstract_controller/base.rb:214:in `process_action'

actionpack (7.0.2.4) lib/action_controller/metal/rendering.rb:53:in `process_action'

actionpack (7.0.2.4) lib/abstract_controller/callbacks.rb:234:in `block in process_action'

activesupport (7.0.2.4) lib/active_support/callbacks.rb:118:in `block in run_callbacks'

app/controllers/application_controller.rb:404:in `block in with_resolved_locale'

i18n (1.10.0) lib/i18n.rb:328:in `with_locale'

app/controllers/application_controller.rb:404:in `with_resolved_locale'

activesupport (7.0.2.4) lib/active_support/callbacks.rb:127:in `block in run_callbacks'
2 Likes

@robbyoconnor @Nick_Chomey @jerry0 I’ve just pushed a fix for the issue this plugin had

If one of you could update and respond to confirm the fix, I’ll move this plugin back to #plugin.

4 Likes

I will test it soon and report back.

2 Likes

@angus

Thanks VERY much for your work on this! I really hope that it can get polished off soon!

I have done some basic testing now and it is still having most of the problems that I reported here.

I no longer get the popup error message saying “Sorry an error has occured”, but clicking the Assign button in the Tickets module (to the right of the tags) doesnt do anything and produces the same console errors shown previously in the screen recording.

I can assign a topic with the Assign button below the topic, but Tickets and Assign still don’t seem to be talking to each other. The Assigned column in the Tickets Dashboard doesn’t populate.

Also, I’m hoping that while you are looking at this you might be able to give a bit of attention to the request that a variety of people have made - allowing groups beyond “Staff” to be able to use Tickets. I poked around in the code a bit and noticed a few places where it says things like currentUser.staff, is_staff etc… So I’m guessing that it wouldn’t be too difficult to either

  1. relax/remove that stipulation,
  2. add another userGroup (e.g. TicketsTeam) that we could create and define ourselves, or
  3. add some sort of customization mechanism in the Tickets settings that allows us to define which groups have access to Tickets.

Obviously 3 > 2 > 1, but whatever you are inclined towards would be greatly appreciated! I also think it would make Tickets more broadly appealing, which would make your previous hard work more worth the while.

Thanks again!

1 Like

Hey @angus - yes that has fixed the tags issue.

However I still consider this plugin to be broken as none of the interplay with the Assigned plugin is working any more, and both @Nick_Chomey and me have been reporting this (and contacting Pavilion separately for months without any useful response). It just doesn’t show who a ticket is assigned to which is pretty major issue.

Thanks, hope this can be fixed still.

1 Like

@Nick_Chomey @jerry0 I’ve updated this plugin to support the changes in the assign plugin.

Sorry if we’ve missed your messages! How did you try and contact us? Did you file a bug report (I don’t see any for the tickets plugin)? Did you message me somewhere? Or do you mean your posts earlier in this topic?

Given the tags issue is confirmed as fixed, and I’ve addressed the assign integration, I’ll be moving this back to #plugin.

6 Likes

Hi Angus - I really appreciate you working on this. That’s fantastic!!! (and in response to your question, I PM’d @ellibereth a few times as you suggested in your post above). Sorry, I didn’t file a bug report but note that for the future!!

3 Likes

@angus Thanks for the further work on this. I get this error when I go to site.com/admin/tickets

image

It goes away if I check Redirect user assigned routes to ticket dashboard.

Also, I think @jerry0 was referrring to our various tagged replies here over the past 6 months… I think we thought those were sufficient, given that you and your team had acknowledged the problems on a few occasions…

If only there were a Tickets mechanism here that non-staff members had access to, then it would be easy for a group of unrelated people to track and manage communal tasks … :wink:

It is something that is desperately needed in a decentralized community, such as those often run on Discourse. It doesn’t make sense to use a separate project management tool (off-site friction, costs and overkill), not all issues warrant being made/tracked on Github (off-site friction, non-code-related issues/tasks, etc…), and, obviously, such a task needs more than just a category of topics (hence the existence of this plugin).

It is already possible to use the Assign Plugin to assign topics to non-staff members (such as those within a particular group) - it seems only natural (and, I suspect, not terribly difficult) to extend such functionality/access to the Tickets plugin. I’d do it myself, but I don’t really know how Discourse development works… It would take me days to figure out.

So, I really hope you can take a quick look into modifying Tickets in one of the ways suggested in my previous post. A final thought on it - given that non-staff don’t have access to site.com/admin perhaps the tickets dashboard can/should be moved to the User Dashboard, where the Assigned Dashboard is e.g. site.com/u/[username]/activity/tickets

1 Like

So just to confirm, everything (including the assign integration) is working as expected for you, if tickets redirect assigned is enabled? I’ll look at the issue itself tomorrow.

Yes, we can look at adding this, but the plugin needs unit tests before we do this so it’s not going to happen for at least a few months. The most important thing to address in this plugin is hardening the existing functionality so it’s easier to address compatibility issues (like the recent tag issue) when they arise.

The main reason this plugin hasn’t gotten more attention is because we simply don’t have enough time. But there is a way you can help us solve that. Find a developer who has some experience with Ruby on Rails and JavaScript, or is willing to learn, put them in contact with me and I’ll mentor them as the maintainer of this plugin. I’m always willing to teach a man (or woman) to fish as the saying goes.

Are you a developer? I’d be happy to help you get started with Discourse development so you can take over the plugin. Start out here and once you’re done I’ll set you up with the some beginner tasks involving the Tickets Plugin.

5 Likes

Thanks very much for the thoughtful reply!

I completely understand, now that you explain the underlying issues with the plugin that need to be addressed before moving forward.

I’m a pretty novice “developer”, mostly focusing on WordPress (php, mysql, a bit of js), so a few months ago I would have loved to be mentored on how to get this functionality integrated into the plugin. But unfortunately I really don’t have time to spare now. My interest in Discourse is just for the new forums that I created/migrated for the open-source CyberPanel web control panel.

The developer doesn’t have time or skill/inclination for community management, so he is largely left flying solo. Things have improved a lot since I intervened 6 months ago and moved everything - support, docs etc… - to Discourse. The final piece of the puzzle is to have some sort of tickets management system to better allow the community and developer to track what needs to be done.

If anyone is curious, they can check it out here: https://community.cyberpanel.net/

Anyway, I really do hope that someone else will take you up on you generous offer of mentorship!

2 Likes

Since CyberPanel is a revenue generating business, it might be able to fund the work? I’m sure Pavilion would be glad for its business.

2 Likes