2009-08-31 17:36:21 +00:00
|
|
|
# coding: utf-8
|
|
|
|
|
|
|
|
# maposmatic, the web front-end of the MapOSMatic city map generation system
|
|
|
|
# Copyright (C) 2009 David Decotigny
|
|
|
|
# Copyright (C) 2009 Frédéric Lehobey
|
|
|
|
# Copyright (C) 2009 David Mentré
|
|
|
|
# Copyright (C) 2009 Maxime Petazzoni
|
|
|
|
# Copyright (C) 2009 Thomas Petazzoni
|
|
|
|
# Copyright (C) 2009 Gaël Utard
|
|
|
|
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU Affero General Public License as
|
|
|
|
# published by the Free Software Foundation, either version 3 of the
|
|
|
|
# License, or any later version.
|
|
|
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU Affero General Public License for more details.
|
|
|
|
|
|
|
|
# You should have received a copy of the GNU Affero General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
import datetime
|
2017-05-22 18:49:15 +00:00
|
|
|
import os
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
|
2009-08-29 09:06:30 +00:00
|
|
|
from django import template
|
|
|
|
from django.utils.safestring import mark_safe
|
2009-09-01 09:46:12 +00:00
|
|
|
from django.utils.translation import ugettext_lazy as _
|
2009-08-29 09:06:30 +00:00
|
|
|
|
|
|
|
register = template.Library()
|
|
|
|
|
|
|
|
def job_status_to_str(value, arg, autoescape=None):
|
|
|
|
if value == 0:
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("Waiting for rendering to begin...")
|
2009-08-29 09:06:30 +00:00
|
|
|
elif value == 1:
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("The rendering is in progress...")
|
2009-08-29 09:06:30 +00:00
|
|
|
elif value == 2:
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
if arg == 'ok':
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("Rendering was successful.")
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
else:
|
2016-11-15 09:08:49 +00:00
|
|
|
return _("Rendering failed! Please contact hartmut@php.net for more information.")
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
elif value == 3:
|
|
|
|
if arg == 'ok':
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("Rendering is obsolete: the rendering was successful, but the files are no longer available.")
|
2009-08-29 09:06:30 +00:00
|
|
|
else:
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("Obsolete failed rendering: the rendering failed, and the incomplete files have been removed.")
|
Job cancel feature
This change introduces the job cancel feature as requested in bug #28488
(https://savannah.nongnu.org/bugs/?28488).
To do so, a new field called 'nonce' is added to the MapRenderingJob
model object (which results in a new column in the database, see below
how to recreate/update a current database). A random string, called the
nonce, is generated when the job is created and stored alongside the
other information on this job. The user is then redirected to the
/jobs/ID/NONCE page, instead of simply /jobs/ID.
As long as the user provides the correct nonce at the end of the URL, he
will have the ability, if the job is still in the queue, to cancel the
job request. The button to cancel the request is shown if and only if
the user provides the matching nonce string in the URL, which is only
displayed when the job is created.
A new job state is also created (4, Cancelled) to match this new
cancelled state.
As far as the database change goes, the easiest if you are only doing
development is to drop your database and recreate it with syncdb. If you
need to keep your data, you can simply add the column to the
maposmatic_maprenderingjob table using the following statement:
ALTER TABLE maposmatic_maprenderingjob ADD COLUMN
nonce varchar(16) NOT NULL;
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@enix.org>
2010-06-20 17:40:11 +00:00
|
|
|
elif value == 4:
|
2010-11-01 19:17:48 +00:00
|
|
|
return _("The rendering was cancelled by the user.")
|
Improve the file cleanup mechanism
Previously, when the rendering directory was over the defined threshold,
files where removed progressively, oldest first, to make up some space.
No information was kept about jobs whose files were removed, making it
harder to keep track of valid jobs with files available.
This change introduces two new things:
1. a new job status, 3, for jobs processed but now without files, or
"obsolete" jobs.
2. a new cleanup mechanism that considers jobs as the atomic unit of
cleaning instead of files, as this would leave with jobs without
all their renderings (which didn't make much sense).
The cleanup function underwent the following modifications:
* files are now sorted by content modification time and not last
metadata change (a simple chmod could mess up the order);
* thumbnails are excluded from the list of considered files for
removal (this is still is discussion, but for now let's keep them);
* when a file needs to be removed, all files from its parent job are
removed and the job's status is set to 3 (see
MapRenderingJob#remove_all_files).
* if no parent job can be found, it's an orphaned file and can be
safely removed. Files starting with a '.' are of course preserved;
* some logging improvements during the cleanup phase.
New 'job-done-obsolete' and 'job-error-obsolete' status icons are now
available, and the status icon filename is now inferred with a custom
template tag (this also led to some cleanup in extratags.py).
The file size of the renderings is also displayed next to each format in
the job information.
Signed-off-by: Maxime Petazzoni <maxime.petazzoni@bulix.org>
2010-01-13 13:46:40 +00:00
|
|
|
|
|
|
|
return ''
|
2009-08-29 09:06:30 +00:00
|
|
|
|
2009-10-07 07:16:03 +00:00
|
|
|
def feedparsed(value):
|
|
|
|
return datetime.datetime(*value[:6])
|
|
|
|
|
2017-05-22 18:49:15 +00:00
|
|
|
def gpx_basename(value):
|
|
|
|
return os.path.basename(value.name)
|
|
|
|
|
2009-08-29 09:06:30 +00:00
|
|
|
register.filter('job_status_to_str', job_status_to_str)
|
2009-10-07 07:16:03 +00:00
|
|
|
register.filter('feedparsed', feedparsed)
|
2010-08-04 20:03:07 +00:00
|
|
|
register.filter('abs', lambda x: abs(x))
|
2012-12-13 05:56:10 +00:00
|
|
|
register.filter('getitem', lambda d,i: d.get(i,''))
|
2017-05-22 18:49:15 +00:00
|
|
|
register.filter('gpx_basename', gpx_basename)
|