You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
abonnements/abonnements_pipelines.php

350 lines
11 KiB
PHTML

<?php
/**
* Plugin Abonnements
* (c) 2012 Les Développements Durables
* Licence GNU/GPL v3
*/
if (!defined('_ECRIRE_INC_VERSION'))
return;
/**
* Optimiser la base de donnees des abonnements
*
* @param int $n
* @return int
*/
function abonnements_optimiser_base_disparus($flux) {
//Offres d'abonnement à la poubelle
3 years ago
$mydate = sql_quote(trim($flux['args']['date'], "'"));
sql_delete("spip_abonnements_offres", "statut='poubelle' AND maj < $mydate");
//Supprimer les abonnements lies à une offre d'abonnement inexistante
$res = sql_select("DISTINCT abonnements.id_abonnements_offre", "spip_abonnements AS abonnements
LEFT JOIN spip_abonnements_offres AS offres
ON abonnements.id_abonnements_offre=offres.id_abonnements_offre", "offres.id_abonnements_offre IS NULL");
while ($row = sql_fetch($res))
sql_delete("spip_abonnements", "id_abonnements_offre=" . $row['id_abonnements_offre']);
//Abonnements à la poubelle
sql_delete("spip_abonnements", "statut='poubelle' AND maj < $mydate");
include_spip('action/editer_liens');
$flux['data'] += objet_optimiser_liens(array('abonnement' => '*'), '*');
return $flux;
}
/*
* Des modifs supplémentaires après édition
*/
function abonnements_post_edition($flux) {
if (empty($flux['args']['table'])) {
return $flux;
}
// Si on modifie un abonnement
if ($flux['args']['table'] == 'spip_abonnements') {
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
include_spip('inc/abonnements');
$id_abonnement = intval($flux['args']['id_objet']);
$abonnement = sql_fetsel('*', 'spip_abonnements', 'id_abonnement = ' . $id_abonnement);
$offre = sql_fetsel('*', 'spip_abonnements_offres', 'id_abonnements_offre = ' . intval($abonnement['id_abonnements_offre']));
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
$jourdhui = date('Y-m-d H:i:s');
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si la date de fin a été modifiée et qu'elle est dans le future
// on reprogramme la désactivation
if (isset($flux['data']['date_fin']) and $flux['data']['date_fin'] > $jourdhui) {
abonnements_programmer_desactivation($flux['args']['id_objet'], $flux['data']['date_fin']);
}
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si on a mis l'abonnement inactif ou à la poubelle, on doit enlever les tâches liées
if (
isset($flux['data']['statut'])
and in_array($flux['data']['statut'], array('inactif', 'poubelle'))
) {
include_spip('action/editer_liens');
$liens = objet_trouver_liens(array('job' => '*'), array('abonnement' => $abonnement['id_abonnement']));
if ($liens and is_array($liens)) {
// Et on les supprime toutes !
foreach ($liens as $lien) {
job_queue_remove($lien['id_job']);
}
}
}
// Si on a un id_commande dans l'environnement, on lie la commande à l'abonnement
if (
$id_commande = intval(_request('id_commande'))
and defined('_DIR_PLUGIN_COMMANDES')
) {
// On lie cet abonnement avec la commande qui l'a généré
include_spip('action/editer_liens');
objet_associer(
array('commande' => $id_commande), array('abonnement' => $id_abonnement)
);
}
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
$modifs = array();
$modifs_instituer = array();
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si l'échéance est VIDE, et que pourtant l'offre parente A BIEN une durée
// alors c'est qu'il faut initialiser les dates !
if ($abonnement['date_echeance'] == '0000-00-00 00:00:00' and ( $duree = $offre['duree']) > 0) {
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
$modifs = abonnements_initialisation_dates($abonnement, $offre);
}
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si les dates doivent être changées, on change le tableau de l'abonnement pour le test de statut qui suivra
if (isset($modifs['date_debut'])) {
$abonnement['date_debut'] = $modifs['date_debut'];
}
if (isset($modifs['date_fin'])) {
$abonnement['date_fin'] = $modifs['date_fin'];
}
// Seulement si personne n'a modifié le statut manuellement, alors on check les dates pour statufier
if (!$flux['data']['statut']) {
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si aujourd'hui est entre date_debut et date_echeance, on active
if (
$abonnement['statut'] == 'inactif'
and $jourdhui >= $abonnement['date_debut']
and $jourdhui <= $abonnement['date_echeance']
) {
$modifs_instituer['statut'] = 'actif';
spip_log("Post-édition : passage de labonnement $id_abonnement en actif", 'abonnements.'._LOG_INFO);
spip_log($abonnement, 'abonnements.'._LOG_INFO);
}
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
// Si aujourd'hui est en dehors des dates début et FIN, on désactive
// on ne teste pas date_echeance car ce sera à un génie de désactiver si trop dépassée
elseif (
$abonnement['statut'] == 'actif'
and (
// Avant la date de début
$jourdhui < $abonnement['date_debut']
// Ou après la date de fin MAIS seulement si elle existe !
or (
$abonnement['date_fin'] != '0000-00-00 00:00:00'
and $jourdhui >= $abonnement['date_fin']
)
)
) {
$modifs_instituer['statut'] = 'inactif';
spip_log("Post-édition : passage de labonnement $id_abonnement en inactif", 'abonnements.'._LOG_INFO);
spip_log($abonnement, 'abonnements.'._LOG_INFO);
}
}
// S'il y a des modifs à faire on appelle l'API de modif
if (!empty($modifs)) {
include_spip('action/editer_objet');
objet_modifier('abonnement', $flux['args']['id_objet'], $modifs);
}
// Pour le statut on fait à part (pb de double entrée avec Champs Extras)
if (!empty($modifs_instituer)) {
include_spip('action/editer_objet');
objet_instituer('abonnement', $flux['args']['id_objet'], $modifs_instituer);
}
}
// Détection magique du plugin Commandes et d'une commande d'offre d'abonnement
elseif (
// Si on institue une commande
$flux['args']['table'] == 'spip_commandes'
and $id_commande = intval($flux['args']['id_objet'])
and $flux['args']['action'] == 'instituer'
// Et qu'on passe en statut "paye" depuis autre chose
and $flux['data']['statut'] == 'paye'
and $flux['args']['statut_ancien'] != 'paye'
// Et que la commande existe bien
and $commande = sql_fetsel('*', 'spip_commandes', 'id_commande = ' . $id_commande)
// Et que cette commande a un utilisateur correct
and ( $id_auteur = $commande['id_auteur']) > 0
// Et qu'on a des détails dans cette commande
and $details = sql_allfetsel('*', 'spip_commandes_details', 'id_commande = ' . $id_commande)
and is_array($details)
) {
// On cherche si on a des offres d'abonnements dans les détails de la commande
foreach ($details as $detail) {
// Si on trouve une offre d'abonnement
if ($detail['objet'] == 'abonnements_offre' and ( $id_abonnements_offre = $detail['id_objet']) > 0) {
// Si la commande est renouvelable et que c'est le PREMIER paiement (activation)
// on force toujours la création d'un nouvel abonnement
$forcer_creation = false;
if (
in_array($commande['echeances_type'], array('mois', 'annee'))
and include_spip('inc/commandes_echeances')
and commandes_nb_echeances_payees($id_commande) <= 1
) {
$forcer_creation = true;
}
// On crée ou renouvelle
include_spip('inc/abonnements');
set_request('id_commande', $id_commande); // on garde l'id_commande dans l'environnement
$retour = abonnements_creer_ou_renouveler($id_auteur, $id_abonnements_offre, $forcer_creation);
}
}
}
return $flux;
}
/*
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
* Ajout de tâches nécessaires aux abonnements
*
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
* - Une tâche pour vérifier toutes les heures si on a pas trop dépassé des échéances
* - Une tâche pour vérifier toutes les heures si les abonnements actifs ont une tâche de désactivation
* - Une tâche pour programmer les emails de notification à envoyer
*
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
* @pipeline taches_generales_cron
* @param array $taches Liste des génies et leur périodicité
* @return array Liste des tâches possiblement modifiées
*/
function abonnements_taches_generales_cron($taches) {
On utilise la nouvelle date d'échéance. 1) Lorsqu'on initialise les dates, c'est ça qu'on teste. Par défaut la date de fin est la date d'échéance. Mais s'il y a Commandes et Bank, on regarde si l'abonnement a été activé par une transaction : - si c'est SEPA, on annule la date de fin, par défaut ça sera infini - si c'est carte bleue, on met comme date de fin celle de la carte bleue puisqu'on l'a 1bis) Au passage on déplace les tâches d'initialisation dans une fonction à part pour y voir plus clair. 2) Quand un abonnement est modifié et qu'on check les dates, on active entre date_debut et date_echeance maintenant. 3) Mais on désactive toujours seulement après date_fin, pas date_echeance. Ce qui permet de laisser une marge si jamais l'échéance est passée mais sans désactiver. Car ça se trouve c'est justement un paiement un peu en retard. 4) Quand on renouvelle un abonnement, on renouvelle à partir de la date d'échéance, et non plus de la date de fin. Et on repousse la date de fin si elle se retrouve avant la nouvelle échéance décalée. 5) Une nouvelle tâche génie est programmée toutes les heures pour vérifier les échéances. Si on a trop dépassé (48h par défaut qui sera configurable) alors on change la date de fin pour maintenant, ce qui va désactiver l'abonnement. Ce n'est PAS FINI. Il manque : - rendre configurable les deux délais qui sont en lire_config() - afficher la nouvelle date d'échéance dans l'admin et la rendre éditable dans le form d'édition d'un abonnement - possiblement changer la désactivation par Jobs en utilisant un génie (perf issue d'après cerdic) - sûrement plein de bugs à corriger, j'espère pas trop…
8 years ago
$taches['abonnements_verifier_echeances'] = 60 * 60; // toutes les heures
$taches['abonnements_verifier_desactivation'] = 60 * 60; // toutes les heures
$taches['abonnements_verifier_notifications'] = 24 * 3600; // une fois par jour
return $taches;
}
/**
* Ajouter des choses dans la colonne de gauche
3 years ago
*
* Offres d'abonnements : config des notifications + notifications ponctuelles
*
* @param array $flux
* @return array
*/
function abonnements_affiche_gauche($flux) {
if (isset($flux['args']['exec'])
and $flux['args']['exec'] == 'abonnements_offre'
and isset($flux['args']['id_abonnements_offre'])
) {
$flux['data'] .= recuperer_fond(
'prive/squelettes/navigation/inc-abonnements_notifications', array(
'id_abonnements_offre' => $flux['args']['id_abonnements_offre']
)
);
}
return $flux;
}
/*
* Ajouter la boite des abonnements sur la fiche auteur
*/
function abonnements_affiche_milieu($flux) {
$e = trouver_objet_exec($flux['args']['exec']);
// Sur la page des auteurs
if (
is_array($e)
and $e['type'] == 'auteur'
and $e['edition'] == false
) {
$id_auteur = $flux['args']['id_auteur'];
$ins = recuperer_fond('prive/squelettes/inclure/abonnements_auteur', array('id_auteur' => $id_auteur));
if (($p = strpos($flux['data'], "<!--affiche_milieu-->")) !== false)
$flux['data'] = substr_replace($flux['data'], $ins, $p, 0);
else
$flux['data'] .= $ins;
}
return $flux;
}
/*
* Ajouter les offres sur les objets configurés
*/
function abonnements_affiche_enfants($flux) {
$e = trouver_objet_exec($flux['args']['exec']);
// Sur la page d'un objet s'il fait partie de la config
if (
is_array($e)
and !$e['edition']
and in_array($e['table_objet_sql'], lire_config('abonnements/objets', array()))
and $texte = recuperer_fond(
'prive/objets/editer/liens',
array(
'table_source' => 'abonnements_offres',
'objet' => $e['type'],
'id_objet' => $flux['args']['id_objet']
)
)
) {
if ($p=strpos($flux['data'], '<!--affiche_milieu-->')) {
$flux['data'] = substr_replace($flux['data'], $texte, $p, 0);
} else {
$flux['data'] .= $texte;
}
}
return $flux;
}
/**
* Afficher les contenus dans lesquels sont rangés les offres
*
* @param array $flux
* @return array
*/
function abonnements_affiche_hierarchie($flux) {
include_spip('inc/config');
// Sur la page d'une offre
if (
$flux['args']['objet'] == 'abonnements_offre'
and $objets = lire_config('abonnements/objets')
) {
include_spip('action/editer_liens');
$objets = array_map('objet_type', $objets);
// On cherche si cette offre à des liens
if ($liens = objet_trouver_liens(
array('abonnements_offre' => $flux['args']['id_objet']),
array('*' => '*')
)) {
$liens_parents = array();
$liens_offres = array();
foreach ($liens as $lien) {
// Seulement si ce lien est actuellement prévu dans la config
if (in_array($lien['objet'], $objets)) {
// Si c'est une liaison entre deux offres
if ($lien['objet'] == 'abonnements_offre') {
$liens_offres[] = "[->{$lien['objet']}{$lien['id_objet']}]";
}
else {
$liens_parents[] = "[->{$lien['objet']}{$lien['id_objet']}]";
}
}
}
if ($liens_parents) {
$liens_parents = PtoBR(propre(_T('abonnementsoffre:liens_parents_label') . join(', ', $liens_parents)));
$flux['data'] .= '<div class="parents_offres">'.$liens_parents.'</div>';
}
if ($liens_offres) {
$liens_offres = PtoBR(propre(_T('abonnementsoffre:liens_offres_label') . join(', ', $liens_offres)));
$flux['data'] .= '<div class="liens_offres">'.$liens_offres.'</div>';
}
}
}
return $flux;
}
/*
* Ajouter une feuille de style privée
*/
function abonnements_header_prive($flux) {
$flux = abonnements_insert_head($flux);
return $flux;
}
function abonnements_insert_head($flux) {
$flux .= '<link rel="stylesheet" href="' . _DIR_PLUGIN_ABONNEMENTS . 'css/abonnements_prive.css" type="text/css" />';
return $flux;
}