sur la 4.0 ce ne sera pas possible de relancer une autre installation comme ça.

L'install pourra être relancé, mais bloquera à l'étape de la DB, pour pouvoir continuer l'installation, il faudra avoir passé l'étape de la DB (et donc connaître le mot de passe de connexion à mysql).

Sans ça, rien ne sera fait.

Après, rien n'empêche dans le changeday de lever une alerte si le dossier existe toujours, mais pas de page bloquante, c'est trop chiant pour nous en DEV.

Shadow:

En fait si, c'est possible si j'ai bien compris.

Lors de l'édition d'un menu de lien, en cliquant sur le l'icône + à droite du lien, on affiche des détails supplémentaires sur les autorisations du lien en question. Il est donc possible d'avoir un menu avec plusieurs liens à l'intérieur avec des autorisations différentes pour chaque lien.

Par contre, ce qui n'est pas possible, c'est d'avoir la configuration des autorisations d'un lien pointant vers un module automatiquement reliée aux autorisations du module en question.

Mais comme l'a dit Ben.popeye plus haut, il suffit de configurer les autorisations du lien en accord avec celle du module.

Voilà, j'espère que j'ai pu aidé.

Bonjour,

Ce n'est pas du tout comme ça qu'il faut faire, il y a beaucoup plus simple

Il faut d'abord repérer l'id du menu que tu veux. Ensuite, il te suffit de faire un Code PHP :

Tu obtiendras alors un objet de type LinksMenu qui contient soit des sous menu (LinksMenu), soit des liens (LinksMenuLink)

Tu peux alors parcourir les liens, images et texte associés. Tu peux aussi choisir de simplement redéfinir un template en faisant comme ça : Code PHP : $le_template_en_question étant un objet Template.
Par exemple : Code PHP : Le fichier tpl associé sera alors à mettre dans /templates/TON_THEME/framework/menus/links/le_template_en_question.tpl ou dans /templates/default/framework/menus/links/le_template_en_question.tpl si il n'est pas trouvé dans précédemment.

Voilà, j'espère que c'est plus clair comme ça

Bonjour,

Concernant ton problème, je n'ai pas bien saisi si c'est la version fournie avec PHPBoost de Feed.class.php que tu as.

Si oui, alors le mieux serait d'effacer tous les fichiers du répertoire /cache/syndication qui contiennent le mot forum dans leur nom.

Bonne journée.

Bonjour,

Je tiens à préciser les propos de ReidLos,

La 3.1 contiendra effectivement un FormBuilder permettant de créer des formulaires facilement, mais en PHP.

Un générateur de formulaire tel que tu l'entends n'est actuellement pas possible.

Il est cependant possible de faire des sondages dans le forum avec des radio

Bonne journée

Salut,

Ce n'est pas le cas, il ne "s'incruste" pas dans une balise body.

La balise body que tu vois est celle de la page. Comme ta publicité est le premier élément de ta page, elle est placée juste après le body, c'est tout.

Donc tout est normal

Je suis totalement d'accord avec CrowkaiT, mais j'ai peut-être une solution qui pourrait palier à ceci :
CrowkaiT:

En fait, ce qui nous paraît tordu est le fait qu'on fonctionne uniquement par autorisation et que ça parait débile (même si le besoin se comprend) d'interdire quelqu'un qu'on a autorisé.

La solution, serait de donner des autorisation spécifiques autres que membres pour ces modules mais ce qui pose problème actuellement, c'est le fait de devoir ajouter tous les membres manuellement à un groupe.

Du coup, j'ai pensé à qu'il serait bien de pouvoir définir la liste des groupes dans lesquels mettre un membre à sa création.
Il suffirait ensuite de le retirer du/des groupe/s en question/s

Je sais que ce que je dis, c'est un peu prendre le problème à l'envers, mais c'est surtout aller dans le même sens que le système d'autorisation actuel.

Qu'en pensez vous?

Pas de soucis swan, je voulais juste être clair dans mon point de vue

Alain, Je suis désolé, mais je n'ai rien compris à ce que tu proposes, tu peux me faire un dessin stp.

Non, ce que je dit, c'est que le système d'authorisation de PHPBoost ne fonctionne que par authorisation, pas par interdiction.

Du coup, il convient de penser les autorisations d'accès dans le sens, j'autorise telle ressource à tel groupe et tous ceux qui n'y sont pas dedans n'y ont pas accès.

Du coup, dans ce que j'ai dit précédemment, l'idée, c'est créer un groupe dans lequel tous les membres sont par défaut, et supprimer le membre du groupe qui ne doit pas avoir l'accès.

Cela peut paraître compliqué de prime abord, mais si on commence à avoir un système :
- on interdit tout le monde
- on n'autorise que ceux qui sont défini pour le allow (groupe / utilisateur)
- on interdit tous ceux qui sont défini pour le deny (groupe / utilisateur) avec cette règle prioritaire sur la précédente

ça risque de devenir un cauchemar à gérer pour vos sites. C'est sûr que dans ce cas, c'est plus simple, mais je pense personnellement que ça deviendra vite incompréhensible à l'utilisation.

Ceci, sans parler des problèmes d'implémentation venant du fait que la structure de données actuelle n'est pas faîte pour stocker ce genre d'information => pb de migration avec l'ancienne structure), mais à la limite, ça c'est un détail.

A voir ce qu'en pense les autres.

le cas d'utilisation que tu décris indique que ton contenu est restreint et que par conséquent seul un groupe de personne peut y avoir accès

=> group

non?