El proyecto pretender configurar un CMS opensource desarrollando los módulos necesarios de modo que permita ofrecer funcionalidades de administración electrónica adaptadas a las principales exigencias de la Ley 11/2007, de acceso electrónico de los ciudadanos a los servicios públicos. Se persigue además que el sistema sea fácilmente parametrizable.

El proyecto surge tras comprobar que el coste (no sólo económico) de acceso a la tecnología era uno de los principales obstáculos para el desarrollo de la administración electrónica entre las entidades locales.

Por otra parte, existen claros casos de éxito en otros ámbitos, como las aplicaciones de eLearning opensource que están siendo utilizadas por numerosas universidades como plataformas para sus aulas virtuales.

Para ello se ha efectuado un estudio de los principales procedimientos de las entidades locales de tamaño medio y reducido a los efectos de analizar cómo se traducen las exigencias de la Ley 11/2007 en su gestión.

También se han estudiado los diversos CMS OpenSource y se ha elegido DRUPAL, por múltiples motivos entre los que destacan:

• Su flexibilidad.
• El tratamiento de los perfiles de usuarios.
• Sus posibilidades multisite.
• La existencia de módulos ya desarrollados que permitían una parte de las funcionalidades pretendidas.
• Su amplia comunidad de usuarios que permite obtener soporte de instalación y mantenimiento a un coste reducido.
• search engine optimized

El drupalX509, tras los desarrollos adicionales efectuados y la configuración ofrecida tiene las siguientes funcionalidades:

La identificación de los ciudadanos se efectúa mediante:

• Los sistemas de firma incorporados al DNI electrónico.
• Otros sistemas de firma electrónica avanzada.
• Mediante claves concertadas (usuario y contraseña) que pueda expedir la administración a través de un procedimiento de registro previo.

El sistema permite a los administradores del sistema, sin necesidad de programación, crear formularios normalizados mediante los que se iniciarán los procedimientos o servicios que se den de alta.

También se puede crear una solicitud genérica (solicita/expone) que permitirá presentar cualquier escrito o solicitud distinto de los anteriores.

Las solicitudes o documentos electrónicos mediante los que se inician procedimientos a través de la aplicación se firman mediante firma electrónica con carácter opcional u obligatorio, en función de lo que es establezca cuando se cree cada solicitud.

A la firma se le puede añadir un sello de tiempo.

El administrador del sistema puede, de nuevo sin necesidad de programación, definir los distintos trámites a efectuar en cada procedimiento. En concreto es posible:

• Definir los campos de cada trámite, que pueden incluir documentos adjuntos.
• Definir, por roles, el funcionario o grupo de funcionarios que podrán visualizar y cumplimentar el trámite.
• Definir el flujo de trabajo y las acciones que cada rol (funcionario o grupo de funcionarios) puede realizar en el trámite (pasa a la siguiente fase, vuelve a la anterior, finalizado, etc.).

El sistema permite:

• Controlar que cada rol de funcionarios sólo accedan, para consultar o tramitar, a aquellos procedimientos para los están autorizados.
• Que el ciudadano tenga acceso al estado de tramitación del procedimiento, a los trámites realizados y a la resolución final.
• Que pueda controlarse el tiempo transcurrido en cada una de las fases del procedimiento.
• Que un trámite pueda ser reconducido a otro, cuando el ciudadano se haya equivocado al presentar la solicitud o haya presentado una solicitud general para un procedimiento que tiene prevista tramitación.

Los módulos de DRUPAL utilizados son los siguientes:

Se utiliza este módulo para permitir adjuntar documentación tanto en la presentación de la solicitud, como en las distintas fases de los procedimientos. Más información sobre el módulo upload.

Permite crear tipos de contenido. Se utiliza este módulo para para crear un tipo de contenido para cada trámite que se quiera definir dentro de los procedimientos. Permite definir los campos a rellenar en cada trámite. Mediante la configuración de permisos se puede determinar que campo puede ver y editar cada rol de usuarios (funcionario o grupos de funcionarios). Más información sobre el módulo CCK.

