settings.rst 9.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226
  1. ========
  2. Settings
  3. ========
  4. Accessing Settings
  5. ==================
  6. Misago splits its settings into two groups:
  7. * **Low level settings** - those settings must be available when Misago starts or control resources usage and shouldn't be changed frequently from admin control panel. Those settings live in ``settings.py``
  8. * **High level settings** - those settings are stored in database and can be changed on runtime using interface provided by admin control panel.
  9. Both types of settings can accessed as attributes of ``misago.conf.settings`` object and high level settings can be also accessed from your templates as attributes of ``misago_settings`` context value.
  10. .. note::
  11. Not all high level settings values are available at all times. Some settings ("lazy settings"), are evaluated to ``True`` or ``None`` immediately upon load. This means while they can be checked to see if they have value or not, but require you to use special ``get_lazy_setting(setting)`` getter to actually obtain their real value.
  12. Defining Custom DB Settings
  13. ===========================
  14. .. note::
  15. Current Misago 0.6 migrations are south-based placeholders that will be replaced with new migrations introduced in Django 1.7 before release. For this reason this instruction focuses exclusively on usage of utility function provided by Misago.
  16. In order to define or change high-level (stored in database) settings you have to add new rows to ``conf_settingsgroup`` and ``conf_settings`` database tables. This can be done by plenty of different ways, but preffered one is by creating new data migration and using functions from ``misago.conf.migrationutils`` module.
  17. migrate_settings_group
  18. ----------------------
  19. .. function:: migrate_settings_group(orm, group_fixture, old_group_key=None)
  20. This function uses south supplied ORM instance to insert/update settings group in database according to provided dict contianing its name, description and contained settings. If new group should replace old one, you can provide its key in ``old_group_key`` argument.
  21. The ``group_fixture`` dict should define following keys:
  22. * **key** - string with settings group key.
  23. * **name** - string with settings group name.
  24. * **description** - optional string with short settings group description.
  25. * **settings** - tuple containing dics describing settings belonging to this group.
  26. Each dict in ``settings`` tuple should define following keys:
  27. * **setting** - string with internal setting name.
  28. * **name** - string with displayed setting name.
  29. * **description** - optional string with small setting help message.
  30. * **legend** - optional string indicating that before displaying this setting in form, new fieldset should be opened and this value should be used in its legend element.
  31. * **python_type** - optional string defining type of setting's value. Can be either "string", "int", "bool" or "list". If omitted "string" is used by default.
  32. * **value** - list, integer or string with default value for this setting.
  33. * **default_value** - if your setting should always have value, specify there fallabck value used if no user-defined value is available.
  34. * **is_lazy** - if setting value may too large to be always loaded into memory, you may make setting lazily loaded by defining this key with ``True`` value assigned.
  35. * **form_field** - What form field should be used to change this setting. Can be either "text", "textarea", "select", "radio", "yesno" or "checkbox". If not defined, "text" is used. "checkbox" should be used exclusively for multiple choices list.
  36. * **field_extra** - dict that defines extra attributes of form field. For "select", "radio" and "checkbox" fields this dict should contain "choices" key with tuple of tuples that will be used for choices in input. For "string" settings you can define "min_length" and "max_length" extra specifying minmal and maximal lenght of entered text. For integer settings you can specify minimal and maximal range in which value should fall by "min_value" and "max_value".
  37. .. note::
  38. If you wish to make your names and messages translateable, you should use ``ugettext_lazy`` function provided by Misago instead of Django one. This function is defined in ``misago.core.migrationutils`` module and differs from Django one by the fact that it preserves untranslated message on its ``message`` attribute.
  39. For your convience ``migrate_settings_group`` triess to switch translation messages with their "message" attribute when it writes to database and thus making their translation to new languages in future possible.
  40. with_conf_models
  41. ----------------
  42. .. function:: with_conf_models(migration, this_migration=None)
  43. South migrations define special ``models`` attribute that holds dict representing structure of database at time of migration execution. This dict will by default contain only your apps models. To add settings models that ``migrate_settings_group`` requires to work, you have to use ``with_conf_models`` function. This function accepts two arguments:
  44. * **migration** - name of migration in ``misago.conf`` app containing models definitions current for the time of your data migration.
  45. * **this_migration** - dict with model definitions for this migration.
  46. In addition to this, make sure that your migration ``depends_on`` attribute defines dependency on migration from ``misago.conf`` app::
  47. class Migration(DataMigration):
  48. # Migration code...
  49. models = with_conf_models('0001_initial', {
  50. # This migration models
  51. })
  52. depends_on = (
  53. ("conf", "0001_initial"),
  54. )
  55. delete_settings_cache
  56. ---------------------
  57. .. function:: delete_settings_cache()
  58. If you have used ``migrate_settings_group`` function in your migration, make sure to call ``delete_settings_cache`` at its end to flush settings caches.
  59. Misago Settings Reference
  60. =========================
  61. By convention, low level settings are written in UPPER_CASE and high level ones are written in lower_case.
  62. account_activation
  63. ------------------
  64. Preffered way in which new user accounts are activated. Can be either of those:
  65. * **none** - no activation required.
  66. * **user** - new user has to click link in activation e-mail.
  67. * **admin** - board administrator has to activate new accounts manually.
  68. * **block** - turn new registrations off.
  69. avatars_types
  70. -------------
  71. List of avatar sources available to users:
  72. * **gravatar** - Gravatar.
  73. * **upload** - avatar uploads.
  74. * **gallery** - predefined gallery.
  75. avatar_upload_limit
  76. -------------------
  77. Max allowed size of uploaded avatars in kilobytes.
  78. default_avatar
  79. --------------
  80. Default avatar assigned to new accounts. Can be either ``gravatar`` or ``gallery`` which will make Misago pick random avatar from gallery instead.
  81. default_timezone
  82. ----------------
  83. Default timezone used by guests and newly registered users that haven't changed their timezone prefferences.
  84. forum_name
  85. ----------
  86. Forum name, displayed in default templates forum navbar and in titles of pages.
  87. forum_index_meta_description
  88. ----------------------------
  89. Forum index Meta Description used as value meta description attribute on forum index.
  90. forum_index_title
  91. -----------------
  92. Forum index title. Can be empty string if not set, in which case ``forum_name`` should be used instead.
  93. MISAGO_ADMIN_NAMESPACES
  94. -----------------------
  95. Link namespaces that are administrator-only areas that require additional security from Misago. Users will have to re-authenticate themselves to access those namespaces, even if they are already signed in your frontend. In addition they will be requested to reauthenticated if they were inactive in those namespaces for certain time.
  96. Defautly ``misago:admin`` and ``admin`` namespaces are specified, putting both Misago and Django default admin interfaces under extended security mechanics.
  97. MISAGO_ADMIN_PATH
  98. -----------------
  99. Path prefix for Misago administration backend. Defautly "admincp", but you may set it to empty string if you with to disable your forum administration backend.
  100. MISAGO_ADMIN_SESSION_EXPIRATION
  101. -------------------------------
  102. Maximum allowed lenght of inactivity period between two requests to admin namespaces. If its exceeded, user will be asked to sign in again to admin backed before being allowed to continue activities.
  103. MISAGO_MAILER_BATCH_SIZE
  104. ------------------------
  105. Default maximum size of single mails package that Misago will build before sending mails and creating next package.
  106. password_complexity
  107. -------------------
  108. Complexity requirements for new user passwords. It's value is list of strings representing following requirements:
  109. * **case** - mixed case.
  110. * **alphanumerics** - both digits and letters.
  111. * **special** - special characters.
  112. password_length_min
  113. -------------------
  114. Minimal required length of new user passwords.
  115. subscribe_reply
  116. ---------------
  117. Default value for automaticall subscription to replied threads prefference for new user accounts. Its value represents one of those settings:
  118. * **no** - don't watch.
  119. * **watch** - put on watched threads list.
  120. * **watch_email** - put on watched threads list and send e-mail when somebody replies.
  121. subscribe_start
  122. ---------------
  123. Default value for automaticall subscription to started threads prefference for new user accounts. Allows for same values as ``subscribe_reply``.
  124. username_length_max
  125. -------------------
  126. Maximal allowed username length.
  127. username_length_min
  128. -------------------
  129. Minimal allowed username length.