My favorites | Sign in
Project Logo
                
Details: Show all Hide all

Earlier this year

  • Oct 21, 2009
    issue 16 (The job failed to run. The exception is shown below. globa...) commented on by pakhomovalex   -   Ok, I solved this. There was a bug in django-mailer. They need to update lockfile.py. For chronograph I'd like to see more details on exceptions - app, source file etc.
    Ok, I solved this. There was a bug in django-mailer. They need to update lockfile.py. For chronograph I'd like to see more details on exceptions - app, source file etc.
  • Oct 21, 2009
    issue 16 (The job failed to run. The exception is shown below. globa...) commented on by pakhomovalex   -   I tried manage.py send_mail in the shell and it worked: acquiring lock... acquired. sending message '[site.site] My Message' to my@mail.com releasing lock... released. So something wrong with cronograph's lockfile?
    I tried manage.py send_mail in the shell and it worked: acquiring lock... acquired. sending message '[site.site] My Message' to my@mail.com releasing lock... released. So something wrong with cronograph's lockfile?
  • Oct 21, 2009
    issue 16 (The job failed to run. The exception is shown below. globa...) commented on by pakhomovalex   -   On freebsd I got another message in log: The job failed to run. The exception is shown below. ------------------------------------------------------------------------ acquiring lock... And that's all.
    On freebsd I got another message in log: The job failed to run. The exception is shown below. ------------------------------------------------------------------------ acquiring lock... And that's all.
  • Oct 21, 2009
    issue 16 (The job failed to run. The exception is shown below. globa...) reported by pakhomovalex   -   What steps will reproduce the problem? I'm not sure this is chronograph issue but it reports of it. So, 1. I added job with command "send_mail" which should send emails. Set as minutely with interval:5 2. It won't start automatically 3. When I start it manually, it fails and creates log What is the expected output? What do you see instead? In cronograph logs in stderr I see only: The job failed to run. The exception is shown below. global name 'thread' is not defined------------------------------------------------------------------------ I have no idea what thread it is talking about. What version of the product are you using? On what operating system? trunk. windows. Please provide any additional information below.
    What steps will reproduce the problem? I'm not sure this is chronograph issue but it reports of it. So, 1. I added job with command "send_mail" which should send emails. Set as minutely with interval:5 2. It won't start automatically 3. When I start it manually, it fails and creates log What is the expected output? What do you see instead? In cronograph logs in stderr I see only: The job failed to run. The exception is shown below. global name 'thread' is not defined------------------------------------------------------------------------ I have no idea what thread it is talking about. What version of the product are you using? On what operating system? trunk. windows. Please provide any additional information below.
  • Aug 11, 2009
    issue 15 (Improvements to Django-Chronograph (Not a bug report)) commented on by kyle.dickerson   -   Here are the changes I made. To avoid confusion I renamed the project to Cron_Manager for my work. There's an included README file with information on how to get things setup (a person will need to be familiar with how Chronograph functions, as I didn't repeat all that information). Some changes that I made that you may want to include really easily are: 1. rrule parameters ignore whitespace 2. You can use Day-of-Week constants in rrules. E.g. MO, TU, WE, TH, FR, SA, SU 3. You can specify how many old log files to keep for each job, and it will automatically make sure that only that many old log files are kept. Let me know if you have any questions about the changes I made. The attached file includes an example which should make it pretty easy to start with.
    Here are the changes I made. To avoid confusion I renamed the project to Cron_Manager for my work. There's an included README file with information on how to get things setup (a person will need to be familiar with how Chronograph functions, as I didn't repeat all that information). Some changes that I made that you may want to include really easily are: 1. rrule parameters ignore whitespace 2. You can use Day-of-Week constants in rrules. E.g. MO, TU, WE, TH, FR, SA, SU 3. You can specify how many old log files to keep for each job, and it will automatically make sure that only that many old log files are kept. Let me know if you have any questions about the changes I made. The attached file includes an example which should make it pretty easy to start with.
  • Aug 11, 2009
    issue 15 (Improvements to Django-Chronograph (Not a bug report)) commented on by kyle.dickerson   -   Attached is the full set of code as I've modified it. One thing you can easily pull out is in the rrule parsing, I made it ignore whitespace, which helps cut out one area of possible screwups, and allows us to use whitespace to separate out rules more clearly. It includes a README with basic information on how to use it (assuming a person already knows how Chronograph is configured). Let me know if you'd like any more detail on my changes. To avoid confusion I renamed the project Cron_Manager for my implementation.
    Attached is the full set of code as I've modified it. One thing you can easily pull out is in the rrule parsing, I made it ignore whitespace, which helps cut out one area of possible screwups, and allows us to use whitespace to separate out rules more clearly. It includes a README with basic information on how to use it (assuming a person already knows how Chronograph is configured). Let me know if you'd like any more detail on my changes. To avoid confusion I renamed the project Cron_Manager for my implementation.
  • Aug 10, 2009
    issue 9 (Error when editing a job) Status changed by wnielson   -   Thanks! I've made the changes in r21.
    Status: Fixed
    Thanks! I've made the changes in r21.
    Status: Fixed
  • Aug 10, 2009
    r21 (Fixed #9 - The urls now work with Django's new url namespace...) committed by wnielson   -   Fixed #9 - The urls now work with Django's new url namespaces.
    Fixed #9 - The urls now work with Django's new url namespaces.
  • Aug 10, 2009
    issue 6 (Use of Batchadmin should be optional) Status changed by wnielson   -   This has been fixed in r20. Batchadmin has been removed all together since Django now supports the functionality natively.
    Status: Fixed
    This has been fixed in r20. Batchadmin has been removed all together since Django now supports the functionality natively.
    Status: Fixed
  • Aug 10, 2009
    r20 (Fixed #6 - Batchadmin is no longer used at all since the fun...) committed by wnielson   -   Fixed #6 - Batchadmin is no longer used at all since the functionality now exists natively in Django.
    Fixed #6 - Batchadmin is no longer used at all since the functionality now exists natively in Django.
  • Aug 10, 2009
    issue 12 (Job got stuck in 'is_running' state) Status changed by wnielson   -   This has been fixed in r19. Thanks for the feedback.
    Status: Fixed
    This has been fixed in r19. Thanks for the feedback.
    Status: Fixed
  • Aug 10, 2009
    r19 (Fixed #12 - The run method of a Job now calls 'call_command'...) committed by wnielson   -   Fixed #12 - The run method of a Job now calls 'call_command' from within a try...except block. Exceptions are caught and logged and the state of a failed job should no longer get stuck in a 'running' state.
    Fixed #12 - The run method of a Job now calls 'call_command' from within a try...except block. Exceptions are caught and logged and the state of a failed job should no longer get stuck in a 'running' state.
  • Aug 08, 2009
    issue 15 (Improvements to Django-Chronograph (Not a bug report)) commented on by wnielson   -   Kyle, Your changes sound very interesting. I'd love to take a look at bringing your changes into chronograph.
    Kyle, Your changes sound very interesting. I'd love to take a look at bringing your changes into chronograph.
  • Aug 08, 2009
    issue 15 (Improvements to Django-Chronograph (Not a bug report)) reported by kyle.dickerson   -   Hey Weston, I hope you monitor these issues. I can't find any other way to easily contact you. I tried posting a comment on your blog, but that seemed to be broken. I've heavily modified the Django-Chronograph code to be more versatile. My modifications make it work like the Admin system to automatically discover installed apps with jobs, and allows those jobs to just point at whatever function they want to call, rather than being limited to a management command. It still keeps the really nice Admin interface for viewing jobs and logs (however changes applied within the interface only live until the webserver restarts). I posted some information about it on my blog: http://dickersonshypotheticalblog.blogspot.com/2009/08/django-cronjobs-made-easy.html. If you're interested in rolling these changes in to Django-Chronograph, let me know. If not I'll probably post it all as my own project. Anyone else finding this can feel free to go to my blog and leave me a comment if you're interested in getting the changes with and example, that I made.
    Hey Weston, I hope you monitor these issues. I can't find any other way to easily contact you. I tried posting a comment on your blog, but that seemed to be broken. I've heavily modified the Django-Chronograph code to be more versatile. My modifications make it work like the Admin system to automatically discover installed apps with jobs, and allows those jobs to just point at whatever function they want to call, rather than being limited to a management command. It still keeps the really nice Admin interface for viewing jobs and logs (however changes applied within the interface only live until the webserver restarts). I posted some information about it on my blog: http://dickersonshypotheticalblog.blogspot.com/2009/08/django-cronjobs-made-easy.html. If you're interested in rolling these changes in to Django-Chronograph, let me know. If not I'll probably post it all as my own project. Anyone else finding this can feel free to go to my blog and leave me a comment if you're interested in getting the changes with and example, that I made.
  • Aug 06, 2009
    issue 13 (The model Job is already registered) commented on by kyle.dickerson   -   I had this problem and went for a more portable solution. I moved JobAdmin into a file called admin_helper.py. Then I import JobAdmin into admin.py and register it, and then have view.py import JobAdmin from the helper file. This solves the double registration, without hard-linking the code to your specific project.
    I had this problem and went for a more portable solution. I moved JobAdmin into a file called admin_helper.py. Then I import JobAdmin into admin.py and register it, and then have view.py import JobAdmin from the helper file. This solves the double registration, without hard-linking the code to your specific project.
  • Jul 24, 2009
    issue 9 (Error when editing a job) commented on by Venom087   -   Django 1.1 added the concept of url namespaces: http://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces Just change the url tag in change_form.html from {% url admin_chronograph_job_run object_id %} to {% url admin:admin_chronograph_job_run object_id %} I hope this helps!
    Django 1.1 added the concept of url namespaces: http://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces Just change the url tag in change_form.html from {% url admin_chronograph_job_run object_id %} to {% url admin:admin_chronograph_job_run object_id %} I hope this helps!
  • Jul 21, 2009
    issue 14 (setup.py doesn't work on Ubuntu 9.04 / Python 2.6) reported by mark.ellul   -   What steps will reproduce the problem? 1. check out latest code 2. sudo python setup.py install 3. run python from different directory i.e. not in django-chronograh 4. import chronograph What is the expected output? What do you see instead? Expected output is >>> What I am getting is an import error The issue being that the "root_dir" from the command root_dir = os.path.dirname(__file__) Is getting assigned to "." using os.getcwd() might be better or removing all that code and using setuptools find_packkages() call for the packages and commenting out the data_files parameter worked for me What version of the product are you using? On what operating system? This is running on Ubuntu 9.04 python 2.6 Please provide any additional information below.
    What steps will reproduce the problem? 1. check out latest code 2. sudo python setup.py install 3. run python from different directory i.e. not in django-chronograh 4. import chronograph What is the expected output? What do you see instead? Expected output is >>> What I am getting is an import error The issue being that the "root_dir" from the command root_dir = os.path.dirname(__file__) Is getting assigned to "." using os.getcwd() might be better or removing all that code and using setuptools find_packkages() call for the packages and commenting out the data_files parameter worked for me What version of the product are you using? On what operating system? This is running on Ubuntu 9.04 python 2.6 Please provide any additional information below.
  • May 18, 2009
    issue 13 (The model Job is already registered) reported by fede.caceres   -   What steps will reproduce the problem? 1. Download the most recent Chronograph app to your app along with batchadmin. 2. Add them to the settings file 3. Add the following line to the root urls.py file: url(r'^admin/chronograph/job/(?P<pk>\d+)/run/$', 'chronograph.views.job_run', name="admin_chronograph_job_run"), 4. Start your app (in this case, development server) 5. Go to the root dir of your app (http://localhost:8000/ in my case) 6. The following error appears: Caught an exception while rendering: The model Job is already registered Traceback: File "C:\Python26\lib\site-packages\django\core\handlers\base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "E:\Dev\Python\mg\trunk\djmastergoal\..\djmastergoal\customtemplatetags\tem platetags\superbreadcrumbs.py" in wrapped 177. return f(*args, **kwargs) File "E:\Dev\Python\mg\trunk\djmastergoal\..\djmastergoal\views.py" in index 18. return render_to_response('main/index.html', {'login_form' : login_form, 'has_team':has_team,}, context_instance=RequestContext(request)) File "C:\Python26\lib\site-packages\django\shortcuts\__init__.py" in render_to_response 18. return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "C:\Python26\lib\site-packages\django\template\loader.py" in render_to_string 107. return t.render(context_instance) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 24. result = self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\defaulttags.py" in render 245. return self.nodelist_true.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 81. raise wrapped Exception Type: TemplateSyntaxError at / Exception Value: Caught an exception while rendering: The model Job is already registered What is the expected output? What do you see instead? No error page, my normal index page. What version of the product are you using? On what operating system? The latest version from the SVN along with Django 1.0.2. Please provide any additional information below. When I remove the url line, all seems to go ok, so I thought it had something to do with the view, looking at the view's code I saw it included the admin module. There seems to be the problem, the admin module is running the "admin.site.register" lines at the end twice, one when being included by the django admin register and the second one when generating the urls. How did I fix this? I added an if statement before the two lines at the admin.py module, something like this: if __name__[:12] == "djmastergoal": # djmastergoal is the name of my project admin.site.register(Job, JobAdmin) admin.site.register(Log, LogAdmin) That seemed to fix it.
    What steps will reproduce the problem? 1. Download the most recent Chronograph app to your app along with batchadmin. 2. Add them to the settings file 3. Add the following line to the root urls.py file: url(r'^admin/chronograph/job/(?P<pk>\d+)/run/$', 'chronograph.views.job_run', name="admin_chronograph_job_run"), 4. Start your app (in this case, development server) 5. Go to the root dir of your app (http://localhost:8000/ in my case) 6. The following error appears: Caught an exception while rendering: The model Job is already registered Traceback: File "C:\Python26\lib\site-packages\django\core\handlers\base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "E:\Dev\Python\mg\trunk\djmastergoal\..\djmastergoal\customtemplatetags\tem platetags\superbreadcrumbs.py" in wrapped 177. return f(*args, **kwargs) File "E:\Dev\Python\mg\trunk\djmastergoal\..\djmastergoal\views.py" in index 18. return render_to_response('main/index.html', {'login_form' : login_form, 'has_team':has_team,}, context_instance=RequestContext(request)) File "C:\Python26\lib\site-packages\django\shortcuts\__init__.py" in render_to_response 18. return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "C:\Python26\lib\site-packages\django\template\loader.py" in render_to_string 107. return t.render(context_instance) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 97. return compiled_parent.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 176. return self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\loader_tags.py" in render 24. result = self.nodelist.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 71. result = node.render(context) File "C:\Python26\lib\site-packages\django\template\defaulttags.py" in render 245. return self.nodelist_true.render(context) File "C:\Python26\lib\site-packages\django\template\__init__.py" in render 768. bits.append(self.render_node(node, context)) File "C:\Python26\lib\site-packages\django\template\debug.py" in render_node 81. raise wrapped Exception Type: TemplateSyntaxError at / Exception Value: Caught an exception while rendering: The model Job is already registered What is the expected output? What do you see instead? No error page, my normal index page. What version of the product are you using? On what operating system? The latest version from the SVN along with Django 1.0.2. Please provide any additional information below. When I remove the url line, all seems to go ok, so I thought it had something to do with the view, looking at the view's code I saw it included the admin module. There seems to be the problem, the admin module is running the "admin.site.register" lines at the end twice, one when being included by the django admin register and the second one when generating the urls. How did I fix this? I added an if statement before the two lines at the admin.py module, something like this: if __name__[:12] == "djmastergoal": # djmastergoal is the name of my project admin.site.register(Job, JobAdmin) admin.site.register(Log, LogAdmin) That seemed to fix it.
  • May 12, 2009
    issue 12 (Job got stuck in 'is_running' state) commented on by ni...@nomadjourney.com   -   I noticed that the 'is_running' flag was added in r18. Here is the code that handles setting and unsetting the flag: self.is_running = True self.save() call_command(self.command, *args, **options) self.is_running = False self.save() Maybe it would be a good idea if the 'call_command' call was wrapped in a try..except block just in case. There is a possibility that the managenent command being run throw an exception. In this case, you can catch it and set is_running = False so future job runs don't get stuck. Would be great if the exception could be logged as well.
    I noticed that the 'is_running' flag was added in r18. Here is the code that handles setting and unsetting the flag: self.is_running = True self.save() call_command(self.command, *args, **options) self.is_running = False self.save() Maybe it would be a good idea if the 'call_command' call was wrapped in a try..except block just in case. There is a possibility that the managenent command being run throw an exception. In this case, you can catch it and set is_running = False so future job runs don't get stuck. Would be great if the exception could be logged as well.
  • May 11, 2009
    issue 12 (Job got stuck in 'is_running' state) commented on by ni...@nomadjourney.com   -   Here is the output from the last job run before it got stuck: stderr: ------------------------------------------------------------------------ acquiring lock... acquired. releasing lock... released. 0 sent; 0 deferred; 0 don't send done in 0.00 seconds There was no output on stdout.
    Here is the output from the last job run before it got stuck: stderr: ------------------------------------------------------------------------ acquiring lock... acquired. releasing lock... released. 0 sent; 0 deferred; 0 don't send done in 0.00 seconds There was no output on stdout.
  • May 11, 2009
    issue 12 (Job got stuck in 'is_running' state) reported by ni...@nomadjourney.com   -   I have a django-mailer job that runs every 5 minutes. Today it just got stuck in the 'is_running' state. I had to manually update the database table and set it to 0 before it started working again. Not sure how to reproduce the problem. Here are the settings for my job: frequency: Minutely params: interval:5
    I have a django-mailer job that runs every 5 minutes. Today it just got stuck in the 'is_running' state. I had to manually update the database table and set it to 0 before it started working again. Not sure how to reproduce the problem. Here are the settings for my job: frequency: Minutely params: interval:5
  • May 06, 2009
    r18 (Fixed an issue involving long-running processes. NOTE: this...) committed by wnielson   -   Fixed an issue involving long-running processes. NOTE: this involves a change to the model, so you will need to update your database tables. Also added current date and time display to the job's change_list page.
    Fixed an issue involving long-running processes. NOTE: this involves a change to the model, so you will need to update your database tables. Also added current date and time display to the job's change_list page.
  • Apr 28, 2009
    issue 11 (Can't check out via SVN) commented on by wnielson   -   The following doesn't work? svn co http://django-chronograph.googlecode.com/svn/trunk/chronograph/ I just successfully checked out using the above command.
    The following doesn't work? svn co http://django-chronograph.googlecode.com/svn/trunk/chronograph/ I just successfully checked out using the above command.
  • Apr 28, 2009
    issue 11 (Can't check out via SVN) reported by mail.baxter   -   What steps will reproduce the problem? 1. Attempting to check out via SVN What is the expected output? What do you see instead? Expected: files Instead: -bash: http://django-chronograph.googlecode.com/svn/trunk/chronograph/: No such file or directory
    What steps will reproduce the problem? 1. Attempting to check out via SVN What is the expected output? What do you see instead? Expected: files Instead: -bash: http://django-chronograph.googlecode.com/svn/trunk/chronograph/: No such file or directory
  • Apr 24, 2009
    issue 10 (Management command to clean up old job logs) commented on by ni...@nomadjourney.com   -   Sure. Here is a custom command I was using in the interim that you can just add to this project. Feel free to clean up anything you see fit. The command takes two args: cron_clean <unit> <interval> Where unit is one of weeks, days, hours or minutes and interval is an integer value. E.g., cron_clean days 5 Will clean up logs older than 5 days.
    Sure. Here is a custom command I was using in the interim that you can just add to this project. Feel free to clean up anything you see fit. The command takes two args: cron_clean <unit> <interval> Where unit is one of weeks, days, hours or minutes and interval is an integer value. E.g., cron_clean days 5 Will clean up logs older than 5 days.
  • Apr 24, 2009
    issue 10 (Management command to clean up old job logs) commented on by wnielson   -   Sounds reasonable to me. If you work up a patch, I'll work it in, else I'll add this when I've got some time.
    Sounds reasonable to me. If you work up a patch, I'll work it in, else I'll add this when I've got some time.
  • Apr 24, 2009
    issue 10 (Management command to clean up old job logs) reported by ni...@nomadjourney.com   -   I have couple of jobs that run every minute and after a while, the job log table ends up having thousands of entries. It would be nice to have a management command that can go through and clean up entries older than a specified number of days. E.g., django-admin.py cron_clean 5 Would clear out anything older than 5 days.
    I have couple of jobs that run every minute and after a while, the job log table ends up having thousands of entries. It would be nice to have a management command that can go through and clean up entries older than a specified number of days. E.g., django-admin.py cron_clean 5 Would clear out anything older than 5 days.
  • Apr 23, 2009
    issue 9 (Error when editing a job) commented on by wnielson   -   Hrmm, I'm not sure why that is happening. Django 1.1 beta 1 is recent enough to work, so I don't think that is the issue. What does you root urls.py look like?
    Hrmm, I'm not sure why that is happening. Django 1.1 beta 1 is recent enough to work, so I don't think that is the issue. What does you root urls.py look like?
  • Apr 22, 2009
    issue 9 (Error when editing a job) reported by camilo.nova   -   Hi, great job, i get this error when trying to edit a job. -- Environment: Request Method: GET Request URL: http://localhost:8000/admin/chronograph/job/2/ Django Version: 1.1 beta 1 Python Version: 2.5.2 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.humanize', 'chronograph', 'atlantis.local_apps.parametros', 'atlantis.local_apps.terceros', 'atlantis.local_apps.facturacion'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware') Template error: In template /home/camilo/Dropbox/workspace/atlantis/chronograph/templates/admin/chronograph/job/change_form.html, error at line 7 Caught an exception while rendering: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found. 1 : {% extends "admin/change_form.html" %} 2 : {% load i18n %} 3 : {% block object-tools %} 4 : {% if change %}{% if not is_popup %} 5 : <ul class="object-tools"> 6 : <li><a href="history/" class="historylink">{% trans "History" %}</a></li> 7 : <li><a href=" {% url admin_chronograph_job_run object_id %} " class="viewsitelink">{% trans "Run Job" %}</a></li> 8 : {% if has_absolute_url %} 9 : <li><a href="../../../r/{{ content_type_id }}/{{ object_id }}/" class="viewsitelink"> 10 : {% trans "View on site" %}</a> 11 : </li> 12 : {% endif%} 13 : </ul> 14 : {% endif %}{% endif %} 15 : {% endblock %} Traceback: File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py" in get_response 92. response = callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in root 480. return self.model_page(request, *url.split('/', 2)) File "/usr/lib/python2.5/site-packages/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in model_page 499. return admin_obj(request, rest_of_url) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in __call__ 1092. return self.change_view(request, unquote(url)) File "/usr/lib/python2.5/site-packages/django/db/transaction.py" in _commit_on_success 240. res = func(*args, **kw) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in change_view 870. return self.render_change_form(request, context, change=True, obj=obj) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in render_change_form 587. ], context, context_instance=template.RequestContext(request)) File "/usr/lib/python2.5/site-packages/django/shortcuts/__init__.py" in render_to_response 20. return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "/usr/lib/python2.5/site-packages/django/template/loader.py" in render_to_string 108. return t.render(context_instance) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 24. result = self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 24. result = self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py" in render 243. return self.nodelist_true.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py" in render 243. return self.nodelist_true.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 81. raise wrapped Exception Type: TemplateSyntaxError at /admin/chronograph/job/2/ Exception Value: Caught an exception while rendering: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found. Original Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/django/template/debug.py", line 71, in render_node result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py", line 382, in render raise e NoReverseMatch: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found.
    Hi, great job, i get this error when trying to edit a job. -- Environment: Request Method: GET Request URL: http://localhost:8000/admin/chronograph/job/2/ Django Version: 1.1 beta 1 Python Version: 2.5.2 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.humanize', 'chronograph', 'atlantis.local_apps.parametros', 'atlantis.local_apps.terceros', 'atlantis.local_apps.facturacion'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware') Template error: In template /home/camilo/Dropbox/workspace/atlantis/chronograph/templates/admin/chronograph/job/change_form.html, error at line 7 Caught an exception while rendering: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found. 1 : {% extends "admin/change_form.html" %} 2 : {% load i18n %} 3 : {% block object-tools %} 4 : {% if change %}{% if not is_popup %} 5 : <ul class="object-tools"> 6 : <li><a href="history/" class="historylink">{% trans "History" %}</a></li> 7 : <li><a href=" {% url admin_chronograph_job_run object_id %} " class="viewsitelink">{% trans "Run Job" %}</a></li> 8 : {% if has_absolute_url %} 9 : <li><a href="../../../r/{{ content_type_id }}/{{ object_id }}/" class="viewsitelink"> 10 : {% trans "View on site" %}</a> 11 : </li> 12 : {% endif%} 13 : </ul> 14 : {% endif %}{% endif %} 15 : {% endblock %} Traceback: File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py" in get_response 92. response = callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in root 480. return self.model_page(request, *url.split('/', 2)) File "/usr/lib/python2.5/site-packages/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in model_page 499. return admin_obj(request, rest_of_url) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in __call__ 1092. return self.change_view(request, unquote(url)) File "/usr/lib/python2.5/site-packages/django/db/transaction.py" in _commit_on_success 240. res = func(*args, **kw) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in change_view 870. return self.render_change_form(request, context, change=True, obj=obj) File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" in render_change_form 587. ], context, context_instance=template.RequestContext(request)) File "/usr/lib/python2.5/site-packages/django/shortcuts/__init__.py" in render_to_response 20. return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs) File "/usr/lib/python2.5/site-packages/django/template/loader.py" in render_to_string 108. return t.render(context_instance) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 97. return compiled_parent.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 178. return self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 24. result = self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/loader_tags.py" in render 24. result = self.nodelist.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py" in render 243. return self.nodelist_true.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 71. result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py" in render 243. return self.nodelist_true.render(context) File "/usr/lib/python2.5/site-packages/django/template/__init__.py" in render 779. bits.append(self.render_node(node, context)) File "/usr/lib/python2.5/site-packages/django/template/debug.py" in render_node 81. raise wrapped Exception Type: TemplateSyntaxError at /admin/chronograph/job/2/ Exception Value: Caught an exception while rendering: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found. Original Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/django/template/debug.py", line 71, in render_node result = node.render(context) File "/usr/lib/python2.5/site-packages/django/template/defaulttags.py", line 382, in render raise e NoReverseMatch: Reverse for 'admin_chronograph_job_run' with arguments '(u'2',)' and keyword arguments '{}' not found.
  • Apr 16, 2009
    issue 8 (Run job link broken in logs area) Status changed by wnielson   -   Thanks!
    Status: Fixed
    Thanks!
    Status: Fixed
  • Apr 16, 2009
    r17 (Fixed #8: Moved change_form for job into the proper folder. ...) committed by wnielson   -   Fixed #8: Moved change_form for job into the proper folder. Thanks alexander.j.robbins.
    Fixed #8: Moved change_form for job into the proper folder. Thanks alexander.j.robbins.
  • Apr 15, 2009
    issue 8 (Run job link broken in logs area) reported by alexander.j.robbins   -   The change_form.html template works great when inspecting jobs. However, it is also available when I view logs. If I click on run job when viewing a log, it runs whatever job happens to have the same pk as the log I am viewing. If you move the template into a model specific folder then it will only show up for jobs, which it works very well for. Move from chronograph/templates/admin/chronograph/change_form.html to chronograph/templates/admin/chronograph/job/change_form.html Thanks.
    The change_form.html template works great when inspecting jobs. However, it is also available when I view logs. If I click on run job when viewing a log, it runs whatever job happens to have the same pk as the log I am viewing. If you move the template into a model specific folder then it will only show up for jobs, which it works very well for. Move from chronograph/templates/admin/chronograph/change_form.html to chronograph/templates/admin/chronograph/job/change_form.html Thanks.
  • Apr 15, 2009
    issue 7 (Ordering of url entries) reported by alexander.j.robbins   -   What steps will reproduce the problem? 1. Use the url fix for django 1.0 2. Put the url after the admin.site.root url. What is the expected output? What do you see instead? The run job button won't work. The admin site will catch the request, then die since "1/run" isn't a valid int for primary key lookup. The custom url and handler will never get called. What version of the product are you using? On what operating system? Django 1.0 Please provide any additional information below. Just make sure that people know they should put that additional url in their urls ABOVE the normal admin site entry. Otherwise it will 500 every time that button is clicked.
    What steps will reproduce the problem? 1. Use the url fix for django 1.0 2. Put the url after the admin.site.root url. What is the expected output? What do you see instead? The run job button won't work. The admin site will catch the request, then die since "1/run" isn't a valid int for primary key lookup. The custom url and handler will never get called. What version of the product are you using? On what operating system? Django 1.0 Please provide any additional information below. Just make sure that people know they should put that additional url in their urls ABOVE the normal admin site entry. Otherwise it will 500 every time that button is clicked.
  • Mar 24, 2009
    issue 6 (Use of Batchadmin should be optional) commented on by Gerry.Eisenhaur   -   (sorry about the blank issue, damn enter button came outta no where) I think the use batchadmin should be based on it being installed for the current project, and on it being in the PYTHON path.
    (sorry about the blank issue, damn enter button came outta no where) I think the use batchadmin should be based on it being installed for the current project, and on it being in the PYTHON path.
  • Mar 24, 2009
    issue 6 (Use of Batchadmin should be optional) reported by Gerry.Eisenhaur   -   What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below.
    What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below.
  • Mar 20, 2009
    issue 5 (Better handling for exceptions) commented on by wnielson   -   Yah, I like the idea of having some way to tell if the job ran successfully or not. I think adding another field to keep track of the result of a run will probably be useful. I'll play with it a bit and see what I can come up with. Thanks for the input!
    Yah, I like the idea of having some way to tell if the job ran successfully or not. I think adding another field to keep track of the result of a run will probably be useful. I'll play with it a bit and see what I can come up with. Thanks for the input!
  • Mar 16, 2009
    issue 5 (Better handling for exceptions) reported by alexander.j.robbins   -   I was setting up a job today and couldn't get it to work. Turns out a permission issue on the staging server was killing it. It wasn't that hard to find once I ran the command manually, but it would be nice if the exceptions were just logged. Also, the one command blowing up kept all the others from ever being run. I attached a patch that would catch all exceptions and then add them to the end of the stderr log. That helps with debugging, and also allows all of the other commands to run normally when one is failing. Some questions came up when I was writing this: -Should the job still be marked as run if it blew up? -Should the job be marked as failing somehow? -Should the log have an area to indicate a failed run (some kind of boolean)? Anyway, this would make things more usable for me. I guess the other option is for me to stop writing code that breaks...
    I was setting up a job today and couldn't get it to work. Turns out a permission issue on the staging server was killing it. It wasn't that hard to find once I ran the command manually, but it would be nice if the exceptions were just logged. Also, the one command blowing up kept all the others from ever being run. I attached a patch that would catch all exceptions and then add them to the end of the stderr log. That helps with debugging, and also allows all of the other commands to run normally when one is failing. Some questions came up when I was writing this: -Should the job still be marked as run if it blew up? -Should the job be marked as failing somehow? -Should the log have an area to indicate a failed run (some kind of boolean)? Anyway, this would make things more usable for me. I guess the other option is for me to stop writing code that breaks...
  • Mar 13, 2009
    issue 2 (ModelAdmin.get_urls() not supported on Django-1.0) Status changed by wnielson   -   Thanks for the workaround. I've incorporated the changes.
    Status: Fixed
    Thanks for the workaround. I've incorporated the changes.
    Status: Fixed
  • Mar 13, 2009
    r16 (Fixes #2 - added support for Django 1.0. Thanks nathforge.) committed by wnielson   -   Fixes #2 - added support for Django 1.0. Thanks nathforge.
    Fixes #2 - added support for Django 1.0. Thanks nathforge.
  • Mar 13, 2009
    OlderDjango Wiki page deleted by wnielson
  • Mar 13, 2009
    OlderDjango Wiki page added by wnielson
  • Mar 13, 2009
    issue 3 (Doctest fails) Status changed by wnielson   -   Nice catch.
    Status: Fixed
    Nice catch.
    Status: Fixed
  • Mar 13, 2009
    r13 (Fixes #3 - Doctest in Job no longer fails. Thanks alexander...) committed by wnielson   -   Fixes #3 - Doctest in Job no longer fails. Thanks alexander.j.robbins.
    Fixes #3 - Doctest in Job no longer fails. Thanks alexander.j.robbins.
  • Mar 13, 2009
    issue 4 (Logs created even if no output) Status changed by wnielson   -   Thanks! This is fixed in revision 12.
    Status: Fixed
    Thanks! This is fixed in revision 12.
    Status: Fixed
  • Mar 13, 2009
    r12 (Fixes #4 - Logs are only created if there is output from std...) committed by wnielson   -   Fixes #4 - Logs are only created if there is output from stderr or stdout. Thanks alexander.j.robbins.
    Fixes #4 - Logs are only created if there is output from stderr or stdout. Thanks alexander.j.robbins.
  • Mar 12, 2009
    issue 4 (Logs created even if no output) reported by alexander.j.robbins   -   What steps will reproduce the problem? 1. Run a command that doesn't produce any stdout or stderr What is the expected output? What do you see instead? I don't expect to get a log entry. But I do get one. What version of the product are you using? On what operating system? r11. Ubuntu. Please provide any additional information below. It looks like the problem is that you say: if stdout or stderr: make_a_log() However, StringIOs seem to always be true, even when empty. Switching that to if stdout.getvalue() or stderr.getvalue(): make_a_log() seems to fix it. I attached a diff, but the change is pretty simple. Thanks for this awesome app. I love it!
    What steps will reproduce the problem? 1. Run a command that doesn't produce any stdout or stderr What is the expected output? What do you see instead? I don't expect to get a log entry. But I do get one. What version of the product are you using? On what operating system? r11. Ubuntu. Please provide any additional information below. It looks like the problem is that you say: if stdout or stderr: make_a_log() However, StringIOs seem to always be true, even when empty. Switching that to if stdout.getvalue() or stderr.getvalue(): make_a_log() seems to fix it. I attached a diff, but the change is pretty simple. Thanks for this awesome app. I love it!
  • Mar 10, 2009
    issue 3 (Doctest fails) reported by alexander.j.robbins   -   What steps will reproduce the problem? ./manage.py test chronograph What is the expected output? What do you see instead? ... F.. It looks like the doctest in your Job model thinks job is called Rule. I tried changing that Rule to Job and everything works fine. Thanks for this awesome app! What version of the product are you using? On what operating system? r11 Please provide any additional information below.
    What steps will reproduce the problem? ./manage.py test chronograph What is the expected output? What do you see instead? ... F.. It looks like the doctest in your Job model thinks job is called Rule. I tried changing that Rule to Job and everything works fine. Thanks for this awesome app! What version of the product are you using? On what operating system? r11 Please provide any additional information below.
  • Mar 08, 2009
    issue 2 (ModelAdmin.get_urls() not supported on Django-1.0) reported by nathforge   -   What steps will reproduce the problem? Edit a chronograph job in Django-1.0 What is the expected output? What do you see instead? Exception: TemplateSyntaxError at /admin/chronograph/job/1/ Caught an exception while rendering: Reverse for 'project.admin_chronograph_job_run' with arguments '(u'1',)' and keyword arguments '{}' not found. What version of the product are you using? On what operating system? SVN revision 11 Please provide any additional information below. Django-1.0 doesn't support ModelAdmin.get_urls() - http://docs.djangoproject.com/en/dev/ref/contrib/admin/#get-urls-self As a workaround, I have this in chronograph/views.py: from django.contrib import admin from django.contrib.auth.decorators import user_passes_test from admin import JobAdmin from models import Job def job_run(request, pk): return JobAdmin(Job, admin.site).run_job_view(request, pk) job_run = user_passes_test(lambda user: user.is_superuser)(job_run) And a new pattern in my project's urls.py: url(r'^admin/chronograph/job/(?P<pk>\d+)/run/$', 'chronograph.views.job_run', name="admin_chronograph_job_run")
    What steps will reproduce the problem? Edit a chronograph job in Django-1.0 What is the expected output? What do you see instead? Exception: TemplateSyntaxError at /admin/chronograph/job/1/ Caught an exception while rendering: Reverse for 'project.admin_chronograph_job_run' with arguments '(u'1',)' and keyword arguments '{}' not found. What version of the product are you using? On what operating system? SVN revision 11 Please provide any additional information below. Django-1.0 doesn't support ModelAdmin.get_urls() - http://docs.djangoproject.com/en/dev/ref/contrib/admin/#get-urls-self As a workaround, I have this in chronograph/views.py: from django.contrib import admin from django.contrib.auth.decorators import user_passes_test from admin import JobAdmin from models import Job def job_run(request, pk): return JobAdmin(Job, admin.site).run_job_view(request, pk) job_run = user_passes_test(lambda user: user.is_superuser)(job_run) And a new pattern in my project's urls.py: url(r'^admin/chronograph/job/(?P<pk>\d+)/run/$', 'chronograph.views.job_run', name="admin_chronograph_job_run")
  • Mar 02, 2009
    r11 (Improved logs admin page.) committed by wnielson   -   Improved logs admin page.
    Improved logs admin page.
  • Mar 02, 2009
    r10 (Updated docstrings and help texts.) committed by wnielson   -   Updated docstrings and help texts.
    Updated docstrings and help texts.
 
Hosted by Google Code