Se utiliza este módulo para realizar acciones automáticas. Configuramos un trigger para pasar un nodo recién creado del estado created al siguiente definido en el Workflow. También puede utilizarse para gestionar avisos al cambiar el estado de los distintos trámites. Más información sobre el módulo trigger.

Permite especificar que menús y enlaces de los menús puede ver cada rol. Se utiliza para establecer que las opciones para usuarios internos del sistema no sean visibles para los ciudadanos. Más información sobre el módulo Menu per rol.

Permite establecer un flujo de trabajo sobre los nodos, así como controlar su visibilidad. Con este módulo, definimos los estados y transiciones para cada trámite, así como dependiendo de su estado, se puede definir que rol lo puede ver y editar. Es el módulo más importante de la fase de tramitación de las solicitudes. Más información sobre el módulo workflow.

Los módulos aquí mencionados pueden descargarse desde http://forja.uji.es/frs/?group_id=34

Además de los anteriores, para el desarrollo del proyecto se han desarrollado o adaptado los siguientes módulos:

Este módulo se ha desarrollado con la finalidad de permitir la identificacion de los usuarios mediante el uso de certificados de firma electrónica. Sus funcionalidades son las siguientes:

• Permite permite la autenticación en DRUPAL utilizando alternativamente usuario y contraseña o certificado X509.
• Los usuarios autenticados tienen un rol diferente a los usuarios autenticados con usuario y contraseña. De este modo se permite discriminar el acceso al contenido en función del tipo de autenticación.
• Cuando el usuario que accede con certificado válido no está dado de alta previamente el en sistema, se el módulo crea crea uno nuevo con el DNI, mail y primeros caracteres del nombre del certificado.
• La validez del certificado se comprueba vía OCSP.
• Este módulo hace uso del protocolo de autenticación cruzada que permite delegar la autenticación SSL del cliente en un tercero, de forma que la máquina en la que se instala el CMS no tiene la obligación de implementar el protocolo SSL ni de instalar un certificado de servidor.

Para comprobar el certificado, además de realizar la autenticación SSL, deben extraerse sus datos públicos y remitirse a un Prestador de Servicios de Certificación que constate si el certificado todavía no es válido, ha expirado o ha sido revocado.

Desde el servidor seguro de GINTAL https://sec.gintal.com se ofrece un servicio de autenticación y recolección de los datos del certificado para el DNI electrónico y los certificados de la Autoridad de Certificación de la Comunidad Valenciana (ACCV).

Por su parte, la ACCV ofrece servicios de validación de los certificados incluidos en la plataforma @firma, entre ellos los propios certificados de la ACCV y el DNI electrónico, a través de http://webserv.pki.gva.es:8080/axis/services/serviciospki?wsdl

Para la validación mediante la utilización de estos dos servicios se debería configurar el módulo mediante el menú Certificate Authentication de Site configuration con los siguientes parámetros:

• Server: https://sec.gintal.com
• Script: /sms/common/auth.php
• Web Service: http://webserv.pki.gva.es:8080/axis/services/serviciospki?wsdl
• Función: getEstadoInt()
• Valor esperado: 0

Estos parámetros pueden ser modificados para utilizar otros servicios para la extracción de los datos públicos del certificado que permitiesen utilizar certificados de Prestadores de Servicios de Certificacion (PSC) distintos y otros servicios de validación.

El módulo utilizado para la creación de los formularios (documentos normalizados, normalmente solicitudes) que dan inicio a los procedimientos y servicios es el webform para drupal http://drupal.org/project/webform.

Este módulo ha sido objeto de diversas adaptaciones con una triple finalidad:

Esta adaptación permite realizar firmas sobre los formularios creados mediante webforms.

Sus funcionalidades son las siguientes:

