Merge pull request #225 from lcduong/sync-upstream-22nd

Synct commits from upstream

doc/administrator/commands.rst

@@ -99,14 +99,6 @@ pretalx detects that you don’t have a ``node_modules`` directory, but it’s y
 responsibility to use it during updates. It’s not the default as running ``npm
 install`` can take a long time.
 
-``regenerate_css``
-~~~~~~~~~~~~~~~~~~
-
-The ``regenerate_css`` command regenerates only the custom CSS for events. It
-only runs for events with a specified custom colour, or custom uploaded styles.
-You can specify an event slug with ``--event``. If no event is specified, the
-files for all relevant events will be rebuilt.
-
 ``init``
 ~~~~~~~~
 

doc/administrator/configure.rst

@@ -324,5 +324,14 @@ The locale section
 - **Environment variable:** ``PRETALX_TIME_ZONE``
 - **Default:** ``UTC``
 
+The files section
+-----------------
+
+``upload_limit``
+~~~~~~~~~~~~~~~~
+
+- The maximum file size for uploads in MB.
+- **Environment variable:** ``PRETALX_FILE_UPLOAD_LIMIT``
+- **Default:** ``10``
 
 .. _Python: https://docs.python.org/3/library/configparser.html

doc/administrator/installation.rst

@@ -183,8 +183,12 @@ adjust the content to fit your system::
     [Install]
     WantedBy=multi-user.target
 
-If you decide to use Celery (giving you asynchronous execution for long-running
-tasks), you’ll also need a second service
+pretalx optionally runs with Celery, a service that allows for long-running
+tasks (like sending many emails) to be performed asynchronously in the
+background. We strongly recommend running pretalx with Celery workers, as some
+things, like cleaning up unused files, are otherwise not going to work.
+
+To run Celery workers, you’ll need a second service
 ``/etc/systemd/system/pretalx-worker.service`` with the following content::
 
     [Unit]

doc/administrator/maintenance.rst

@@ -32,7 +32,6 @@ restart your service(s)::
     $ pip3 install --user --upgrade-strategy eager -U pretalx
     $ python -m pretalx migrate
     $ python -m pretalx rebuild --npm-install
-    $ python -m pretalx regenerate_css
     # systemctl restart pretalx-web
     # systemctl restart pretalx-worker  # If you’re running celery
 

doc/changelog.rst

@@ -3,12 +3,34 @@
 Release Notes
 =============
 
+- :bug:`schedule` The schedule would work only intermittently when used with a custom domain.
+- :bug:`cfp` The resource upload form always mentioned a hard-coded file upload limit (but would in reality allow files up to the size of the real file upload limit).
+- :bug:`schedule` Sessions with session image would not look good on some mobile devices.
+- :bug:`orga,1839` If the organisers initially showed the “do not record” checkbox, but then hid it, the sessions marked as unrecorded would still show the appropriate icon in the public schedule, without anybody being able to uncheck the checkbox. Instead, the indicator is now hidden if the checkbox can’t be accessed anymore.
+- :release:`2024.3.0 <2024-10-21>`
+- :feature:`orga` You can now drag rooms, tracks, questions, and even question options to reorder them.
+- :feature:`admin` You can now configure the maximum file upload size.
+- :feature:`cfp` You can now submit a form from textboxes with Ctrl+Enter.
+- :feature:`cfp` In browsers that support it (currently only Chrome), textboxes will now auto-expand when you write more text, rather than showing a scrollbar.
+- :feature:`schedule` When you look at a talk detail page, the start and end time is now also given in your local time (if you are not in the event timezone).
+- :feature:`orga:submission` The proposal list can now be sorted by session type and track.
+- :feature:`cfp` Organisers can now turn off the public “secret” proposal share URLs.
+- :bug:`cfp` On some registration pages, the password strength indicator was missing.
+- :announcement:`dev` pretalx has dropped its use of SCSS, Bootstrap (while retaining a lot of style rules) and jQuery. If you rely on these in your plugin, you will need to adjust your code. If you require jQuery, you can load `static/js/jquery.js`, as this is still shipped with pretalx core. You can continue using SCSS, but you'll have to use CSS variables rather than SCSS variables, but we do expose all previous SCSS variables as CSS variables.
+- :feature:`admin` pretalx is now better about deleting uploaded files that are not in use anymore, as well as giving predictable filenames to user profile pictures.
 - :bug:`orga` Deleting review phases and review score categories was broken.
