editorconfig applied

This commit is contained in:
Peter Pfeufer
2021-05-17 11:42:28 +02:00
parent bad36a69e8
commit e6a4cea4de
99 changed files with 522 additions and 600 deletions

View File

@@ -21,18 +21,18 @@ Typically a service will contain 5 key components:
The architecture looks something like this:
urls -------▶ Views
▲ |
| |
| ▼
ServiceHook ----▶ Tasks ----▶ Manager
|
|
AllianceAuth
▲ |
| |
| ▼
ServiceHook ----▶ Tasks ----▶ Manager
|
|
AllianceAuth
Where:
Module --▶ Dependency/Import
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.

View File

@@ -42,9 +42,9 @@ This is a great feature to signal the user, that he has some open issues to take
```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.
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: