From 3b5630a66ca122f8f4ab485386bc2ad7771a61bc Mon Sep 17 00:00:00 2001 From: Mira Date: Thu, 19 Dec 2024 17:26:38 +0100 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Raphael Michel --- doc/development/api/plugins.rst | 6 +++--- doc/development/implementation/logging.rst | 20 ++++++++++---------- src/pretix/base/logentrytypes.py | 8 +++++--- src/pretix/base/signals.py | 15 +++++++++------ 4 files changed, 27 insertions(+), 22 deletions(-) diff --git a/doc/development/api/plugins.rst b/doc/development/api/plugins.rst index ddc05d30f..b3cc074a8 100644 --- a/doc/development/api/plugins.rst +++ b/doc/development/api/plugins.rst @@ -121,7 +121,7 @@ This will automatically make pretix discover this plugin as soon as it is instal through ``pip``. During development, you can just run ``python setup.py develop`` inside your plugin source directory to make it discoverable. -.. _`Signals`: +.. _`signals`: Signals ------- @@ -163,7 +163,7 @@ ticket renderer. However, for some of them (types of :ref:`Log Entries `) we use a different method to keep track of them: In a ``Registry``, classes are collected at application startup, along with a unique key (in case -of LogEntryType, the action_type) as well as which plugin registered them. +of LogEntryType, the ``action_type``) as well as which plugin registered them. To register a class, you can use one of several decorator provided by the Registry object: @@ -174,7 +174,7 @@ To register a class, you can use one of several decorator provided by the Regist pass All files in which classes are registered need to be imported in the ``AppConfig.ready`` as explained -in `Signals`_ above. +in `Signals `_ above. Views ----- diff --git a/doc/development/implementation/logging.rst b/doc/development/implementation/logging.rst index 42af697ee..ba195b757 100644 --- a/doc/development/implementation/logging.rst +++ b/doc/development/implementation/logging.rst @@ -73,7 +73,7 @@ following ready-to-include template:: {% include "pretixcontrol/includes/logs.html" with obj=order %} We now need a way to translate the action codes like ``pretix.event.changed`` into human-readable -strings. The :py:attr:`pretix.base.logentrytypes.log_entry_types` :ref:`Registry ` allows you to do so. A simple +strings. The :py:attr:`pretix.base.logentrytypes.log_entry_types` :ref:`registry ` allows you to do so. A simple implementation could look like: .. code-block:: python @@ -90,21 +90,21 @@ implementation could look like: class CoreOrderLogEntryType(OrderLogEntryType): pass -Please note that you always need to define your own inherited LogEntryType class in your plugin. If you would just -register an instance of a LogEntryType class defined in pretix core, it is not correctly registered as belonging to -your plugin, leading to confusing user interface situations. +Please note that you always need to define your own inherited ``LogEntryType`` class in your plugin. If you would just +register an instance of a ``LogEntryType`` class defined in pretix core, it cannot be automatically detected as belonging +to your plugin, leading to confusing user interface situations. Customizing log entry display -"""""""""""""""""""""""""""""""""" +""""""""""""""""""""""""""""" -The base LogEntryType classes allows for varying degree of customization in their descendants. +The base ``LogEntryType`` classes allow for varying degree of customization in their descendants. -If you want to add another log message for an existing core object (e.g. an Order, Item or Voucher), you can inherit -from its predefined LogEntryType, e.g. `OrderLogEntryType` and just specify a new plaintext string. You can use format +If you want to add another log message for an existing core object (e.g. an ``Order``, ``Item``, or ``Voucher``), you can inherit +from its predefined `LogEntryType`, e.g. `OrderLogEntryType`, and just specify a new plaintext string. You can use format strings to insert information from the LogEntry's `data` object as shown in the section above. -If you defined a new model object in your plugin, you should make sure proper object links in the user interface are +If you define a new model object in your plugin, you should make sure proper object links in the user interface are displayed for it. If your model object belongs logically to a pretix `Event`, you can inherit from `EventLogEntryType`, and set the `object_link_*` fields accordingly. `object_link_viewname` refers to a django url name, which needs to accept the arguments `organizer` and `event`, containing the respective slugs, and an argument named by `object_link_argname`. @@ -126,7 +126,7 @@ overwrite `object_link_display_name`. return order.code To show more sophisticated message strings, e.g. varying the message depending on information from the LogEntry's -`data` object, overwrite the `display` method: +`data` object, override the `display` method: .. code-block:: python diff --git a/src/pretix/base/logentrytypes.py b/src/pretix/base/logentrytypes.py index c2c233c16..27c32b03c 100644 --- a/src/pretix/base/logentrytypes.py +++ b/src/pretix/base/logentrytypes.py @@ -55,7 +55,7 @@ def make_link(a_map, wrapper, is_active=True, event=None, plugin_name=None): class LogEntryTypeRegistry(EventPluginRegistry): def new_from_dict(self, data): """ - Register multiple instance of a LogEntryType class with different action_type + Register multiple instance of a `LogEntryType` class with different `action_type` and plain text strings, as given by the items of the specified data dictionary. This method is designed to be used as a decorator as follows: @@ -142,7 +142,7 @@ class LogEntryType: class EventLogEntryType(LogEntryType): """ - Base class for any LogEntry type whose content_object is either an `Event` itself or belongs to a specific `Event`. + Base class for any `LogEntry` type whose `content_object` is either an `Event` itself or belongs to a specific `Event`. """ def get_object_link_info(self, logentry) -> dict: @@ -183,7 +183,9 @@ class VoucherLogEntryType(EventLogEntryType): object_link_argname = 'voucher' def object_link_display_name(self, voucher): - return voucher.code[:6] + if len(voucher.code) > 6: + return voucher.code[:6] + "…" + return voucher.code class ItemLogEntryType(EventLogEntryType): diff --git a/src/pretix/base/signals.py b/src/pretix/base/signals.py index 60ede6c34..84d9df170 100644 --- a/src/pretix/base/signals.py +++ b/src/pretix/base/signals.py @@ -254,7 +254,7 @@ class Registry: def __init__(self, keys): """ - :param keys: dictionary {key: accessor_function} + :param keys: Dictionary with `{key: accessor_function}` When a new entry is registered, all accessor functions are called with the new entry as parameter. Their return value is stored as the metadata value for that key. """ @@ -281,10 +281,12 @@ class Registry: for key, value in meta.items(): self.by_key[key][value] = tup self.registered_entries.append(tup) + if len(objs) == 1: + return objs[0] def new(self, *args, **kwargs): """ - Instantiate the decorated class with the given *args and **kwargs, and register the instance in this registry. + Instantiate the decorated class with the given `*args` and `**kwargs`, and register the instance in this registry. May be used multiple times. .. code-block:: python @@ -306,10 +308,11 @@ class Registry: return self.by_key.get(key).get(value, (None, None)) def filter(self, **kwargs): - return ((entry, meta) - for entry, meta in self.registered_entries - if all(value == meta[key] for key, value in kwargs.items()) - ) + return ( + (entry, meta) + for entry, meta in self.registered_entries + if all(value == meta[key] for key, value in kwargs.items()) + ) class EventPluginRegistry(Registry):