From 3a746d010a883837beb1eee732546cbcb09df1f4 Mon Sep 17 00:00:00 2001 From: Skia Date: Tue, 21 Jun 2016 00:47:02 +0200 Subject: [PATCH] Finish the report --- Doxyfile | 127 ++++++++++----------- doc/TW_Skia/Rapport.tex | 237 ++++++++++++++++++++++++++++++---------- 2 files changed, 246 insertions(+), 118 deletions(-) diff --git a/Doxyfile b/Doxyfile index 5f20f60a..f2f479c2 100644 --- a/Doxyfile +++ b/Doxyfile @@ -38,20 +38,20 @@ PROJECT_NAME = Sith # could be handy for archiving the generated documentation or if some version # control system is used. -PROJECT_NUMBER = +PROJECT_NUMBER = # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. -PROJECT_BRIEF = +PROJECT_BRIEF = # With the PROJECT_LOGO tag one can specify an logo or icon that is included in # the documentation. The maximum height of the logo should not exceed 55 pixels # and the maximum width should not exceed 200 pixels. Doxygen will copy the logo # to the output directory. -PROJECT_LOGO = +PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is @@ -154,7 +154,7 @@ FULL_PATH_NAMES = YES # will be relative from the directory where doxygen is started. # This tag requires that the tag FULL_PATH_NAMES is set to YES. -STRIP_FROM_PATH = +STRIP_FROM_PATH = # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the # path mentioned in the documentation of a class, which tells the reader which @@ -163,7 +163,7 @@ STRIP_FROM_PATH = # specify the list of include paths that are normally passed to the compiler # using the -I flag. -STRIP_FROM_INC_PATH = +STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but # less readable) file names. This can be useful is your file systems doesn't @@ -230,13 +230,13 @@ TAB_SIZE = 4 # "Side Effects:". You can put \n's in the value part of an alias to insert # newlines. -ALIASES = +ALIASES = # This tag can be used to specify a number of word-keyword mappings (TCL only). # A mapping has the form "name=value". For example adding "class=itcl::class" # will allow you to use the command class in the itcl::class meaning. -TCL_SUBST = +TCL_SUBST = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. For @@ -280,7 +280,7 @@ OPTIMIZE_OUTPUT_VHDL = NO # Note that for custom extensions you also need to set FILE_PATTERNS otherwise # the files are not read by doxygen. -EXTENSION_MAPPING = +EXTENSION_MAPPING = # If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments # according to the Markdown format, which allows for more readable @@ -616,7 +616,7 @@ GENERATE_DEPRECATEDLIST= YES # sections, marked by \if ... \endif and \cond # ... \endcond blocks. -ENABLED_SECTIONS = +ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the # initial value of a variable or macro / define can have for it to appear in the @@ -658,7 +658,7 @@ SHOW_NAMESPACES = YES # by doxygen. Whatever the program writes to standard output is used as the file # version. For an example see the documentation. -FILE_VERSION_FILTER = +FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated @@ -671,7 +671,7 @@ FILE_VERSION_FILTER = # DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE # tag is left empty. -LAYOUT_FILE = +LAYOUT_FILE = # The CITE_BIB_FILES tag can be used to specify one or more bib files containing # the reference definitions. This must be a list of .bib files. The .bib @@ -682,7 +682,7 @@ LAYOUT_FILE = # search path. Do not use file names with spaces, bibtex cannot handle them. See # also \cite for info how to create references. -CITE_BIB_FILES = +CITE_BIB_FILES = #--------------------------------------------------------------------------- # Configuration options related to warning and progress messages @@ -741,7 +741,7 @@ WARN_FORMAT = "$file:$line: $text" # messages should be written. If left blank the output is written to standard # error (stderr). -WARN_LOGFILE = +WARN_LOGFILE = #--------------------------------------------------------------------------- # Configuration options related to the input files @@ -792,7 +792,7 @@ RECURSIVE = YES # Note that relative paths are relative to the directory from which doxygen is # run. -EXCLUDE = +EXCLUDE = # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded @@ -809,7 +809,8 @@ EXCLUDE_SYMLINKS = NO # exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = */migrations/* \ - */admin.py + */admin.py \ + *env_sith/* # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the @@ -820,13 +821,13 @@ EXCLUDE_PATTERNS = */migrations/* \ # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories use the pattern */test/* -EXCLUDE_SYMBOLS = +EXCLUDE_SYMBOLS = # The EXAMPLE_PATH tag can be used to specify one or more files or directories # that contain example code fragments that are included (see the \include # command). -EXAMPLE_PATH = +EXAMPLE_PATH = # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and @@ -846,7 +847,7 @@ EXAMPLE_RECURSIVE = NO # that contain images that are to be included in the documentation (see the # \image command). -IMAGE_PATH = +IMAGE_PATH = # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program @@ -863,7 +864,7 @@ IMAGE_PATH = # code is scanned, but not when the output code is generated. If lines are added # or removed, the anchors will not be placed correctly. -INPUT_FILTER = +INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the @@ -872,7 +873,7 @@ INPUT_FILTER = # filters are used. If the FILTER_PATTERNS tag is empty or if none of the # patterns match the file name, INPUT_FILTER is applied. -FILTER_PATTERNS = +FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER ) will also be used to filter the input files that are used for @@ -887,14 +888,14 @@ FILTER_SOURCE_FILES = NO # *.ext= (so without naming a filter). # This tag requires that the tag FILTER_SOURCE_FILES is set to YES. -FILTER_SOURCE_PATTERNS = +FILTER_SOURCE_PATTERNS = # If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that # is part of the input, its contents will be placed on the main page # (index.html). This can be useful if you have a project on for instance GitHub # and want to reuse the introduction page also for the doxygen output. -USE_MDFILE_AS_MAINPAGE = +USE_MDFILE_AS_MAINPAGE = #--------------------------------------------------------------------------- # Configuration options related to source browsing @@ -1006,7 +1007,7 @@ COLS_IN_ALPHA_INDEX = 5 # while generating the index headers. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. -IGNORE_PREFIX = +IGNORE_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the HTML output @@ -1050,7 +1051,7 @@ HTML_FILE_EXTENSION = .html # of the possible markers and block names see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_HEADER = +HTML_HEADER = # The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each # generated HTML page. If the tag is left blank doxygen will generate a standard @@ -1060,7 +1061,7 @@ HTML_HEADER = # that doxygen normally uses. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_FOOTER = +HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading style # sheet that is used by each HTML page. It can be used to fine-tune the look of @@ -1072,7 +1073,7 @@ HTML_FOOTER = # obsolete. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_STYLESHEET = +HTML_STYLESHEET = # The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user- # defined cascading style sheet that is included after the standard style sheets @@ -1083,7 +1084,7 @@ HTML_STYLESHEET = # see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_EXTRA_STYLESHEET = +HTML_EXTRA_STYLESHEET = # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note @@ -1093,7 +1094,7 @@ HTML_EXTRA_STYLESHEET = # files will be copied as-is; there are no commands or markers available. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_EXTRA_FILES = +HTML_EXTRA_FILES = # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen # will adjust the colors in the stylesheet and background images according to @@ -1221,7 +1222,7 @@ GENERATE_HTMLHELP = NO # written to the html output directory. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. -CHM_FILE = +CHM_FILE = # The HHC_LOCATION tag can be used to specify the location (absolute path # including file name) of the HTML help compiler ( hhc.exe). If non-empty @@ -1229,7 +1230,7 @@ CHM_FILE = # The file has to be specified with full path. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. -HHC_LOCATION = +HHC_LOCATION = # The GENERATE_CHI flag controls if a separate .chi index file is generated ( # YES) or that it should be included in the master .chm file ( NO). @@ -1242,7 +1243,7 @@ GENERATE_CHI = NO # and project file content. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. -CHM_INDEX_ENCODING = +CHM_INDEX_ENCODING = # The BINARY_TOC flag controls whether a binary table of contents is generated ( # YES) or a normal table of contents ( NO) in the .chm file. @@ -1272,7 +1273,7 @@ GENERATE_QHP = NO # the HTML output folder. # This tag requires that the tag GENERATE_QHP is set to YES. -QCH_FILE = +QCH_FILE = # The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help # Project output. For more information please see Qt Help Project / Namespace @@ -1297,7 +1298,7 @@ QHP_VIRTUAL_FOLDER = doc # filters). # This tag requires that the tag GENERATE_QHP is set to YES. -QHP_CUST_FILTER_NAME = +QHP_CUST_FILTER_NAME = # The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the # custom filter to add. For more information please see Qt Help Project / Custom @@ -1305,21 +1306,21 @@ QHP_CUST_FILTER_NAME = # filters). # This tag requires that the tag GENERATE_QHP is set to YES. -QHP_CUST_FILTER_ATTRS = +QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this # project's filter section matches. Qt Help Project / Filter Attributes (see: # http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes). # This tag requires that the tag GENERATE_QHP is set to YES. -QHP_SECT_FILTER_ATTRS = +QHP_SECT_FILTER_ATTRS = # The QHG_LOCATION tag can be used to specify the location of Qt's # qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the # generated .qhp file. # This tag requires that the tag GENERATE_QHP is set to YES. -QHG_LOCATION = +QHG_LOCATION = # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be # generated, together with the HTML files, they form an Eclipse help plugin. To @@ -1452,7 +1453,7 @@ MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest # MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols # This tag requires that the tag USE_MATHJAX is set to YES. -MATHJAX_EXTENSIONS = +MATHJAX_EXTENSIONS = # The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces # of code that will be used on startup of the MathJax code. See the MathJax site @@ -1460,7 +1461,7 @@ MATHJAX_EXTENSIONS = # example see the documentation. # This tag requires that the tag USE_MATHJAX is set to YES. -MATHJAX_CODEFILE = +MATHJAX_CODEFILE = # When the SEARCHENGINE tag is enabled doxygen will generate a search box for # the HTML output. The underlying search engine uses javascript and DHTML and @@ -1520,7 +1521,7 @@ EXTERNAL_SEARCH = NO # Searching" for details. # This tag requires that the tag SEARCHENGINE is set to YES. -SEARCHENGINE_URL = +SEARCHENGINE_URL = # When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed # search data is written to a file for indexing by an external tool. With the @@ -1536,7 +1537,7 @@ SEARCHDATA_FILE = searchdata.xml # projects and redirect the results back to the right project. # This tag requires that the tag SEARCHENGINE is set to YES. -EXTERNAL_SEARCH_ID = +EXTERNAL_SEARCH_ID = # The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen # projects other than the one defined by this configuration file, but that are @@ -1546,7 +1547,7 @@ EXTERNAL_SEARCH_ID = # EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ... # This tag requires that the tag SEARCHENGINE is set to YES. -EXTRA_SEARCH_MAPPINGS = +EXTRA_SEARCH_MAPPINGS = #--------------------------------------------------------------------------- # Configuration options related to the LaTeX output @@ -1607,7 +1608,7 @@ PAPER_TYPE = a4 # If left blank no extra packages will be included. # This tag requires that the tag GENERATE_LATEX is set to YES. -EXTRA_PACKAGES = +EXTRA_PACKAGES = # The LATEX_HEADER tag can be used to specify a personal LaTeX header for the # generated LaTeX document. The header should contain everything until the first @@ -1623,7 +1624,7 @@ EXTRA_PACKAGES = # PROJECT_NAME), or the project number (see PROJECT_NUMBER). # This tag requires that the tag GENERATE_LATEX is set to YES. -LATEX_HEADER = +LATEX_HEADER = # The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the # generated LaTeX document. The footer should contain everything after the last @@ -1632,7 +1633,7 @@ LATEX_HEADER = # Note: Only use a user-defined footer if you know what you are doing! # This tag requires that the tag GENERATE_LATEX is set to YES. -LATEX_FOOTER = +LATEX_FOOTER = # The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the LATEX_OUTPUT output @@ -1640,7 +1641,7 @@ LATEX_FOOTER = # markers available. # This tag requires that the tag GENERATE_LATEX is set to YES. -LATEX_EXTRA_FILES = +LATEX_EXTRA_FILES = # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is # prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will @@ -1740,14 +1741,14 @@ RTF_HYPERLINKS = NO # default style sheet that doxygen normally uses. # This tag requires that the tag GENERATE_RTF is set to YES. -RTF_STYLESHEET_FILE = +RTF_STYLESHEET_FILE = # Set optional variables used in the generation of an RTF document. Syntax is # similar to doxygen's config file. A template extensions file can be generated # using doxygen -e rtf extensionFile. # This tag requires that the tag GENERATE_RTF is set to YES. -RTF_EXTENSIONS_FILE = +RTF_EXTENSIONS_FILE = #--------------------------------------------------------------------------- # Configuration options related to the man page output @@ -1808,13 +1809,13 @@ XML_OUTPUT = xml # validating XML parser to check the syntax of the XML files. # This tag requires that the tag GENERATE_XML is set to YES. -XML_SCHEMA = +XML_SCHEMA = # The XML_DTD tag can be used to specify a XML DTD, which can be used by a # validating XML parser to check the syntax of the XML files. # This tag requires that the tag GENERATE_XML is set to YES. -XML_DTD = +XML_DTD = # If the XML_PROGRAMLISTING tag is set to YES doxygen will dump the program # listings (including syntax highlighting and cross-referencing information) to @@ -1891,7 +1892,7 @@ PERLMOD_PRETTY = YES # overwrite each other's variables. # This tag requires that the tag GENERATE_PERLMOD is set to YES. -PERLMOD_MAKEVAR_PREFIX = +PERLMOD_MAKEVAR_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the preprocessor @@ -1932,7 +1933,7 @@ SEARCH_INCLUDES = YES # preprocessor. # This tag requires that the tag SEARCH_INCLUDES is set to YES. -INCLUDE_PATH = +INCLUDE_PATH = # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard # patterns (like *.h and *.hpp) to filter out the header-files in the @@ -1940,7 +1941,7 @@ INCLUDE_PATH = # used. # This tag requires that the tag ENABLE_PREPROCESSING is set to YES. -INCLUDE_FILE_PATTERNS = +INCLUDE_FILE_PATTERNS = # The PREDEFINED tag can be used to specify one or more macro names that are # defined before the preprocessor is started (similar to the -D option of e.g. @@ -1950,7 +1951,7 @@ INCLUDE_FILE_PATTERNS = # recursively expanded use the := operator instead of the = operator. # This tag requires that the tag ENABLE_PREPROCESSING is set to YES. -PREDEFINED = +PREDEFINED = # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this # tag can be used to specify a list of macro names that should be expanded. The @@ -1959,7 +1960,7 @@ PREDEFINED = # definition found in the source code. # This tag requires that the tag ENABLE_PREPROCESSING is set to YES. -EXPAND_AS_DEFINED = +EXPAND_AS_DEFINED = # If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will # remove all refrences to function-like macros that are alone on a line, have an @@ -1988,13 +1989,13 @@ SKIP_FUNCTION_MACROS = YES # the path). If a tag file is not located in the directory in which doxygen is # run, you must also specify the path to the tagfile here. -TAGFILES = +TAGFILES = # When a file name is specified after GENERATE_TAGFILE, doxygen will create a # tag file that is based on the input files it reads. See section "Linking to # external documentation" for more information about the usage of tag files. -GENERATE_TAGFILE = +GENERATE_TAGFILE = # If the ALLEXTERNALS tag is set to YES all external class will be listed in the # class index. If set to NO only the inherited external classes will be listed. @@ -2042,14 +2043,14 @@ CLASS_DIAGRAMS = YES # the mscgen tool resides. If left empty the tool is assumed to be found in the # default search path. -MSCGEN_PATH = +MSCGEN_PATH = # You can include diagrams made with dia in doxygen documentation. Doxygen will # then run dia to produce the diagram and insert it in the documentation. The # DIA_PATH tag allows you to specify the directory where the dia binary resides. # If left empty dia is assumed to be found in the default search path. -DIA_PATH = +DIA_PATH = # If set to YES, the inheritance and collaboration graphs will hide inheritance # and usage relations if the target is undocumented or is not a class. @@ -2098,7 +2099,7 @@ DOT_FONTSIZE = 10 # the path where dot can find it using this tag. # This tag requires that the tag HAVE_DOT is set to YES. -DOT_FONTPATH = +DOT_FONTPATH = # If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for # each documented class showing the direct and indirect inheritance relations. @@ -2236,26 +2237,26 @@ INTERACTIVE_SVG = NO # found. If left blank, it is assumed the dot tool can be found in the path. # This tag requires that the tag HAVE_DOT is set to YES. -DOT_PATH = +DOT_PATH = # The DOTFILE_DIRS tag can be used to specify one or more directories that # contain dot files that are included in the documentation (see the \dotfile # command). # This tag requires that the tag HAVE_DOT is set to YES. -DOTFILE_DIRS = +DOTFILE_DIRS = # The MSCFILE_DIRS tag can be used to specify one or more directories that # contain msc files that are included in the documentation (see the \mscfile # command). -MSCFILE_DIRS = +MSCFILE_DIRS = # The DIAFILE_DIRS tag can be used to specify one or more directories that # contain dia files that are included in the documentation (see the \diafile # command). -DIAFILE_DIRS = +DIAFILE_DIRS = # The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes # that will be shown in the graph. If the number of nodes in a graph becomes diff --git a/doc/TW_Skia/Rapport.tex b/doc/TW_Skia/Rapport.tex index 4c91c4f6..e7a8e3e4 100644 --- a/doc/TW_Skia/Rapport.tex +++ b/doc/TW_Skia/Rapport.tex @@ -59,8 +59,7 @@ \tableofcontents -\chapter*{Introduction} -\addcontentsline{toc}{chapter}{Introduction} +\chapter{Introduction} \par Il y a longtemps, au début des années 2000, l'Association des Étudiants a mis en place un site internet qui n'a eu de cesse d'évoluer au fil des ans. Grâce aux différents contributeurs qui s'y sont plongés, et qui ont pu y ajouter leurs fonctionnalités plus ou moins utiles, le site possède désormais un ensemble de fonctionnalité impressionnant. @@ -71,6 +70,10 @@ maintenir à l'heure actuelle, et le besoin d'une refonte s'imposait de plus en \par Le choix de technologies récentes, maintenues, et éprouvée a donc été fait, et le développement a pu commencer dès Novembre 2015, avec l'objectif d'une mise en production dans l'été 2016, au moins dans une version incluant l'intégralité des fonctions liées à l'argent, qui sont les plus critiques. +\par Soutenant les projets libres, j'ai décidé de placer le projet sous licence MIT, assurant ainsi une pérénité aux +source. Si quelqu'un dans le futur souhaite le relicencier sous GPL ou autre, cela reste possible, mais je n'impose au +départ que très peu de restrictions \footnote{La seule condition en réalité, est de toujours garder à sa place une copie +de la licence originale, à savoir le fichier LICENSE à la racine du site.} . \chapter{Les technologies} \label{cha:les_technologies} @@ -480,99 +483,223 @@ comptoirs et des produits, ainsi que des données de comptabilité. \par L'application \emph{Core} est de loin la plus importante de toutes. C'est elle qui gère les utilisateurs ainsi que leurs droits. Le CMS y est aussi définit pour tout ce qui est pages de Wiki, pages statiques, ou l'ajout du filtre \verb#markdown# pour les templates. + \subsection{Liste des modèles} \label{sub:liste_des_mod_les} +\begin{itemize} + \item \textbf{Group} \\ + Ce modèle se subdivise en deux: RealGroup et MetaGroup, décrivant respectivement un vrai groupe géré à la main + dans la liste des groupes, et un meta-groupe, géré automatiquement, en général par les clubs, ou bien par les + cotisations. + \item \textbf{User} \\ + Le modèle des utilisateurs, qui est ensuite décliné ou référencé dans beaucoup d'applications pour les + utilisations spécifiques. C'est toutefois ici que sont déclarés les fonctions de gestion des droits des + utilisateurs, afin de pouvoir les utiliser partout ailleurs. + \item \textbf{AnonymousUser} \\ + Cette classe n'est pas un modèle stocké en base, puisqu'elle sert à instancier la variable \verb#user# + lorsqu'aucun utilisateur n'est connecté au site. + \item \textbf{Page} \\ + Décrit une entité page, servant dans le Wiki ou pour les pages statiques du site. Cette classe s'occupe des + méta-données de la page, comme ses droits, mais son contenu est en réalité stocké dans un objet \verb#PageRev#. + \item \textbf{PageRev} \\ + Décrit une révision de page. Utiliser une autre classe avec une \verb#ForeignKey# permet de gérer facilement un + historique des révisions. +\end{itemize} + +\subsection{La gestion des droits} +\label{sub:la_gestion_des_droits} +\par La gestion des droits est implémentée de manière globale dans l'application Core. +\par On trouve en effet dans \verb#views/__init__.py# un certain nombre de mixins \footnote{Un mixin est, en +\emph{Django}, un terme désignant une classe abstraite qui ne peut pas servir de parente seule. Elle permet de +surcharger certaines méthodes d'une autre classe abstraite afin de l'adapter à un comportement plus spécifique, mais +reste totalement inutile quand elle est seule. La gestion des droits est un bon exemple puisqu'elle ne s'occupe pas +vraiment de traitement des données comme les autres vues le ferait, elle permet simplement d'ajouter une condition à une +autre classe où cette dernière renverrait un \emph{403 Forbidden} } s'occupant de cela, en se basant sur +un modèle général permettant de rendre compatible rapidement n'importe quel modèle que l'on voudrait protéger. Il suffit +alors de déclarer dans la classe une certain nombre de méthodes et/ou d'attributs, le reste étant simplement déjà pris +en charge par les mixins suivants: +\begin{itemize} + \item \textbf{CanCreateMixin} \\ + Cette classe est à mettre en parente d'une classe héritant de \verb#CreateView#, afin d'empêcher quelqu'un + n'ayant pas les droits de créer un objet.\\ + Méthode correspondante à créer dans les modèles: \\ + \verb#def can_be_created_by(user):# \\ + (Attention, ce n'est pas une méthode prenant \verb#self# en premier paramètre!) + \item \textbf{CanEditPropMixin} \\ + Cette classe protège l'objet pour l'édition avancée. Par exemple: éditer les droits sur une page, ou éditer les + droits accordé à un utilisateur. \\ + Attribut correspondant à créer dans les modèles: \\ + \verb#owner_group = models.ForeignKey(Group, # \\ + \verb# related_name="owned_user", default=settings.SITH_GROUPS['root']['id'])# \\ + Méthode correspondante à créer dans les modèles: \\ + \verb#def is_owned_by(self, user):# \\ + \item \textbf{CanEditMixin} \\ + Cette classe protège l'objet pour l'édition non avancée. Par exemple: éditer une page, ou éditer le profil d'un + utilisateur. \\ + Attribut correspondant à créer dans les modèles: \\ + \verb#edit_groups = models.ManyToManyField(Group, # \\ + \verb# related_name="editable_user", blank=True)# \\ + Méthode correspondante à créer dans les modèles: \\ + \verb#def can_be_edited_by(self, user):# \\ + \item \textbf{CanEditPropMixin} \\ + Cette classe protège l'objet pour la vue. Par exemple: consulter une page, ou voir le profil d'un utilisateur. \\ + Attribut correspondant à créer dans les modèles: \\ + \verb#view_groups = models.ManyToManyField(Group, # \\ + \verb# related_name="viewable_user", blank=True)# \\ + Méthode correspondante à créer dans les modèles: \\ + \verb#def can_be_viewed_by(self, user):# \\ +\end{itemize} +\par Pour savoir si l'on doit implémenter les méthodes, les attributs, ou les deux, il faut simplement se poser la +question de savoir si l'objet en question requiert une gestion des droits à l'échelle de la classe ou à l'échelle de +l'objet, et si cette gestion peut être calculé par de la logique. +\par Si on a besoin d'une gestion pour la classe, ou si du code peut être implémenter pour déterminer qui peut avoir tel +droit, alors la méthode suffira. Mais si on a besoin d'une gestion au niveau de l'objet, alors il faudra certainement +recourir aux attributs. +\par Exemples: +\begin{itemize} + \item Les comptes en banques sont gérés uniquement par les personnes faisant partie du groupe \verb#admin-compta#. + Ils ont donc tous les même droits, c'est une gestion au niveau de la classe, donc les méthodes suffisent. + \item Les classeurs de comptabilité sont gérés par les trésoriers des clubs, ils n'ont pas tous les même droits, + mais cela peut tout de même se calculer en fonction des postes dans les clubs correspondants. On a donc besoin + des méthodes uniquement. + \item Les pages n'appartiennent pas forcément à un club, ni à une quelconque entité, mais ont tout de même besoin de + gestion des droits au niveau de l'objet. L'ajout des attributs est donc nécessaire pour pouvoir gérer cela au + cas par cas. +\end{itemize} \section{Subscription} \label{sec:subscription} \subsection{Résumé} \label{sub:r_sum_} +\par Cette application étend le modèle \verb#User# pour y ajouter le support des cotisations. Elle fournit également les +interfaces de cotisation. \subsection{Liste des modèles} \label{sub:liste_des_mod_les} - +\begin{itemize} + \item \textbf{Subscriber} \\ + Un modèle proxy de \verb#User# fournissant les méthodes pour rapidement savoir si l'utilisateur est cotisant ou + non. + \item \textbf{Subscription} \\ + Un modèle cotisation, pour stocker ces dernières. Cette classe fait automatiquement les calculs de début et de + fin de cotisation en fonction de la date du jour, du type de cotisation, et de la durée en semestre de + cotisation. +\end{itemize} \section{Accounting} \label{sec:accounting} \subsection{Résumé} \label{sub:r_sum_} +\par Cette application sert à gérer à la comptabilité. Elle est architecturée de façon hiérarchique, avec en haut, les +comptes bancaires réels, qui contiennent eux des comptes de clubs, permettant de les diviser en plusieurs petits comptes +en interne, et enfin les classeurs de trésorerie, propres à chaque compte club, permettant de faire les comptes en +triant par semestre. +\par De plus, cette application définit un nouveau type de champ dans la base de donnée: le champ \verb#CurrencyField#, +permettant de stocker de valeurs monétaires. \subsection{Liste des modèles} \label{sub:liste_des_mod_les} - +\begin{itemize} + \item \textbf{BankAccount} \\ + Le modèle des comptes bancaires. + \item \textbf{ClubAccount} \\ + Le modèle des comptes clubs. + \item \textbf{GeneralJournal} \\ + Le modèle des classeurs de comptabilité, généralement semestriels, mais ils peuvent toutefois fonctionner en + année pour les activités plus longues comme le Gala. + \item \textbf{AccountingType} \\ + Le modèle pour stocker les types comptables, servant à remplir les opérations. + \item \textbf{Operation} \\ + Le modèle des opérations, servant à remplir les classeurs comptables. Un opération peut être un débit ou un + crédit, et permet ensuite d'éditer des factures, par exemple. +\end{itemize} \section{Counter} \label{sec:counter} \subsection{Résumé} \label{sub:r_sum_} +\par Cette application s'occupe de la gestion des comptoirs. Elle définit ainsi des produits, et ajoute également le +support du compte AE pour les utilisateurs. \subsection{Liste des modèles} \label{sub:liste_des_mod_les} +\begin{itemize} + \item \textbf{Customer} \\ + Ce modèle étend l'utilisateur pour lui rajouter un compte AE. Il est lié à la classe \verb#User# par un + \verb#OneToOneField#. + \item \textbf{ProductType} \\ + Ce modèle ajoute des types de produits afin de catégoriser ces derniers. + \item \textbf{Product} \\ + Ce modèle décrit les produits pouvant être vendus dans les différents comptoirs. + \item \textbf{Counter} \\ + Ce modèle décrit les comptoirs, qui permettent de générer des recharges de compte et des ventes de produits. + \item \textbf{Refilling} \\ + Ce modèle permet de stocker les rechargements de compte. + \item \textbf{Selling} \\ + Ce modèle permet d'enregistrer toutes les ventes de produits. +\end{itemize} \section{Club} \label{sec:club} \subsection{Résumé} \label{sub:r_sum_} +\par Cette application permet de générer les clubs et les adhésions des utilisateur à ceux-ci. \subsection{Liste des modèles} \label{sub:liste_des_mod_les} +\begin{itemize} + \item \textbf{Club} \\ + Le modèle des clubs. + \item \textbf{Membership} \\ + Le modèle des adhésions. Stocker cela dans un modèle à part permet de conserver un historique des personnes + ayant eu un rôle quelconque dans un club quelconque. +\end{itemize} -\chapter*{Conclusion} -\addcontentsline{toc}{chapter}{Conclusion} +\chapter{Conclusion} +\par Encore une fois, ce rapport ne se veut absolument pas exhaustif sur quoi que ce soit. +\par Concernant \emph{Python}, \emph{Django}, ou \emph{Jinja}, les documentations respectives sont toujours très bien +faites, et permettront de répondre à toutes les questions techniques concernant les technologies. +\par Concernant le projet \emph{Sith} en lui-même, ce rapport n'est pas non plus exhaustif. Pour cela, lire le code des +différentes sections sera le meilleur moyen de comprendre le fonctionnement des différentes fonctions. Pour obtenir plus +rapidement un résumé à jour des sources, le fichier \verb#Doxyfile# présent à la racine du site permet de regénérer de +la documentation exhaustive rapidement à l'aide de \emph{Doxygen} (voir la section correspondante dans le README). +\par J'espère toutefois que même s'il n'est pas complet, ce rapport permettra à tout futur contributeur de rentrer plus +rapidement dans le projet. +\par L'idéal serait également de maintenir à jour ce rapport du mieux possible en même temps que le développement +avance, même si je ne me fais guère d'illusions en pratique. -\appendix -\addtolength{\textheight}{60mm} -\part*{Annexes} -\addtolength{\topmargin}{-50mm} -\definecolor{gray75}{gray}{0.75} -\newcommand{\hsp}{\hspace{20pt}} -\titleformat{\chapter}[block]{\Huge\bfseries}{\thechapter\hsp\textcolor{gray75}{|}\hsp}{0pt}{\Huge\bfseries}[\vskip -2em] +\section{Pour le futur...} +\label{sec:pour_le_futur} +\par En l'état actuel des choses, un grand nombre d'éléments sont encore manquants au site: +\begin{itemize} + \item Une API REST pour pouvoir facilement intégrer d'autres outils autour du site. + \item Du CSS, pour qu'il soit un peu plus joli à regarder. + \item Du Javascript, et particulièrement de l'AJAX pour améliorer l'ergonomie de certaines pages. + \item Un grand nombre de vues pour aider à gérer les données plus efficacement, ou à les gérer tout court dans + certains cas. + \item Quelques applications utiles à qui existent sur le site actuel, mais que je n'ai pas encore eu le temps de + développer: un forum, une galerie de photos, une gestion basique des fichiers pour uploader des documents dans + les pages ou le forum, un système de news, une newsletter (Weekmail), une gestion des sondages et des élections, + etc... +\end{itemize} -% \chapter{Classe python} -% \label{python_class} -% \begin{figure}[H] -% \begin{lstlisting}[language=python,morekeywords={True,False}] -% host_to_host = Table("host_to_host", Base.metadata, -% Column("cluster_id", Integer, ForeignKey("host.host_id"), primary_key=True), -% Column("node_id", Integer, ForeignKey("host.host_id"), primary_key=True) -% ) -% class Host(Base): -% __tablename__ = 'host' -% host_id = Column(Integer, primary_key=True, nullable=False) -% groups = Column(String(30), ForeignKey("env.name")) -% name = Column(String(30), unique=True, nullable=False, -% default="UNKNOWN HOST") -% address = Column(String(30), nullable=False, default="0.0.0.0") -% alias = Column(String(30), nullable=True, default="") -% state = Column(String(10), nullable=False, default=0) -% num_services = Column(Integer, nullable=False, default=0) -% num_services_crit = Column(Integer, nullable=False, default=0) -% num_services_unknown = Column(Integer, nullable=False, default=0) -% num_services_warn = Column(Integer, nullable=False, default=0) -% scheduled_downtime_depth = Column(Integer, nullable=False, default=0) -% _json_extra = Column(Text, nullable=True) -% _last_time = Column(DateTime, server_default=func.now(), -% onupdate=func.current_timestamp()) -% _location = Column(String(4), nullable=True) -% _nodes = relationship("Host", -% backref="_clusters", -% secondary=host_to_host, -% primaryjoin=host_id==host_to_host.c.cluster_id, -% secondaryjoin=host_id==host_to_host.c.node_id, -% ) -% \end{lstlisting} -% \caption{Classe python} -% \end{figure} -% \par -% On voit bien que l'on définit les attributs de la classe à la manière des colonnes d'une table dans une base de -% donnée. -% \par -% On met aussi ici en place une relation \emph{Many To Many} entre les Hosts à l'aide de la table de jointure définie -% juste avant: \emph{host\_to\_host}. +\section{Apports personnels} +\label{sec:apports_personnels} +\par Même s'il est vrai que j'ai beaucoup appris en développement ce site, cela reste avant tout un travail de quantité +plus que de qualité: on définit des modèles, puis les vues correspondantes en terminant par les templates, et on répète +l'opération pour l'application suivante. +\par Mais j'ai tout de même pu mettre en place de l'intégration continue pour ce projet, ce qui a été certes, très +rapide, mais toutefois très enrichissant, étant donnée que ces méthodes sont très en vogue ces derniers temps. +\par J'ai également pu me familiariser d'avantage avec le fonctionnement d'un ORM, et la magie noire que cela permet de +faire \footnote{Je trouve toujours magique de pouvoir faire une requête SQL au milieu d'un template sans que cela +paraisse affreux :)}. +\par Enfin, j'espère que ce projet va, en plus d'être correctement mené au bout, pouvoir être repris par la suite par +les futurs membres de l'équipe info de l'AE, et pourquoi pas par d'autre contributeurs... +\vskip 3em +\emph{Skia - 2016} \end{document} -%s/ \(SQLalchemy\|SQLite\)/ \\emph{\1}/