Merge branch 'master' of gitlab.com:allianceauth/allianceauth into v4.x

docs/development/custom/index.md

@@ -2,14 +2,12 @@
 
 This section describes how to extend **Alliance Auth** with custom apps, services and themes.
 
-```eval_rst
-.. toctree::
-    :maxdepth: 1
+:::{toctree}
+:maxdepth: 1
 
-    integrating-services
-    custom-themes
-    menu-hooks
-    url-hooks
-    logging
-    css-framework
-```
+integrating-services
+menu-hooks
+url-hooks
+logging
+css-framework
+:::

docs/development/custom/integrating-services.md

@@ -21,19 +21,19 @@ Typically a service will contain 5 key components:
 The architecture looks something like this:
 
 ```none
-  urls -------▶ Views
-    ▲              |
-    |              |
-    |              ▼
-ServiceHook ----▶ Tasks ----▶ Manager
-    ▲
-    |
-    |
-AllianceAuth
+        urls -------▶ Views
+          ▲              |
+          |              |
+          |              ▼
+      ServiceHook ----▶ Tasks ----▶ Manager
+          ▲
+          |
+          |
+      AllianceAuth
 
 
-Where:
-  Module --▶ Dependency/Import
+    Where:
+        Module --▶ Dependency/Import
 ```
 
 While this is the typical structure of the existing services modules, there is no enforcement of this structure and you are, effectively, free to create whatever architecture may be necessary. A service module need not even communicate with an external service, for example, if similar triggers such as validate_user, delete_user are required for a module it may be convenient to masquerade as a service. Ideally though, using the common structure improves the maintainability for other developers.
@@ -50,23 +50,22 @@ def register_service():
 
 This would register the ExampleService class which would need to be a subclass of `services.hooks.ServiceHook`.
 
-```eval_rst
-.. important::
-    The hook **MUST** be registered in ``yourservice.auth_hooks`` along with any other hooks you are registering for Alliance Auth.
-```
+:::{important}
+The hook **MUST** be registered in ``yourservice.auth_hooks`` along with any other hooks you are registering for Alliance Auth.
+:::
 
 A subclassed `ServiceHook` might look like this:
 
 ```python
 class ExampleService(ServicesHook):
-def __init__(self):
-    ServicesHook.__init__(self)
-    self.urlpatterns = urlpatterns
-    self.service_url = 'http://exampleservice.example.com'
+  def __init__(self):
+      ServicesHook.__init__(self)
+      self.urlpatterns = urlpatterns
+      self.service_url = 'http://exampleservice.example.com'
 
-    """
-    Overload base methods here to implement functionality
-    """
+  """
+  Overload base methods here to implement functionality
+  """
 ```
 
 ### The ServiceHook class
@@ -79,7 +78,7 @@ Instance Variables:
 
 - [self.name](#selfname)
 - [self.urlpatterns](#selfurlpatterns)
-- [self.service_ctrl_template](#selfservice-ctrl-template)
+- [self.service_ctrl_template](#selfservice_ctrl_template)
 
 Properties:
 
@@ -123,7 +122,9 @@ class MyService(ServiceHook):
 
 All of your apps defined urlpatterns will then be included in the `URLconf` when the core application starts.
 
-### Properties
+#### self.service_ctrl_template
+
+This is provided as a courtesy and defines the default template to be used with [render_service_ctrl](#render_service_ctrl). You are free to redefine or not use this variable at all.
 
 #### title
 
@@ -150,12 +151,14 @@ The function should return a boolean, `True` if successfully disabled, `False` o
 Validate the users service account, deleting it if they should no longer have access. The `user` parameter should be a Django User object.
 
 An implementation will probably look like the following:
+
 ```python
 def validate_user(self, user):
 logger.debug('Validating user %s %s account' % (user, self.name))
 if ExampleTasks.has_account(user) and not self.service_active_for_user(user):
     self.delete_user(user, notify_user=True)
 ```
+
 No return value is expected.
 
 This function will be called periodically on all users to validate that the given user should have their current service accounts.
@@ -312,3 +315,9 @@ You should have a look through some of the other service modules before you get
 ## Testing
 
 You will need to add unit tests for all aspects of your service module before it is accepted. Be mindful that you don't actually want to make external calls to the service so you should mock the appropriate components to prevent this behavior.
+
+```{eval-rst}
+.. autoclass:: allianceauth.services.hooks.ServicesHook
+    :members:
+    :undoc-members:
+```

docs/development/custom/logging.md

@@ -36,3 +36,11 @@ Options are: *(all options accept entries of levels listed below them)*
 * `WARNING`
 * `ERROR`
 * `CRITICAL`
+
+## allianceauth.services.hooks.get_extension_logger
+
+```{eval-rst}
+.. automodule:: allianceauth.services.hooks.get_extension_logger
+    :members:
+    :undoc-members:
+```

docs/development/custom/menu-hooks.md

@@ -12,7 +12,7 @@ def register_menu():
 
 The `MenuItemHook` class specifies some parameters/instance variables required for menu item display.
 
-```eval_rst
+```{eval-rst}
 .. autoclass:: allianceauth.services.hooks.MenuItemHook
     :members: __init__
     :undoc-members:
@@ -24,23 +24,22 @@ The `MenuItemHook` class specifies some parameters/instance variables required f
 
 This is a great feature to signal the user, that he has some open issues to take care of within an app. For example Auth uses this feature to show the specific number of open group request to the current user.
 
-```eval_rst
-.. hint::
-    Here is how to stay consistent with the Auth design philosophy for using this feature:
-    1. Use it to display open items that the current user can close by himself only. Do not use it for items, that the user has no control over.
-    2. If there are currently no open items, do not show a badge at all.
-```
+:::{hint}
+Here is how to stay consistent with the Auth design philosophy for using this feature:
 
+1. Use it to display open items that the current user can close by himself only. Do not use it for items, that the user has no control over.
+2. If there are currently no open items, do not show a badge at all.
+:::
 To use it set count the `render()` function of your subclass in accordance to the current user. Here is an example:
 
-```eval_rst
+```{eval-rst}
 .. automodule:: allianceauth.services.hooks.MenuItemHook
     :members: render
     :noindex:
     :undoc-members:
 ```
 
-```Python
+```python
 def render(self, request):
     # ...
     self.count = calculate_count_for_user(request.user)

docs/development/custom/url-hooks.md

@@ -30,10 +30,11 @@ In addition is it possible to make views public. Normally, all views are automat
 
 An app can opt-out of this feature by adding a list of views to be excluded when registering the URLs. See the `excluded_views` parameter for details.
 
-```eval_rst
-.. note::
-    Note that for a public view to work, administrators need to also explicitly allow apps to have public views in their AA installation, by adding the apps label to ``APPS_WITH_PUBLIC_VIEWS`` setting.
-```
+:::{note}
+Note that for a public view to work, administrators need to also explicitly allow apps to have public views in their AA installation, by adding the apps label to ``APPS_WITH_PUBLIC_VIEWS`` setting.
+:::
+
+>>>>>>>
 ## Examples
 
 An app called `plugin` provides a single view:
@@ -70,7 +71,7 @@ When this app is included in the project's `settings.INSTALLED_APPS` users would
 
 ## API
 
-```eval_rst
+```{eval-rst}
 .. autoclass:: allianceauth.services.hooks.UrlHook
     :members:
 ```