• Al crear un nuevo formulario hay un campo de configuración (signature options) que permite elegir si el formulario creado con webforms se firmará de forma opcional u obligatoria.
• La firma se efectúa mediante el cryptoapplet desarrollado por la Universitat Jaume I http://forja.uji.es/projects/cryptoapplet.
• Se firman tanto los campos como los documentos anexos.
• Una vez firmada la solicitud se adjunta un campo en el webforms que guarda la firma en formato XML, éste XML contiene dos CMS/PKCS#7:

<data> 
  <cms_signature>
    base64 encoded pkcs#7 signature
  </cms_signature>
  <cms_timestamp>
    base64 encoded pkcs#7 timestamp
  </cms_timestamp>
</data>

El primero representa la firma, el segundo, una marca de tiempo proporcionada por una autoridad de sellado de tiempo válida.

• Al consultar los envíos (submissions) de webforms, se puede descargar el PKCS#7 para comprobar la firma.

La utilización de la firma requiere nuevamente su validación por parte de un PSC. Para ello se debe configurar la llamada que se efectúa mediante WSDL utilizando la opción correspondiente de la página de configuración del módulo en Site configuration. En el ejemplo que se describe a continuación se han utilizado los servicios de validación OCSP de la ACCV. Para ello, en WSDL se ha puesto la siguiente dirección: http://webserv.pki.gva.es:8080/axis/services/serviciospki?wsdl

La funcionalidad de firma implementa la verificación de la misma, ésta se realiza en dos pasos:

• El propio módulo verifica que la firma es correcta y que se ha realizado con el certificado asociado, existente en la estructura CMS/PKCS#7.
• El certificado se valida a través del WebService indicado en el punto anterior con la finalidad de conocer si éste ha sido revocado, todavía no es válido o ha expirado.
• Si se ha configurado una dirección URL de verificación de Sello de Tiempo, el módulo verifica que el sello de tiempo es válido y ha sido firmado por una autoridad de sellado de tiempo en la que confiamos.

Conviene tener en cuenta que la gestión de cada procedimiento se realiza mediante los tipos de contenido creados a través de CCK y mediante las funcionalidades de los módulos workflow y trigger respecto a estos tipos de contenido. Por tanto, es necesario vincular el formulario mediante el que se crean las solicitudes o documentos normalizados que iniciarán los procedimientos, y su posterior tramitación.

Las nuevas funciones que se han desarrollado a este respecto son:

• Al instalar webforms se crea un campo en la tabla webforms para albergar tipo contenido (creado con CCK) que genera cada uno de los formularios webform.
• Al instalar webforms se crea un campo en la tabla webform_submissions que guardará el nid del nodo (trámite) generado para cada envío efectuado mediante los formularios (webform submission).
• Cuando se crea un tipo de formulario (un nuevo webform) se muestra un desplegable entre los tipos de contenidos previamente creados, para poder vincular esos formularios al tipo de contenido.
• Cada vez que se efectúa un envío de un formulario se inserta un nuevo nodo del tipo que se haya configurado.
• Cada vez que se efectúa un envío se vincula con el nodo creado.

La utilización del sistema requiere la visualización por parte de los distintos usuarios (ciudadano y funcionarios) de las solicitudes o trámites disponibles y del estado de tramitación de cada uno de los procedimientos. Las comúnmente denominadas carpeta del ciudadano o carpeta del funcionario.

Para facilitar la utilización del sistema sin necesidad de tener que utilizar ningún tipo de programación por parte del administrador, y para evitar la instalación de módulos adicionales se han añadido unas funciones en el archivo webform.module que crean unos items de menú y unas funciones para visualizar su contenido al acceder a las url de los correspondientes items.

A continuación se muestra y comenta brevemente este código para facilitar su localización y personalización, o eliminación cuando se desee mostrar la información de otro modo o con un contenido distinto.

Es la entrada del registro electrónico.

Para ello, se ha introducido un código que crea un ítem del menú que permite acceder a la relación de solicitudes o trámites disponibles.

 $items['instancias'] = array(
    'title' => 'Solicitudes disponibles',
    'page callback' => 'webform_solicitudes_disponibles',
     'access callback' => 'user_access',
    'access arguments' => array('access webform results'),
   'description' => t('View all submissions of the user.'),
    'type' => MENU_CALLBACK,
  );