+- :feature:`schedule` The schedule navigation to switch between schedule, talk list, and speakers, is now always visible and easier to find.
+- :feature:`orga` Organisers can now open the quick-nav menu with the Alt-K shortcut.
+- :feature:`orga` In order to make the many settings pages more manageable, they are now grouped into tabs.
+- :feature:`orga` Whenever users can select an item associated with a colour (e.g. a track, an event), the colour is also shown in the drop-down.
+- :feature:`orga` On the landing page in the organiser area, there are now links to the events the current user has submitted proposals to, in order to help guide speakers back to the speaker frontend from the (to-them empty) organiser backend.
+- :feature:`orga` There is now an organiser-level dashboard with an events list and team list.
 - :feature:`schedule` The schedule page makes even better use of several caching methods in order to be smaller and faster to load and re-load.
-- :announcement:`admin` Due to a potentially tricky update in Django, and maintenance cost, pretalx is dropping support for MySQL/MariaDB. Please use either PostgreSQL or SQLite. If you are currently running MySLQ.
+- :announcement:`admin` The ``regenerate_css`` command has been dropped without replacement, as it was not needed anymore.
+- :announcement:`admin` Due to a potentially tricky update in Django, and maintenance cost, pretalx is dropping support for MySQL/MariaDB. Please use either PostgreSQL or SQLite. If you are currently running MySLQ, please take a look at this exemplary `MySQL migration guide<https://pretix.readthedocs.io/en/latest/admin/mysql2postgres.html>`_ by the pretix project **BEFORE** starting your pretalx update, in order to migrate your data with ``pgloader`` to PostgreSQL!
 - :announcement:`admin` pretalx now requires Python 3.10 or newer.
 - :feature:`orga` Organisers now have access to a list of all speakers / submitters for all of their events.
-- :bug:`orga:schedule,1828` When exporting an event to a HTML export, files with umlauts or other non-ascii characters in their file name were saved with the encoded version of that name, so when the export was served by a webserver, these files wouldn't be shown.
+- :bug:`orga:schedule,1828` When exporting an event to a HTML export, files with umlauts or other non-ASCII characters in their file name were saved with the encoded version of that name, so when the export was served by a web server, these files wouldn't be shown.
 - :bug:`schedule` When organisers initially asked speakers to upload a profile picture, but then turned off the upload, the profile pictures collected to that date would still show up in the schedule grid and on the individual speaker pages. They will now be hidden from view.
 - :bug:`orga` Organisers could inadvertently remove all access to an event when they updated their team permissions. Pretalx now forbids this, and additionally shows warnings when an event is being orphaned by a team change.
 - :feature:`orga` A lot of info boxes that are mostly useful to new or inexperienced users are now hidden behind ❓ symbols rather than being always visible.
@@ -18,6 +40,7 @@ Release Notes
 - :bug:`orga` When copying an old event's settings to a new one, questions were copied, but their answer options (for choice/multiple choice questions) were omitted.
 - :bug:`orga:email` When sending an email to only speakers with a specific question answer, emails would instead be generated (and placed in the outbox, not sent!) to all speakers.
 - :bug:`orga:submission` When organisers filtered the session list by specific question answers, adding search terms or filters would reset the question filter.
+- :bug:`schedule` When the pretalx schedule widget was used with an event that didn't have a public schedule, it would show a loading spinner indefinitely. It now shows a message that the schedule is not available.
 - :feature:`schedule,1002` Logged-in users can now download an iCal file with their starred talks.
 - :feature:`schedule` For logged in users, pretalx will now save the list of starred/favourited talks, so that you can sync the starred talks across devices.
 - :feature:`schedule` If a talk won't be recorded, this will now be shown in the schedule, rather than just on the individual talk pages.

doc/developer/plugins/plugins.rst

@@ -14,9 +14,11 @@ The communication between pretalx and the plugins happens using Django’s
 `signal dispatcher`_ feature. The core modules of pretalx expose signals which
 you can read about on the next pages.
 
+.. highlight:: console
+
 To create a new plugin, create a new python package which must be a valid
-`Django application`_ and must contain plugin meta-data, as described below.
-You will need some boilerplate for every plugin to get started. To save your
+`Django application`_ and must contain plugin metadata, as described below.
+You will need some boilerplate for every plugin to get started. To save you
 time, we created a `cookiecutter`_ template that you can use like this::
 
    (env)$ pip install cookiecutter
@@ -29,7 +31,8 @@ Afterwards install your plugin into pretalx::
    (env)$ python -m pip install -e .
 
 If you already had it running, you’ll now have to restart your pretalx
-development server process for it to recognise the new plugin.
+development server process for it to recognise the new plugin. Your plugin
+should now show up in the startup message the server prints to the console.
 
 About this Documentation
 ------------------------
@@ -39,11 +42,11 @@ supported. While these instructions don’t assume that you know a lot about
 pretalx, they do assume that you have prior knowledge about Django (e.g. its
 view layer, how its ORM works, topics covered in the Django tutorial.).
 
