Recherche avancée

Sur d’autres sites (6989)

• Revision 65f13afd7d : Fix building for arm with Visual Studio 2013 The microsoft build tools explicit

  4 mai 2014, par Martin Storsjo

  Changed Paths :
   Modify /build/make/configure.sh

  
   Modify /build/make/gen_msvs_vcxproj.sh

  
  
  Fix building for arm with Visual Studio 2013

  The microsoft build tools explicitly disallow building for arm in
  the "desktop" target configuration ; one has to target "Windows
  Store" apps (aka WinRT/Metro) or Windows Phone. In Visual Studio
  2012, one could just pick the v110_wp80 toolset which made the
  vcxproj files buildable. In Visual Studio 2013, picking the v120_wp81
  toolset isn’t enough - one has to configure the vcxproj files
  as an "AppContainerApplication". This has the implication that
  you can’t just build a plain .exe (such as the examples) - an .exe
  project would need to have an AppxManifest file. Therefore we can
  only build the library itself.

  If loaded into Visual Studio for Windows (the Windows Store/Phone
  version of Visual Studio, not the Desktop one), the obj_int_extract
  project is omitted since it’s treated as incompatible. Building
  from the command line with msbuild works fine though.

  The armv7-win32-vs12 target was added as part of a638bdf4 even
  though actual use of it hadn’t been tested.

  Change-Id : Iee8088252cf790317aeb6b417d29058225f1f629

• Evolution #2608 (Fermé) : visiteurs

  22 mars 2012, par cedric -

  faut relire le thread de 6 mois sur le bandeau... les visiteurs concernent l’activité publique du site et sont donc rangés dans le menu Activité

• Anomalie #3055 (En cours) : Autorisation sur les listes d’objets

  5 mai 2015, par Eric Lupinacci

  En fait, c’est à mon avis un problème plus général, de rigueur dans l’appel des autorisations en entrée des pages mais aussi de stratégie de définition des autorisations qui sont malheureusement assez rarement arborescentes.

  Si on prend les pages objet comme article, rubrique et auteur par exemple, elle commencent toutes par une autorisation :
  

  (#AUTORISERvoir,article,#ID_ARTICLE ou
  (#AUTORISERvoir,rubrique,#ID_RUBRIQUE ou
  (#AUTORISERvoir,auteur,#ID_AUTEUR
  

  
  Cependant d’ailleurs seul l’autorisation article_voir est définie, les autres renvoyant sur l’autorisation par défaut. Mais au moins une autorisation est appelée systématiquement quelque soit le moyen avec lequel on arrive sur cette page.
  A partir de là si il existe un bouton qui envoie sur cette page il faut le conditionner par cette autorisation (code HTML) et si c’est un menu créé automatiquement alors là il faut créer une autorisation de menu qui appelle l’autorisation de voir et pas le contraire à mon avis.

  Donc si on étend ça aux pages articles, auteurs et rubriques je suis d’accord qu’il faudrait une autorisation voir_xxxx (ce qui n’est pas le cas actuellement) qui serait appelée en entrée de la page comme l’exemple ci-dessous pour la page articles :
  

  (#AUTORISERvoir,_articles
  

  
  et il faudrait alors coder l’autorisation du menu Articles de cette façon :
  

  function autoriser_articles_menu_dist($faire, $type, $id, $qui, $opt) 
      return autoriser(’voir’, ’_articles’) ;
  
  

  
  En effet, la décision d’afficher ou pas le menu est indépendante du fait de voir ou pas la page articles mais doit s’appuyer dessus si on décide de ne pas présenter un lien qui mène vers une page interdite.
  Et il faudrait systématiser cela pour tous les plugins objet du core à mon avis.

  En second lieu il faudrait faire une passe sur le code des autorisations actuelles pour imbriquer un peu plus les autorisations de façon arborescente ce qui leur donnerait plus de lisibilité car parfois elles sont identiques sans qu’on s’en rende compte car le code est dupliqué.