Mediante este código cuando se accede a la url www.site.com/instancias se ejecuta la función del page callback webform_solicitudes_disponibles que muestra las solicitudes o trámites disponibles creados mediante webform.

function webform_solicitudes_disponibles() {
 
    global $user;
$res=db_query("SELECT node.nid as nodo, node.title as titulo
FROM webform
INNER JOIN node ON node.nid = webform.nid");
 
// La cabecera de la tabla
$header = array(
  array('data' => t('Tipo de solicitud'), 'field' => 'name',  'sort' => 'asc'),
);
 
while ($result = db_fetch_array($res)) {
// El cuerpo de la tabla, las filas
$rows[]= array(l($result['titulo'], 'node/'.$result['nodo']));
} // end while
 
return theme('table', $header, $rows);
 
}

Es la carpeta del ciudadano.

Para ello se ha introducido un código que crea un ítem del menú para acceder a dicha página.

     $items['missolicitudes'] = array(
    'title' => 'Solicitudes enviadas',
    'page callback' => 'webform_solicitudes_enviadas',
    'access callback' => TRUE,
    'description' => t('View all submissions of the user.'),
    'type' => MENU_CALLBACK,
  );

Mediante este código cuando se accede a la url www.sitio.com/solicitudes se muestra una tabla con las solicitudes enviadas por el usuario mediante la llamada a la función webform_solicitudes_enviadas.

function webform_solicitudes_enviadas() {
 
    global $user;
 
$sql="SELECT node1.title as titulo, submitted, state, webform_submissions.nid as nodo, webform_submissions.sid as envio
FROM node AS node1
INNER JOIN webform_submissions ON node1.nid = webform_submissions.nid
INNER JOIN node AS node2 ON webform_submissions.node_created = node2.nid
INNER JOIN workflow_node ON webform_submissions.node_created = workflow_node.nid
INNER JOIN workflow_states ON workflow_states.sid = workflow_node.sid
WHERE webform_submissions.uid = %d";
 
// La cabecera de la tabla
$header = array(
  array('data' => t('Solicitud'), 'field' => 'titulo'),
  array('data' => t('Estado'), 'field' => 'state'),
 array('data' => t('Fecha'), 'sort' => 'desc','field' => 'submitted' ),
 
);
$res=db_query($sql.tablesort_sql($header),$user->uid);
//lo de table sort es para que se pueda ordenar la tabla
 
while ($result = db_fetch_array($res)) {
// El cuerpo de la tabla, las filas
$rows[]= array(l($result['titulo'], 'node/'.$result['nodo'].'/submission/'.$result['envio']), $result['state'], date("d.m.y",$result['submitted']));
} // end while
 
return theme('table', $header, $rows);
 
}

Es la carpeta del funcionario.

Para ello se ha introducido un código que crea un item del menú para acceder a dicha carpeta.

$items['solicitudes'] = array(
    'title' => 'Gestión de solicitudes',
    'page callback' => 'webform_solicitudes_gestiona',
    'page arguments'=> array(1),
    'access callback' => 'user_access',
    'access arguments' => array('access workflow summary views'),
    'description' => t('Admin the submisions.'),
    'type' => MENU_CALLBACK,
  );

El argumento (1) con los valores view o update permitirá mostrar todos los trámites o sólo aquellos que tengan tareas pendientes para ese funcionario.

De este modo accediendo a www.site.com/solicitudes/view se visualizan todas los trámites, con independencia de su estado.

Y accediendo a www.site.com/solicitudes/update se visualizan únicamente los trámites con tareas pendientes.

Los trámites pueden ordenarse por cada uno de los campos de la tabla.

La función que generará la página es la siguiente:

function webform_solicitudes_gestiona($acceso) {
 
    global $user;
    $sql = "SELECT node.nid AS nid, 
node.title AS node_title, 
workflow_states.state AS workflow_states_state, 
webform_submissions.sid AS sid, 
webform_submissions.nid AS nid2, 
webform_submissions.submitted AS date, 
node_type.name AS node_type
FROM node node
INNER JOIN workflow_node workflow_node ON node.nid = workflow_node.nid
INNER JOIN workflow_states workflow_states ON workflow_node.sid = workflow_states.sid
INNER JOIN webform_submissions ON webform_submissions.node_created = node.nid
INNER JOIN node_type ON node.type = node_type.type
WHERE node.type NOT
IN (
'webform', 'page', 'story'
)";
 
// La cabecera de la tabla
$header = array(
  array('data' => t('Solicitud'), 'field' => 'node_type'),
  array('data' => t('Fecha'), 'field' => 'date','sort' => 'asc'),
  array('data' => t('Estado'), 'field' => 'workflow_states_state'),
  array('data' => t('')),
  array('data' => t(''))
);
$res=db_query($sql.tablesort_sql($header));
 
while ($result = db_fetch_array($res)) {
// El cuerpo de la tabla, las filas
    $node3 = node_load($result['nid']);
    if (node_access($acceso,$node3))
        $rows[]= array(l($result['node_type'], 'node/'.$result['nid2'].'/submission/'.$result['sid']),date("d/m/y",$result['date']) ,l($result['workflow_states_state'],'node/'.$result['nid'].'/workflow/'),l('Ver','node/'.$result['nid']),l('Tramitar','node/'.$result['nid'].'/edit/'));
} // end while
 
return theme('table', $header, $rows);
 
}

Con el If controlamos que sólo se muestren los nodos a los que cada funcionario en funcion de su rol tiene permiso de acceso.

Generamos una pestaña que permite, dada la vista estándar de un envío, cambiar la solicitud generada por el envío. Se usa en casos en que un ciudadano use una instancia general, por ejemplo, para solicitar un vado.

$items['node/%webform_menu/submission/%webform_menu_submission/redirect'] = array(
    'title' => 'Cambia tipo de trámite',
    'load arguments' => array(1),
    'page callback' => 'drupal_get_form',
	'page arguments' => array('webform_reconducir_form',1, 3),
    'access callback' => 'user_access',
    'access arguments' => array('access workflow summary views'),
    'weight' => 3,
    'type' => MENU_LOCAL_TASK,
  );

Mediante un sencillo formulario se selecciona el nuevo tipo de trámite que debe permitir tramitar la solicitud.

function webform_reconducir_form($form_state,$node, $submission)
{
 
   $form['reconducir'] = array(
    '#type' => 'fieldset',
    '#title' => t('Cambiar tipo de trámite de una solicitud'),
	'#tree' => TRUE,
  );
 
  $form['reconducir']['node_type'] = array(
    '#type'  => 'select',
    '#title' => t('Seleccciona el tipo de trámite para la solicitud'),
    '#description' => t('Atención. El trámite asociado inicialmente a la solicitud será eliminado y sustituido por uno nuevo del tipo seleccionado.'),
  );
  $form['reconducir']['node_type']['#options'] = _node_type_select_load_options();
  $form['node'] = array('#type' => 'value', '#value' => $node);
  $form['submission'] = array('#type' => 'value', '#value' => $submission);
  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Aceptar'),
    '#weight' => 4
  );
 
  return $form;
}