-Plugin meta-data
+Plugin metadata
 ----------------
 
-The plugin meta-data lives inside a ``PretalxPluginMeta`` class inside your
-configuration class. The meta-data class must define the following attributes:
+The plugin metadata lives inside a ``PretalxPluginMeta`` class inside your
+configuration class. The metadata class must define the following attributes:
 
 .. rst-class:: rest-resource-table
 
@@ -52,17 +55,22 @@ Attribute          Type                 Description
 ================== ==================== ===========================================================
 name               string               The human-readable name of your plugin
 author             string               Your name
-version            string               A human-readable version code of your plugin
+version            string               A human-readable version code of your plugin. If you publish your
+                                        plugin on PyPI, this should match the package version.
 description        string               A more verbose description of what your plugin does.
 category           string               A category for your plugin, used to group it in the plugin list.
                                         Supported categories are ``FEATURE``, ``INTEGRATION``, ``CUSTOMIZATION``,
                                         ``EXPORTER``, ``RECORDING``, ``LANGUAGE``, ``OTHER`` (default).
+visible            bool                 Defaults to ``True``. Setting it to ``False`` will hide the plugin
+                                        from the plugin list in the event settings.
 ================== ==================== ===========================================================
 
+.. highlight:: python
+
 A working example would be::
 
     from django.apps import AppConfig
-    from django.utils.translation import ugettext_lazy as _
+    from django.utils.translation import gettext_lazy as _
 
 
     class FacebookApp(AppConfig):
@@ -74,7 +82,6 @@ A working example would be::
             author = _("the pretalx team")
             version = "1.0.0"
             visible = True
-            restricted = False
             description = _("This plugin allows you to post talks to facebook.")
             category = "INTEGRATION"
 
@@ -84,29 +91,33 @@ A working example would be::
 Plugin registration
 -------------------
 
+.. highlight:: toml
+
 Somehow, pretalx needs to know that your plugin exists at all. For this purpose, we
 make use of the `entry point`_ feature of setuptools. To register a plugin that lives
 in a separate python package, your ``pyproject.toml`` should contain something like this::
 
-
     [project.entry-points."pretalx.plugin"]
     pretalx_facebook = "pretalx_facebook:PretalxPluginMeta"
 
 
 This will automatically make pretalx discover this plugin as soon as you have
 installed it e.g.  through ``pip``. During development, you can run ``pip
 install -e .`` inside your plugin source directory to make it discoverable.
+Make sure you do this in the same virtualenv as you're using for pretalx.
 
 Signals
 -------
 
+.. highlight:: python
+
 pretalx defines signals which your plugin can listen for. We will go into the
 details of the different signals in the following pages. We suggest that you
 put your signal receivers into a ``signals`` submodule of your plugin. You
 should extend your ``AppConfig`` (see above) by the following method to make
 your receivers available::
 
-    class PaypalApp(AppConfig):
+    class FacebookApp(AppConfig):
 
         def ready(self):
             from . import signals  # noqa
@@ -115,7 +126,7 @@ You can optionally specify code that you want to execute when the organiser
 activates your plugin for an event in the ``installed`` method, and code to
 execute upon removal in the ``uninstalled`` method::
 
-    class PaypalApp(AppConfig):
+    class FacebookApp(AppConfig):
 
         def installed(self, event):
             pass  # Your code here
@@ -125,7 +136,26 @@ execute upon removal in the ``uninstalled`` method::
 
 The ``AppConfig`` class may also implement the method ``is_available(event)``
 which checks if a plugin is available for a specific event. If not, it will not
-be shown on the plugin list for that event, and cannot be enabled.
+be shown on the plugin list for that event, and cannot be enabled. This method
+is not called on plugins with ``visibility=False``, as those are already
+hidden.
+
+Models
+------
+
+Often, you’ll want to store additional data in your plugin. As your plugin is a
+Django application, you can define models in the usual way, and generate
+migrations for them, by running ``python -m pretalx makemigrations``. Your
+migrations will be applied when running ``python -m pretalx migrate`` just like
+any other migration.
+
+.. highlight:: console
+
+Please note that to generate your **first** migration, you will have to specify
+your plugin’s app name explicitly in order for Django to pick it up, like
+this::
+
+    python -m pretalx makemigrations pretalx_facebook
 
 Views
 -----
@@ -135,16 +165,22 @@ plugin module, pretalx will automatically import it and include it into the root
 URL configuration with the namespace ``plugins:<label>:``, where ``<label>`` is
 your Django application label.
 
