jutda-helpdesk - Project Hosting on Google Code

| Sign in

Jutda Helpdesk is a Django-powered ticket tracking system for small enterprise, designed from the ground up to be easy to use.

Project Home		Downloads		Issues		Source

Summary | Updates | People

Details: Show all Hide all

1 - 50 Next ›

Last 30 days Dec 23, 2009 issue 120 (Ticket sorting) commented on by rwpoulton - You can sort columns using the filtering options at the top of the screen. Do you think these are insufficient? The nifty thing about sorting with those filters is that you can save the entire filter/sorting set to re-use in the future. You can sort columns using the filtering options at the top of the screen. Do you think these are insufficient? The nifty thing about sorting with those filters is that you can save the entire filter/sorting set to re-use in the future. Dec 23, 2009 issue 125 (IndexError at /helpdesk/reports/userpriority/) Status changed by rwpoulton - Fixed in SVN r148, thank you. Status: Fixed Fixed in SVN r148, thank you. Status: Fixed Dec 23, 2009 r148 (Issue #125: If you have no tickets, the reports throw a 500 ...) committed by rwpoulton - Issue #125 : If you have no tickets, the reports throw a 500 server error. This patch removes the report links when there's no tickets in the system. Thanks to Kestutis Gustaitis for the bug report. Issue #125 : If you have no tickets, the reports throw a 500 server error. This patch removes the report links when there's no tickets in the system. Thanks to Kestutis Gustaitis for the bug report. Dec 22, 2009 issue 125 (IndexError at /helpdesk/reports/userpriority/) reported by kestutis.gustaitis - What version of Python are you using? (1, 1, 1, 'final', 0) What is your hosting environment? localhost What version of Jutda Helpdesk are you using? svn 147 2009-12-16T09:28:19.792174Z What is the expected output? What do you see instead? IndexError at /helpdesk/reports/userpriority/ list index out of range Please provide any additional information below. /usr/lib/python2.6/dist-packages/helpdesk/views/staff.py in run_report 750. first_ticket = Ticket.objects.all().order_by('created')[0] ... This happens cause Ticket.objects.all() returns empty list. Probably there is more "list index out of range" scenarious. What version of Python are you using? (1, 1, 1, 'final', 0) What is your hosting environment? localhost What version of Jutda Helpdesk are you using? svn 147 2009-12-16T09:28:19.792174Z What is the expected output? What do you see instead? IndexError at /helpdesk/reports/userpriority/ list index out of range Please provide any additional information below. /usr/lib/python2.6/dist-packages/helpdesk/views/staff.py in run_report 750. first_ticket = Ticket.objects.all().order_by('created')[0] ... This happens cause Ticket.objects.all() returns empty list. Probably there is more "list index out of range" scenarious. Dec 16, 2009 issue 119 (Russian translation update) Status changed by rwpoulton - Updated in SVN r147. Thanks! Status: Fixed Updated in SVN r147. Thanks! Status: Fixed Dec 16, 2009 r147 (Issue #119 Update Russian translation with patch from Alex Y...) committed by rwpoulton - Issue #119 Update Russian translation with patch from Alex Yakovlev. English file was also out of date which has been updated by the 'makemessages' command. Issue #119 Update Russian translation with patch from Alex Yakovlev. English file was also out of date which has been updated by the 'makemessages' command. Dec 16, 2009 issue 116 (Pre-set replys behavior) Status changed by rwpoulton - I'd be happy for this change to make it's way into the codebase, if you can submit a patch I'll include it. Should there be other things that the Pre-Set replies do? Perhaps letting them be public or private? Status: Accepted I'd be happy for this change to make it's way into the codebase, if you can submit a patch I'll include it. Should there be other things that the Pre-Set replies do? Perhaps letting them be public or private? Status: Accepted Dec 16, 2009 issue 121 ("" get displayed wrong in the email subject) changed by rwpoulton - Fixed in SVN r146, thanks Andreas! Status: Fixed Labels: Component-Email Fixed in SVN r146, thanks Andreas! Status: Fixed Labels: Component-Email Dec 16, 2009 r146 (Issue #121: Formatting fix for e-mail subject. Thanks to And...) committed by rwpoulton - Issue #121 : Formatting fix for e-mail subject. Thanks to Andreas Kotowicz for the report. Issue #121 : Formatting fix for e-mail subject. Thanks to Andreas Kotowicz for the report. Dec 16, 2009 issue 124 (Move to 'flot' for report charts) reported by rwpoulton - Summary of the new feature (a few words): Instead of relying on Google Charts on the report pages, use something internal such as flot (a jQuery Javascript library) Reason why this is needed in Jutda Helpdesk: 1. Google charts have many limitations (hard to customise, maximum widths, etc) 2. Many people don't want to (or can't) rely on third parties. Explanation of the new feature (including a workflow for how you imagine it would work for the end user) Remove reliance on Google Charts, use 'flot' or similar instead. http://code.google.com/p/flot/ Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) Should be nil; we're already using jQuery and jQuery UI elsewhere. Other Comments: Summary of the new feature (a few words): Instead of relying on Google Charts on the report pages, use something internal such as flot (a jQuery Javascript library) Reason why this is needed in Jutda Helpdesk: 1. Google charts have many limitations (hard to customise, maximum widths, etc) 2. Many people don't want to (or can't) rely on third parties. Explanation of the new feature (including a workflow for how you imagine it would work for the end user) Remove reliance on Google Charts, use 'flot' or similar instead. http://code.google.com/p/flot/ Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) Should be nil; we're already using jQuery and jQuery UI elsewhere. Other Comments: Dec 16, 2009 issue 123 (Google Charts don't render when width >1000 px) Status changed by rwpoulton - Fixed in SVN r145 by limiting the chart to 1000px wide. Probably not the best solution, I think it's worth investigating other options such as jQuery charting - see Issue #124 for more info. Status: Fixed Fixed in SVN r145 by limiting the chart to 1000px wide. Probably not the best solution, I think it's worth investigating other options such as jQuery charting - see Issue #124 for more info. Status: Fixed Dec 16, 2009 r145 (Issue #123: Charts don't show when there's a large volume of...) committed by rwpoulton - Issue #123 : Charts don't show when there's a large volume of data due to Google constraints. Issue #123 : Charts don't show when there's a large volume of data due to Google constraints. Dec 16, 2009 issue 123 (Google Charts don't render when width >1000 px) reported by rwpoulton - What steps will reproduce the problem? 1. Have many months of data in the system. 2. Run any report 3. Observe chart missing. What is the expected output? What do you see instead? Expect the Google chart to show, however it is blank. This is because the graph has grown to over 1000px wide, which is outside Google's limits. What steps will reproduce the problem? 1. Have many months of data in the system. 2. Run any report 3. Observe chart missing. What is the expected output? What do you see instead? Expect the Google chart to show, however it is blank. This is because the graph has grown to over 1000px wide, which is outside Google's limits. Dec 16, 2009 issue 122 (endless loop in reporting when last ticket was created in de...) Status changed by rwpoulton - Fixed in SVN r144. Thanks for the bug report! Status: Fixed Fixed in SVN r144. Thanks for the bug report! Status: Fixed Dec 16, 2009 r144 (Fixes Issue #122 - infinite loop when most recent ticket was...) committed by rwpoulton - Fixes Issue #122 - infinite loop when most recent ticket was opened in December. Thanks to Chris Vigelius for the bug report. Fixes Issue #122 - infinite loop when most recent ticket was opened in December. Thanks to Chris Vigelius for the bug report. Dec 07, 2009 issue 122 (endless loop in reporting when last ticket was created in de...) reported by chris.vigelius - What version of Django are you using? 1.1.1 What version of Python are you using? 2.6 What is your hosting environment? local development server What version of Jutda Helpdesk are you using? r143 What steps will reproduce the problem? 1. fresh installation of jutda-helpdesk 2. add a ticket (creation date month must be december) 3. navigate to /helpdesk/reports/queuepriority/ (or any other report) What is the expected output? What do you see instead? Expected: the report Actual: nothing at all, and cpu at 100% the culprit is staff.py line 768 (loop exit condition will never be true when last_month == 12) What version of Django are you using? 1.1.1 What version of Python are you using? 2.6 What is your hosting environment? local development server What version of Jutda Helpdesk are you using? r143 What steps will reproduce the problem? 1. fresh installation of jutda-helpdesk 2. add a ticket (creation date month must be december) 3. navigate to /helpdesk/reports/queuepriority/ (or any other report) What is the expected output? What do you see instead? Expected: the report Actual: nothing at all, and cpu at 100% the culprit is staff.py line 768 (loop exit condition will never be true when last_month == 12) Earlier this year Nov 11, 2009 issue 121 ("" get displayed wrong in the email subject) reported by andreas.kotowicz - What version of Django are you using? 1.1 What version of Python are you using? Python 2.6.4 What is your hosting environment? linux What version of Jutda Helpdesk are you using? SVN-143 What steps will reproduce the problem? 1. create a new bug with a title like: fix "add" button in forms to be more generic 2. wait for email to arrive 3. What is the expected output? What do you see instead? expected output: fix "add" button in forms to be more generic instead, the email subject will read: fix " add" button in forms to be more generic What version of Django are you using? 1.1 What version of Python are you using? Python 2.6.4 What is your hosting environment? linux What version of Jutda Helpdesk are you using? SVN-143 What steps will reproduce the problem? 1. create a new bug with a title like: fix "add" button in forms to be more generic 2. wait for email to arrive 3. What is the expected output? What do you see instead? expected output: fix "add" button in forms to be more generic instead, the email subject will read: fix " add" button in forms to be more generic Oct 20, 2009 issue 120 (Ticket sorting) reported by jrmorrisnc - Summary of the new feature (a few words): Request to add JS/Ajax sorting/reverse sorting of tickets by column headers via click. Reason why this is needed in Jutda Helpdesk: It makes it easier to work down a list of tickets by priority, status, etc. Explanation of the new feature (including a workflow for how you imagine it would work for the end user): I think http://tablesorter.com/docs/ would be an easy and excellent choice. Impact on existing areas of Jutda Helpdesk (will it break existing functionality?): It shouldn't, as far as I can tell this is a singular UI improvement. Other Comments: Nice Django application! Summary of the new feature (a few words): Request to add JS/Ajax sorting/reverse sorting of tickets by column headers via click. Reason why this is needed in Jutda Helpdesk: It makes it easier to work down a list of tickets by priority, status, etc. Explanation of the new feature (including a workflow for how you imagine it would work for the end user): I think http://tablesorter.com/docs/ would be an easy and excellent choice. Impact on existing areas of Jutda Helpdesk (will it break existing functionality?): It shouldn't, as far as I can tell this is a singular UI improvement. Other Comments: Nice Django application! Oct 14, 2009 issue 119 (Russian translation update) reported by alex.s.yakovlev - Updated Russian locale for judta-helpdesk r143. Updated Russian locale for judta-helpdesk r143. Oct 13, 2009 issue 115 (Non engilsh attachments) Status changed by rwpoulton - Your patch will allow emails to come through with a filename like '../../myfile.txt' which is not a good thing for obvious reasons. The code you've removed is intended to make the filename on disk ASCII with only valid filename characters. Wanting unicode characters is all well and good, however the security implications of allowing characters other than [a-zA-Z0-9._-] are pretty big. Perhaps we can ASCII-ise the filename on the filesystem, and show the original filename in the user interface. Would that work do you think? Not being entirely familiar with Cryllic filenames; how do other programs handle them in a safe way, remembering that the filenames are being provided by untrusted 3rd parties? Status: Accepted Your patch will allow emails to come through with a filename like '../../myfile.txt' which is not a good thing for obvious reasons. The code you've removed is intended to make the filename on disk ASCII with only valid filename characters. Wanting unicode characters is all well and good, however the security implications of allowing characters other than [a-zA-Z0-9._-] are pretty big. Perhaps we can ASCII-ise the filename on the filesystem, and show the original filename in the user interface. Would that work do you think? Not being entirely familiar with Cryllic filenames; how do other programs handle them in a safe way, remembering that the filenames are being provided by untrusted 3rd parties? Status: Accepted Oct 13, 2009 issue 114 (get_mail.py queue guessing) commented on by rwpoulton - Jutda Helpdesk assumes that e-mail coming in to the e-mail box (POP3 / IMAP) defined on the Queue instance is for that queue; the queue portion of the ticket ID in the subject is ignored. This means that each queue must use a different incoming mailbox. The 'allow_email_submission' flag is used to turn e-mail fetching on/off for a queue. The hard part of what you're trying to do is handling emails without a queue ID in the subject - we need to make sure they go somewhere sensible. The allow_email_submission flag also stops updates coming in via e-mail - I've made the assumption that if you don't allow people to send new tickets via email you also don't allow them to send updates via email. Perhaps I need to rethink this assumption, however don't be fooled - it'll require some pretty significant analysis to make sure messages don't end up going missing in the ether. Jutda Helpdesk assumes that e-mail coming in to the e-mail box (POP3 / IMAP) defined on the Queue instance is for that queue; the queue portion of the ticket ID in the subject is ignored. This means that each queue must use a different incoming mailbox. The 'allow_email_submission' flag is used to turn e-mail fetching on/off for a queue. The hard part of what you're trying to do is handling emails without a queue ID in the subject - we need to make sure they go somewhere sensible. The allow_email_submission flag also stops updates coming in via e-mail - I've made the assumption that if you don't allow people to send new tickets via email you also don't allow them to send updates via email. Perhaps I need to rethink this assumption, however don't be fooled - it'll require some pretty significant analysis to make sure messages don't end up going missing in the ether. Oct 13, 2009 issue 113 (show open / reopened bugs by default after clicking on a que...) Status changed by rwpoulton - I have updated this to append &status=1&status=2; to be the same as if you clicked the number of open tickets for the queue. Sorting has been left at the default to avoid confusion. Done in SVN r143. Status: Fixed I have updated this to append &status=1&status=2; to be the same as if you clicked the number of open tickets for the queue. Sorting has been left at the default to avoid confusion. Done in SVN r143. Status: Fixed Oct 13, 2009 r143 (Issue #113: When clicking a queue name on the dashboard, sho...) committed by rwpoulton - Issue #113 : When clicking a queue name on the dashboard, show only open tickets by default. Thanks to Andreas Kotowicz for the suggestion. Issue #113 : When clicking a queue name on the dashboard, show only open tickets by default. Thanks to Andreas Kotowicz for the suggestion. Oct 13, 2009 issue 117 (Incorrect blocktrans usage in public_view_ticket.html) Status changed by rwpoulton - Updated in SVN r142, thanks for the patch. Status: Fixed Updated in SVN r142, thanks for the patch. Status: Fixed Oct 13, 2009 r142 (Fixes Issue #117 thanks to hgeerts. Corrects usage of blockt...) committed by rwpoulton - Fixes Issue #117 thanks to hgeerts. Corrects usage of blocktrans tag, and properly concatenates strings together in models.py Fixes Issue #117 thanks to hgeerts. Corrects usage of blocktrans tag, and properly concatenates strings together in models.py Oct 13, 2009 issue 118 (send_templated_mail locale can be set to an empty string) changed by rwpoulton - Fixed in SVN r141. Thanks for the suggestion. Status: Fixed Owner: rwpoulton Labels: Type-Defect Fixed in SVN r141. Thanks for the suggestion. Status: Fixed Owner: rwpoulton Labels: Type-Defect Oct 13, 2009 r141 (Issue #118: Incorrect handling of Locales on e-mail template...) committed by rwpoulton - Issue #118 : Incorrect handling of Locales on e-mail templates Issue #118 : Incorrect handling of Locales on e-mail templates Oct 13, 2009 issue 118 (send_templated_mail locale can be set to an empty string) reported by hgeerts - What steps will reproduce the problem? 1. Leave Queue.locale blank 2. Submit a new ticket 3. helpdesk tries to load the template "templates/email_text_footer.txt" What is the expected output? What do you see instead? >>> class Queue: ... locale = '' ... >>> print getattr(Queue(), 'locale', 'en') >>> If the attribute exists getattr will return it regardless of it's value. Please use labels and text to provide additional information. What steps will reproduce the problem? 1. Leave Queue.locale blank 2. Submit a new ticket 3. helpdesk tries to load the template "templates/email_text_footer.txt" What is the expected output? What do you see instead? >>> class Queue: ... locale = '' ... >>> print getattr(Queue(), 'locale', 'en') >>> If the attribute exists getattr will return it regardless of it's value. Please use labels and text to provide additional information. Oct 13, 2009 issue 117 (Incorrect blocktrans usage in public_view_ticket.html) reported by hgeerts - What version of Django are you using? 1.0.2 What version of Python are you using? 2.5.2 What is your hosting environment? based on debian lenny What version of Jutda Helpdesk are you using? r140 What steps will reproduce the problem? 1. View a ticket with ticketchanges through the public_view_ticket.html template What is the expected output? What do you see instead? The ticket, but instead a keyerror is generated by incorrect use of the blocktrans tag Please provide any additional information below. Attached patch fixes the blocktrans problem It also solves a problem with the TicketChange model referencing globals instead of instance properties and concatenating a string with a string proxy. As well as translating the string before substituting it's parameters. What version of Django are you using? 1.0.2 What version of Python are you using? 2.5.2 What is your hosting environment? based on debian lenny What version of Jutda Helpdesk are you using? r140 What steps will reproduce the problem? 1. View a ticket with ticketchanges through the public_view_ticket.html template What is the expected output? What do you see instead? The ticket, but instead a keyerror is generated by incorrect use of the blocktrans tag Please provide any additional information below. Attached patch fixes the blocktrans problem It also solves a problem with the TicketChange model referencing globals instead of instance properties and concatenating a string with a string proxy. As well as translating the string before substituting it's parameters. Oct 05, 2009 issue 116 (Pre-set replys behavior) reported by Mikhail.V.Savchuk - Summary of the new feature (a few words): Pre-set replys can't change current state of ticket. For example, I have couple of replys like "Ticket closed, solved by phone call" or "Ticket closed, incorrect ticket - please fill all fields carefully at http://<bla-bla> Reason why this is needed in Jutda Helpdesk: Just to simplify technician work. Explanation of the new feature (including a workflow for how you imagine it would work for the end user) Some pre-set replays could change state of current ticket (may be just Java Script changing state radiobutton) Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) Nope Summary of the new feature (a few words): Pre-set replys can't change current state of ticket. For example, I have couple of replys like "Ticket closed, solved by phone call" or "Ticket closed, incorrect ticket - please fill all fields carefully at http://<bla-bla> Reason why this is needed in Jutda Helpdesk: Just to simplify technician work. Explanation of the new feature (including a workflow for how you imagine it would work for the end user) Some pre-set replays could change state of current ticket (may be just Java Script changing state radiobutton) Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) Nope Sep 16, 2009 issue 114 (get_mail.py queue guessing) commented on by Mikhail.V.Savchuk - Yes, you are right. I have no need to make new tickets from e-mail, is this a bug or not but jutda-helpdesk can: 1. Check queue email, and make either new tickets, or update current tickets (for example when someone wants to add some additional information to his query or to answer support's question) 2. Or not to check e-mail at all. I think it's connected with allow_email_submission flag. So, i've made dirty hack to send all e-mail that's not look like [<slug>-<id>]something to special e-mail address. According to this one, i preffer to use one email to unificate all processes. Yes, you are right. I have no need to make new tickets from e-mail, is this a bug or not but jutda-helpdesk can: 1. Check queue email, and make either new tickets, or update current tickets (for example when someone wants to add some additional information to his query or to answer support's question) 2. Or not to check e-mail at all. I think it's connected with allow_email_submission flag. So, i've made dirty hack to send all e-mail that's not look like [<slug>-<id>]something to special e-mail address. According to this one, i preffer to use one email to unificate all processes. Sep 16, 2009 issue 114 (get_mail.py queue guessing) commented on by rwpoulton - Just to clarify this for me - are you trying to use one e-mail address for all of your queues? Just to clarify this for me - are you trying to use one e-mail address for all of your queues? Sep 16, 2009 issue 114 (get_mail.py queue guessing) commented on by Mikhail.V.Savchuk - I did some patch in email.py like this if regex.match(subject): +slug = re.match(r"^\[(?P<slug>[A-Za-z0-9]+)-(?P<id>\d+)\]", subject).group('slug') +try: + queue = Queue.objects.get(slug=slug) +except Queue.DoesNotExist: + return None; # This is a reply or forward. ticket = re.match(r"^\[(?P<queue>[A-Za-z0-9]+)-(?P<id>\d+)\]", subject).group('id') else: ticket = None It's make dynamic substitution of queue while processing. Of course it's a dirty hack, but at least I can use one email for each queue. I did some patch in email.py like this if regex.match(subject): +slug = re.match(r"^\[(?P<slug>[A-Za-z0-9]+)-(?P<id>\d+)\]", subject).group('slug') +try: + queue = Queue.objects.get(slug=slug) +except Queue.DoesNotExist: + return None; # This is a reply or forward. ticket = re.match(r"^\[(?P<queue>[A-Za-z0-9]+)-(?P<id>\d+)\]", subject).group('id') else: ticket = None It's make dynamic substitution of queue while processing. Of course it's a dirty hack, but at least I can use one email for each queue. Sep 15, 2009 issue 115 (Non engilsh attachments) reported by Mikhail.V.Savchuk - What steps will reproduce the problem? When I send e-mail to my queue bot it ruins my cyrillic attachments. It looks like =?KOI8-R?B?0NLJ18XULnBuZw==?= (image/png, 9.7 КБ). Please provide any additional information below. I've made some changes to e-mail.py like this. +filename = decode_header(name)[0][0]; +charset = decode_header(name)[0][1]; -'filename' : name, +'filename': filename.decode(charset), +filename = file['filename'] -filename = file['filename'].encode('ascii', 'replace').replace(' ', '_') -filename = re.sub('[^a-zA-Z0-9._-]+', '', filename) Sorry, still has no qualification to make patch. What steps will reproduce the problem? When I send e-mail to my queue bot it ruins my cyrillic attachments. It looks like =?KOI8-R?B?0NLJ18XULnBuZw==?= (image/png, 9.7 КБ). Please provide any additional information below. I've made some changes to e-mail.py like this. +filename = decode_header(name)[0][0]; +charset = decode_header(name)[0][1]; -'filename' : name, +'filename': filename.decode(charset), +filename = file['filename'] -filename = file['filename'].encode('ascii', 'replace').replace(' ', '_') -filename = re.sub('[^a-zA-Z0-9._-]+', '', filename) Sorry, still has no qualification to make patch. Sep 14, 2009 issue 114 (get_mail.py queue guessing) reported by Mikhail.V.Savchuk - What steps will reproduce the problem? We are using one e-mail for each queues. When someone answers from his email carbon copies and owners email are with incorrect <From:> filed. Looks like jutda-helpdesk tries to guess queue just from e-mail, not from subject, so in carbon copy and I see incorrect From field (technically it's first queue in list). What steps will reproduce the problem? We are using one e-mail for each queues. When someone answers from his email carbon copies and owners email are with incorrect <From:> filed. Looks like jutda-helpdesk tries to guess queue just from e-mail, not from subject, so in carbon copy and I see incorrect From field (technically it's first queue in list). Sep 14, 2009 issue 111 (Using GMail (Google apps) mail as queue bot.) commented on by Mikhail.V.Savchuk - Thanks for advice. But it looks a bit complicated to install MTA agent when there is no real need to do so. Thanks for advice. But it looks a bit complicated to install MTA agent when there is no real need to do so. Sep 13, 2009 issue 111 (Using GMail (Google apps) mail as queue bot.) commented on by comp.ogz - To send emails by using Gmail, i installed and configured postfix at my machine. At the postfix configuration, it is possible to say to use ssl authantication and use smtp.gmail.com for sending mails. I can send you the configurations if you like. So indeed what you do is sending mails to username@localhost.localhost, but it is delivered to the destination via gmail and you can defined the from address also so the reply will be to that address. To send emails by using Gmail, i installed and configured postfix at my machine. At the postfix configuration, it is possible to say to use ssl authantication and use smtp.gmail.com for sending mails. I can send you the configurations if you like. So indeed what you do is sending mails to username@localhost.localhost, but it is delivered to the destination via gmail and you can defined the from address also so the reply will be to that address. Sep 12, 2009 issue 113 (show open / reopened bugs by default after clicking on a que...) reported by andreas.kotowicz - Summary of the new feature (a few words): on the dashboard, we get presented the list of queues in the "helpdesk summary" table. the default behavior of Jutda Helpdesk is to show the entire queue (with all closed and resolved bugs) after you click on a queue. I think that most people are interested in the open / reopened bugs. By default you are most probably not interested to see bugs from 2 years ago Reason why this is needed in Jutda Helpdesk: will make the work flow much more effective. Currently I create a custom query for each queue because I only want to see the open bugs. Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) none. It should be as easy as adding "&sort=created&status=1&status=2" after the queue-id to the URL. Summary of the new feature (a few words): on the dashboard, we get presented the list of queues in the "helpdesk summary" table. the default behavior of Jutda Helpdesk is to show the entire queue (with all closed and resolved bugs) after you click on a queue. I think that most people are interested in the open / reopened bugs. By default you are most probably not interested to see bugs from 2 years ago Reason why this is needed in Jutda Helpdesk: will make the work flow much more effective. Currently I create a custom query for each queue because I only want to see the open bugs. Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) none. It should be as easy as adding "&sort=created&status=1&status=2" after the queue-id to the URL. Sep 12, 2009 issue 112 (allow to change user settings - create default settings.) reported by andreas.kotowicz - Summary of the new feature (a few words): currently all of the following settings have to be set by each user individually: use_email_as_submitter email_on_ticket_assign email_on_ticket_change login_view_ticketlist email_on_ticket_apichange tickets_per_page there is no way for the admin to a) change the settings for a given user b) set different default settings for new users Reason why this is needed in Jutda Helpdesk: it will make live easier. currently, after a new user is added to the system, I have to execute following code by hand: user_settings['email_on_ticket_assign'] = True user_settings['email_on_ticket_change'] = True user_settings['login_view_ticketlist'] = True .... user.usersettings.settings = user_settings user.usersettings.save() I find this quite annoying, because I tend to forget to do this :) Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) none. Summary of the new feature (a few words): currently all of the following settings have to be set by each user individually: use_email_as_submitter email_on_ticket_assign email_on_ticket_change login_view_ticketlist email_on_ticket_apichange tickets_per_page there is no way for the admin to a) change the settings for a given user b) set different default settings for new users Reason why this is needed in Jutda Helpdesk: it will make live easier. currently, after a new user is added to the system, I have to execute following code by hand: user_settings['email_on_ticket_assign'] = True user_settings['email_on_ticket_change'] = True user_settings['login_view_ticketlist'] = True .... user.usersettings.settings = user_settings user.usersettings.save() I find this quite annoying, because I tend to forget to do this :) Impact on existing areas of Jutda Helpdesk (will it break existing functionality?) none. Sep 11, 2009 issue 111 (Using GMail (Google apps) mail as queue bot.) reported by Mikhail.V.Savchuk - What version of Python are you using? 2.4 What steps will reproduce the problem? When I try to use gmail account as queue address jutda-helpdesk can't send anything. I removed fail_silently in sent_templated_email in lib.py, then i saw sslerror. It's internally not a heplpdesk problem, but Python's one(bug in SMTP lib) as explained here http://www.mail-archive.com/django-users@googlegroups.com/msg36740.html. I've inserted theese stings in send_templated_email import socket socket.setdefaulttimeout(None) Now, it works. What version of Python are you using? 2.4 What steps will reproduce the problem? When I try to use gmail account as queue address jutda-helpdesk can't send anything. I removed fail_silently in sent_templated_email in lib.py, then i saw sslerror. It's internally not a heplpdesk problem, but Python's one(bug in SMTP lib) as explained here http://www.mail-archive.com/django-users@googlegroups.com/msg36740.html. I've inserted theese stings in send_templated_email import socket socket.setdefaulttimeout(None) Now, it works. Sep 09, 2009 issue 102 (allow to CC users to a bug) commented on by andreas.kotowicz - I would mention in the changelog that people need to do a $ python manage.py syncdb after applying this patch. I would mention in the changelog that people need to do a $ python manage.py syncdb after applying this patch. Sep 09, 2009 issue 13 (Enhancement: tag support) commented on by andreas.kotowicz - for people using django-evolution, this is code you can use to update the database. #----- Evolution for helpdesk from django_evolution.mutations import * from django.db import models import tagging from tagging.fields import TagField MUTATIONS = [ AddField('Ticket', 'tags', TagField, initial='', max_length=255) ] #---------------------- for people using django-evolution, this is code you can use to update the database. #----- Evolution for helpdesk from django_evolution.mutations import * from django.db import models import tagging from tagging.fields import TagField MUTATIONS = [ AddField('Ticket', 'tags', TagField, initial='', max_length=255) ] #---------------------- Sep 09, 2009 issue 13 (Enhancement: tag support) Status changed by rwpoulton - Added to Jutda Helpdesk in SVN r140. Thank you for the patch, and my apologies for taking so long to get this added into trunk. Status: Fixed Added to Jutda Helpdesk in SVN r140. Thank you for the patch, and my apologies for taking so long to get this added into trunk. Status: Fixed Sep 09, 2009 r140 (Issue #13 Add Tags to tickets Patch courtesy of david@zettaz...) committed by rwpoulton - Issue #13 Add Tags to tickets Patch courtesy of david@zettazebra.com, adds the ability to add tags to tickets if django-tagging is installed and in use. If django-tagging isn't being used, no change is visible to the user. Issue #13 Add Tags to tickets Patch courtesy of david@zettazebra.com, adds the ability to add tags to tickets if django-tagging is installed and in use. If django-tagging isn't being used, no change is visible to the user. Sep 09, 2009 issue 102 (allow to CC users to a bug) Status changed by rwpoulton - I have added some rudimentary CC: support into SVN as of r139. When viewing a ticket, you can click 'manage' next to the CC: field on the ticket header. From here, you can add an e-mail address or a user, and they will then receive copies of all correspondence sent to the Submitter (using the Submitter templates). This is very rough. There are ticketboxes on the TicketCCForm to allow an email address to view and/or update a ticket; these currently do nothing (they are saved in the DB but unused). I'll do some further changes to this soon to make those fields functional, and probably add some custom templates for CC's rather than using the Submitter template. Status: Started I have added some rudimentary CC: support into SVN as of r139. When viewing a ticket, you can click 'manage' next to the CC: field on the ticket header. From here, you can add an e-mail address or a user, and they will then receive copies of all correspondence sent to the Submitter (using the Submitter templates). This is very rough. There are ticketboxes on the TicketCCForm to allow an email address to view and/or update a ticket; these currently do nothing (they are saved in the DB but unused). I'll do some further changes to this soon to make those fields functional, and probably add some custom templates for CC's rather than using the Submitter template. Status: Started Sep 09, 2009 r139 (Issue #102 Add rudimentary CC: functionality on tickets, con...) committed by rwpoulton - Issue #102 Add rudimentary CC: functionality on tickets, controlled by staff users. CC's can be e-mail addresses or users, who will receive copies of all emails sent to the Submitter. This is a work in progress. Issue #102 Add rudimentary CC: functionality on tickets, controlled by staff users. CC's can be e-mail addresses or users, who will receive copies of all emails sent to the Submitter. This is a work in progress. Sep 09, 2009 issue 104 (Add a CHANGELOG file.) Status changed by rwpoulton - CHANGELOG file added in SVN r138. Status: Fixed CHANGELOG file added in SVN r138. Status: Fixed Sep 09, 2009 r138 (Issue #104: Add CHANGELOG file ) committed by rwpoulton - Issue #104 : Add CHANGELOG file Issue #104 : Add CHANGELOG file Sep 09, 2009 issue 13 (Enhancement: tag support) commented on by andreas.kotowicz - any chance of this patch getting committed into jutda-helpdesk? any chance of this patch getting committed into jutda-helpdesk? Sep 03, 2009 issue 110 (Allow user-defined fields on tickets) commented on by dswoods - I also think this is a great idea. I have been maintaining my own modifications to the forms and models to support new fields, but this won't be sustainable for long, so I've been thinking about a cleaner way of doing this. In addition to everything Mikhail has said above (which I also think are good and useful ideas), I would think that support for custom fields that are only visible/available to staff in ticket forms would be useful to most people. An example would be time spent completing an ticket, for accounting purposes; or being able to set priority as a 'staff-only' field, which makes sense in my case but probably not everyones. I also think this is a great idea. I have been maintaining my own modifications to the forms and models to support new fields, but this won't be sustainable for long, so I've been thinking about a cleaner way of doing this. In addition to everything Mikhail has said above (which I also think are good and useful ideas), I would think that support for custom fields that are only visible/available to staff in ticket forms would be useful to most people. An example would be time spent completing an ticket, for accounting purposes; or being able to set priority as a 'staff-only' field, which makes sense in my case but probably not everyones.

1 - 50 Next ›

Hosted by