Una vez realizado el envío, se crea un nuevo nodo del tipo seleccionado en el formulario, se enlaza con el envío, y finalmente se elimina el nodo que se había creado para gestionar la solicitud.

Se ha efectuado una instalación demostración en http://demo.gintal.com.

Se han instalado los módulos anteriormente mencionados (upload, trigger, CCK, menu per role, workflow, Certificate authentication y webform plus).

El administrador ha efectuado las siguientes tareas:

Ha creado los roles:

• urbanismo.
• actividades.
• secretario.
• registro.

Mediante el CCK se han creado cuatro tipos de contenidos:

• Solicitud general.
• Solicitud información urbanística.
• Solicitud ocupación vía pública.
• Solicitud de vado.

En estos contenidos, mediante el CCK, se han creado campos de ejemplos para cada uno de ellos. Por ejemplo, la solicitud de información urbanística tiene tres campos, Informe técnico, Aprobación y Resolución. Por otro lado, la instancia general sólo tiene un campo, Resolución, que es donde se informará al ciudadano de la resolución del expediente que haya solicitado. En cada caso se configuran los campos dependiendo de los trámites o pasos que requiera cada solicitud.

Se han concedido permisos a cada uno de los roles en relación con los procedimientos en los que intervienen.

Mediante el módulo workflow se han creado los estados posibles en relación con cada trámite (por ejemplo, en el caso de la Solicitud de información urbanística: pendiente informe técnico, pendiente firma secretario y finalizado). Tambien se han asignado permisos para la modificacion de estos estados a cada uno de los roles. Por ejemplo, el cambio de estado entre pendiente informe técnico a pendiente firma secretario lo efectúa urbanismo. Por su parte el secretario puede pasarlo a finalizado o devolverlo a pendiente informe técnico.