+You can see examples of how this works on the following pages, particularly
+the “Writing a … plugin” pages.
+
 .. note:: We recommend that non-backend-URLs start with a /p/ to avoid collisions
-   with event names.
+   with event names and current/future pretalx URLs.
 
 .. WARNING:: If you define custom URLs and views, you are on your own
    with checking that the calling user has logged in, has appropriate permissions,
-   and more. We plan on providing native support for this in a later version.
+   and more. You can use mixins and permissions from pretalx to help you with this,
+   but by default, all views are public to all users, authenticated or not.
 
 Configuration
 -------------
 
+.. highlight:: ini
+
 Occasionally, your plugin may need system-level configuration that does not
 need its own API. In this case, you can ask users to provide this configuration
 via their ``pretalx.cfg`` file. Ask them to put their configuration in a
@@ -155,6 +191,8 @@ provide in ``settings.PLUGIN_SETTINGS[your_plugin_name]``, like this::
    endpoint=https://example.com
    api_key=123456
 
+.. highlight:: python
+
 Which you can use in your code like this::
 
    from django.conf import settings

doc/maintainer/release.rst

@@ -48,3 +48,4 @@ Take-off and landing
 14. Update any plugins waiting for the new release.
 15. Check if the docker image build was successful.
 16. Post about the release on ``chaos.social``, Twitter and LinkedIn.
+17. Notify interested parties (e.g. big self-hosted instances, prominent plugin developers) about the release.

doc/spelling_wordlist.txt

@@ -16,8 +16,10 @@ browsable
 canceled
 categorys
 ccc
+center
 CfP
 changelog
+color
 config
 cron
 cronjob
@@ -55,6 +57,7 @@ installable
 integrations
 iterable
 Jorian
+jQuery
 libffi
 lightbox
 linters
@@ -64,7 +67,9 @@ lossy
 makemessages
 middleware
 mixin
+mixins
 namespace
+nav
 nginx
 nodejs
 noopener
@@ -74,10 +79,13 @@ plugins
 prepend
 prepended
 pretalx
+pretix
+px
 pytest
 queryset
 redis
 ro
+scrollbar
 slugified
 stdout
 strikethrough
@@ -90,6 +98,7 @@ subpath
 subtractive
 systemd
 templating
+textboxes
 transactional
 txt
 typeahead

pyproject.toml

@@ -29,32 +29,31 @@ dependencies = [
   "celery~=5.4.0",
   "css_inline~=0.14.0",
   "csscompressor~=0.9.0",
-  "cssutils~=2.10.0",
+  "cssutils~=2.11.0",
   "defusedcsv~=2.0.0",
   "defusedxml~=0.7.0",
   "Django[argon2]~=5.1.0",
-  "django-bootstrap4~=3.0.0",
   "django-compressor~=4.5.0",
   "django-context-decorator",
   "django-countries~=7.0",
   "django-csp~=3.8.0",
-  "django-filter==24.2",
+  "django-filter==24.3",
   "django-formset-js-improved==0.5.0.3",
   "django-formtools~=2.5.1",
-  "django-hierarkey~=1.1.0",
+  "django-hierarkey~=1.2.0",
   "django-i18nfield~=1.9.0",
   "django-libsass~=0.8",
   "django-scopes~=2.0.0",
   "django-pdb~=0.6.2",
   "djangorestframework~=3.15.0",
   "libsass~=0.23.0",
-  "Markdown~=3.6.0",
-  "Pillow~=10.3.0",
-  "publicsuffixlist~=0.10.0",
+  "Markdown~=3.7.0",
+  "Pillow~=11.0.0",
+  "publicsuffixlist~=1.0.0",
   "python-dateutil~=2.9.0",
-  "qrcode~=7.0",
+  "qrcode~=8.0",
   "reportlab~=4.2.0",
-  "requests~=2.31.0",
+  "requests~=2.32.0",
   "rules~=3.5.0",
   "urlman~=2.0.1",
   "vobject~=0.9.0",
@@ -85,7 +84,6 @@ dev = [
   "isort",
   "jsonschema",
   "lxml",
-  "pep8-naming",
   "pytest",
   "pytest-cov",
   "pytest-django",
@@ -95,11 +93,10 @@ dev = [
   "pytest-xdist",
   "pywatchman",
   "responses",
-  "rich",
   "urllib3",
 ]
 postgres = ["psycopg2-binary~=2.9.0"]
-redis = ["redis~=5.0.0"]
+redis = ["redis~=5.1.0"]
 
 [build-system]
 build-backend = "setuptools.build_meta"

src/pretalx/__init__.py

@@ -1 +1 @@
-__version__ = "2024.3.0.dev0"
+__version__ = "2024.4.0.dev0"