Mediante el módulo trigger se ha definido una acción para que pase automáticamente del estado creado (que se produce cuando se presenta la solicitud) al primer estado del workflow (en nuestro ejemplo pendiente informe técnico). De esta forma se automatiza el inicio de la tramitación de un expediente.

Mediante el módulo webforms plus se han creado los campos de cada formulario de inicio a los cuatro trámites y se ha seleccionado para cada tipo de formulario el trámite previamente creado con el CCK.

Se han creado los enlaces desde el menú a los items que muestran el Registro electrónico (http://demo.gintal.com/instancias) la carpeta del ciudadano (http://demo.gintal.com/missolicitudes) y la carpeta del funcionario (http://demo.gintal.com/solicitudes/view para todas las solicitudes recibidas y http://demo.gintal.com/solicitudes/update para las solicitudes con trámites pendientes).

Mediante el módulo menu per role se ha filtrado el menú que permite acceder a la carpeta del funcionario, para que no sea visible para los ciudadanos. Aunque fuese visible tampoco se podría visualizar el contenido dado que la función que genera el contenido de los trámites pendientes vuelve a filtrar el contenido a mostrar en función del rol.

Los usuarios ciudadanos pueden visitar http://demo.gintal.com y acceder mediante usuario/password si previamente están registrados.

También pueden acceder mediante certificado de firma electrónica incluso si previamente no están dados de alta en el sistema. En este caso, se les da de alta y se les asigna una contraseña provisional, permitiéndoles su modificación.

Una vez identificados, a través del enlace 'Registro electrónico', pueden acceder a las solicitudes disponibles y y presentar una solicitud para iniciar cada uno de los trámites. En la demo se han configurado los trámites con firma electrónica opcional con lo que se puede, bien únicamente enviar, o bien enviar y firmar.

El envío genera la creación de un expediente, que se inserta automáticamente en el flujo de trabajo que se ha definido para cada tipo de solicitud.

El expediente queda inicialmente en estado pendiente de alguna actuación por parte de los usuarios internos de la administración.

A través del enlace 'Solicitudes presentadas' el ciudadano consulta el contenido de todas las solicitudes presentadas y el estado de tramitación. El estado de tramitación incluye una vista al campo Resolución (o los campos que el administrador defina como visibles) y la tramitación completa completo con indicación de la fecha en la que cambio de un estado a otro.

Los funcionarios (usuario: urbanismo - password: urbanismo, usuario: secretario- password: secretario y usuario: registro -password: registro), cuando acceden, ven también dos enlaces denominados 'solicitudes pendientes' y 'solicitudes recibidas' que les llevan a la url que muestra la carpeta del funcionario con la relación de solicitudes.

Pinchando sobre el tipo de solicitud se visualiza la solicitud completa presentada por el ciudadano. El funcionario también dispone de una pestaña que le permite cambiar la solicitud a otro trámite. Esta opción es especialmente útil para el funcionario de registro, que puede reconducir una solicitud general hacia uno de los trámites definidos, por ejemplo, para cuando se solicitude un vado , que tiene un procedimiento definido y, por error, se utilice la solicitud general.

• Las solicitudes pendientes son aquellas que se encuentran en un estado que requiere la tramitación por parte de un funcionario de ese rol.
• Las solicitudes recibidas son aquellas que afectan a un rol en particular, aunque un funcionario del rol ya haya realizado el trámite oportuno, siempre podrá consultar el estado actual del trámite.

En el caso de una solicitud de información urbanística el funcionario de urbanismo puede ver los expedientes que están pendientes de su actuación. En este punto puede editar el expediente, pudiendo editar uno de sus campos, creado para que emita su informe técnico. Puede adjuntar también los documentos que estime.

Una vez finalizada su actuación, puede pasar el expediente al siguiente estado del expediente, pendiente de firma del secretario.

El secretario también puede consultar todos los expedientes para los cuales se ha configurado que tiene permisos. Además podrá consultar un listado de expedientes que se encuentran pendientes de su actuación (tareas pendientes). El secretario puede editar también ciertos campos del expediente (los que se definan) y consultar los otros, además de adjuntar los archivos que desee.

Finalmente el secretario puede decidir entre pasar el expediente a estado finalizado, o devolverlo al estado pendiente de informe técnico, por si hubiese alguna deficiencia. En cualquier cambio de estado se permite a los usuarios realizar algún comentario para que el siguiente en tratar el expediente lo lea. Los campos de comentario no son visibles por el ciudadano.

El hecho de elegir como base del proyecto un CMS tan potente como DRUPAL permite extender las funcionalidades de la plataforma de una forma sencilla y con un bajo coste. Entre las funcionalidades más comunes de la administración electrónica que podrían añadirse a esta plataforma se encuentran las siguientes:

• Configuración de alertas, vía correo electrónico o SMS, tanto a los funcionarios avisando de las tareas pendientes como a los ciudadanos informando del cambio de estado de sus trámites.
• Extensión de la carpeta ciudadana: Creación de módulos adaptados a las aplicaciones ya instaladas en cada Administración que permitan mostrar al usuario, además de sus expedientes, sus datos del Padrón, unidades fiscales, recibos, y en general toda la información almacenadas en las diversas bases de datos de la entidad, siempre que su proveedor de la aplicación le permita efectuar consultas en esas bases de datos.
• Extensión de la carpeta del funcionario: Creación de módulos adaptados a las aplicaciones ya instaladas en cada Administración que permitan mostrar al funcionario sus datos personales como Nómina y Control horario, así como la creación de trámites internos como solicitudes de permisos, material, puestos de trabajo, etc. siempre que su proveedor de la aplicación le permita efectuar consultas en esas bases de datos.
• Creación de la página web de la entidad, aprovechando las funcionalidades propias de DRUPAL.
• Generación de un objeto electrónico con información del conjunto de documentos de un expediente para su archivo.

El proyecto ha sido desarrollado por:

• GINTAL (Grupo de Investigación sobre Nuevas Tecnologías y Administración Local), integrado por José Luis Blasco Díaz, Modesto Fabra Valls y Manuel Mollar Villanueva.
• Paúl Santapau Nebot, técnico del Gabinete de Planificación y Prospectiva Tecnológica.
• Santiago Manzano Romero, técnico del Departamento de Informática del Ayuntamiento de Vila-real.

Contacto: gintal(aquí va la arroba)gintal.com

La presente aplicación se ha realizado en el marco del proyecto financiado por el programa propio de investigación de la Universitat Jaume I-Fundación Caixa Castelló-Bancaixa “ADMINISTRACION ELECTRONICA Y ENTIDADES LOCALES: ANALISIS DE LOS CONDICIONANTES NORMATIVOS Y DE SU APLICACION SOBRE LOS PRINCIPALES PROCEDIMIENTOS MUNICIPALES”.

* ODT:

• Versión 24/03/2009
• Versión 03/02/2009

* PDF:

• Versión 24/03/2009
• Versión 03/02/2009