summaryrefslogtreecommitdiff
path: root/patchwork/settings
Commit message (Collapse)AuthorAge
...
* settings: Add PASSWORD_HASHERStephen Finucane2016-08-13
| | | | | | | This improves run time by a few seconds, and is worth having. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Tested-by: Andy Doan <andy.doan@linaro.org>
* settings: Regroup sections per upstream docsStephen Finucane2016-08-13
| | | | Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* REST: Add Projects to the APIAndy Doan2016-06-27
| | | | | | | | | | | | | | This exports projects via the REST API. Security Constraints: * Anyone (logged in or not) can read all objects. * No one can create/delete objects. * Project maintainers are allowed to update (ie "patch" attributes) Signed-off-by: Andy Doan <andy.doan@linaro.org> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Inspired-by: Damien Lespiau <damien.lespiau@intel.com>
* REST: Add base configuration hooks for a REST APIAndy Doan2016-06-27
| | | | | | | | | | | This adds the ability to expose a REST API based on the Django REST framework project. Since this project isn't packaged in most current distributions, we ensure that its both installed and enabled before trying to use it. Signed-off-by: Andy Doan <andy.doan@linaro.org> Inspired-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Stephen Finucane <stephen.finucane@intel.com>
* pep8: Resolve issues in settings fileStephen Finucane2016-04-08
| | | | | | Introduced in '2822854'. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Remove hard coded login url valueMichael Wood2016-04-08
| | | | | | | | | Use the url name for the login page rather than a hard coded value this means that if you have patchwork in a prefix it will redirect to the correct location without any additional configuration. Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* models: Split Patch into two modelsStephen Finucane2016-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a lot of similarities between cover letters and patches: so many, in fact, that it would be helpful to occasionally treat them as the same thing. Achieve this by extracting out the fields that would be shared between a Patch and a hypothetical cover letter into a "sub model". This allows us to do cool stuff like assigning comments to both patches and cover letters or listing both patches and cover letters on the main screen in a natural way. The migrations for this are really the only complicated part. There are three, broken up into schema and data migrations per Django customs, and they works as follows: * Rename the 'Patch' model to 'Submission', then create a subclass called 'Patch' that includes duplicates of the patch-specific fields of Submission (with changed names to prevent conflicts). Rename non-patch specific references to the renamed 'Submission' model as necessary. * Duplicate the contents of the patch-specific fields from 'Submission' to 'Patch' * Remove the patch-specific fields from 'Submission', renaming the 'Patch' model to take their place. Update the patch-specific references to point the new 'Patch' model, rather than 'Submission'. This comes at the cost of an additional JOIN per item on the main screen, but this seems a small price to pay for the additional functionality gained. To minimise this, however, caching will be added. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Signed-off-by: Andy Doan <andy.doan@linaro.org>
* settings: Help caching with content-aware static file namesDamien Lespiau2016-04-01
| | | | | | | | | | | | | | | | If we always serve the "style.css" file, even when its content changes, we run into the situation where the browser (or any HTTP aware middle man) will cache the file and not download a newer version. This can be solved by appending the file hash to its filename. If the content changes, the file name changes and the new version is used right away. We can also use far future Expires headers with such static files, they will really never change. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> --- v2: Disable for Django < 1.7
* settings: Enable the 'message' applicationStephen Finucane2016-03-25
| | | | | | | | Most of the configuration is already done: only the application itself needs to be enabled. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Tested-by: Andy Doan <andy.doan@linaro.org>
* context: Add 'site' context processorStephen Finucane2016-03-25
| | | | | | | | | | | This allows us to use the current "site" value in all templates without requiring PatchworkRequestContext. As a custom context processor is being enabled, the 'TEMPLATE_CONTEXT_PROCESSORS' value must be specified for versions of Django < 1.8 (it's already specified for other versions). Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Tested-by: Andy Doan <andy.doan@linaro.org>
* settings: Use explicit setup for the Debug ToolbarStephen Finucane2016-03-24
| | | | | | | | | | | | | | | | | The 'django-debug-toolbar' application provides an automatic method of configuring the plugin. However, as noted in the documentation [1], this can cause issues like circular imports. In this case, a "Table 'patchwork.patchwork_state' doesn't exist" exception was being raised when attempting to do an initial migration. Resolve this by using the manual configuration provided in the docs. [1] https://django-debug-toolbar.readthedocs.org/en/1.4/installation.html Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Closes-bug: #29 --- v2: Don't rely on 'settings.DEBUG', as this is set to False in tests
* settings: Disable Debug Toolbar for all Django<1.7Stephen Finucane2016-03-24
| | | | | | | | The django-debug-toolbar project doesn't support Django 1.6, but the check used to disable this plugin for this version only works for Django 1.6.0 and less. Enable it for all versions of Django < 1.7. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Add support for 'django-debug-toolbar'Stephen Finucane2016-03-15
| | | | | | | | | | | | This tool is exceptionally helpful for debugging issues with Django: install it as part of the 'dev' configuration. This only works on Django > 1.6, due to a lack of support for older versions in the upstream. A note is included to help users avoid the issues seen when running patchwork on a different machine. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Don't use 'postgre'Damien Lespiau2016-03-08
| | | | | | | | | | From: https://wiki.postgresql.org/wiki/Postgres#Changing_name_from_PostgreSQL_to_Postgres "Does not encourage weird derivations such as 'Postgre'" Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Use environment variables by defaultStephen Finucane2016-02-14
| | | | | | | | | | | | | | The Django documentation suggests using environment variables as a way to allow devs to commit settings files via source control without including confidential information therein [1]. As such, change the provided 'production' settings to do this. This should promote best practices while also ensuring provisioning tools like 'ansible-django-stack' [2] work as expected. [1] https://docs.djangoproject.com/en/1.9/howto/deployment/checklist/ [2] https://github.com/jcalazan/ansible-django-stack Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Place most-used path firstStephen Finucane2016-01-19
| | | | | | | Make the settings file a little easier to parse by placing the most used (i.e. the one used with recent versions of Django) first. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Add TEMPLATES settingStephen Finucane2016-01-19
| | | | | | | | This was added in Django 1.8 and will be required by Django 1.10. https://docs.djangoproject.com/en/1.9/ref/templates/upgrading/#the-templates-settings Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* pep8: Manually resolve remaining issuesStephen Finucane2015-12-03
| | | | | | | | | | | | | | | | The 'autopep8' tool can't do everything, and it is necessary to resolve some final issues. Most of these issues fall under the following categories: E501 line too long E241 multiple spaces after ',' F401 'module' imported but unused F841 local variable 'name' is assigned to but never used It is also necessary to insert '# noqa' comments to hide some F403 errors ('unable to detect undefined names') where 'import *' is useful. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* pep8: Autoresolve most PEP8 issuesStephen Finucane2015-12-03
| | | | | | ...using the 'autopep8' tool. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* py3: Add required 'future' importsStephen Finucane2015-12-03
| | | | | | | | | | These are quite limited as patchwork only supports Python 2.6+. As such, only the 'print_function' and 'absolute_import' statements are required. Found using 'modernize' Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Add console email backendStephen Finucane2015-11-21
| | | | | | | | Requiring configuration of an email server and email recipients for debugging of email-based features is impractical. Use the console backend provided by Django as the development default. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Rework configurable 'PW_TEST_DB_xxx' settingsStephen Finucane2015-11-21
| | | | | | | | | | | | | There are a number of environment variables that users can set to configure different aspects of their testing environment. Rework these like so: * People use PostgreSQL, so make it as easy as possible for them to develop and test against it. Add a 'PW_TEST_DB_TYPE' setting * Attempt to use defaults for the username and password in settings * Allow the user to configure the database name, if they so wish Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Revert "Remove Django < 1.7 blocks"Stephen Finucane2015-11-07
| | | | | | | This reverts commit ea050ad02c61ff1f0bd03ffb02b4706817401aee. To allow patchwork deployment on Enterpise versions of Linux, it is necessary to continue to support Django 1.6.
* templates/patch: Add check summary panelStephen Finucane2015-11-05
| | | | | | | | | | | Add a table to display the checks associated with a patch. This includes the requisite styling along with some additional filters. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> -- v3: Slight restyling per web UI rework
* Remove Django < 1.7 blocksStephen Finucane2015-11-05
| | | | | | | Seeing as we no longer support these versions of Django, there is no need to keep these blocks around. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Also define SERVER_EMAIL for email logsDamien Lespiau2015-11-05
| | | | | | | | | | | | Django can send emails to admins on 500 HTTP errors when DEBUG is false. That looks handy. That mechanism uses SERVER_EMAIL for the From: address, which defaults to root@localhost and can cause problems in the email delivery. Use the same address than DEFAULT_FROM_EMAIL by default. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Move DEFAULT_FROM_EMAIL to the core settings sectionDamien Lespiau2015-11-05
| | | | | | | | | DEFAULT_FROM_EMAIL is actually a django setting, not a patchwork one. v2: Capitalize the 'E' of 'Email' (Stephen Finucane) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Stephen Finucane <stephen.finucane@intel.com>
* settings: Move 'TEST_RUNNER' to correct locationStephen Finucane2015-09-17
| | | | | | | | | Try to keep the order/structure of this file intact for as long as possible. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
* settings: Fix deprecated 'TEST_CHARSET' warningStephen Finucane2015-09-17
| | | | | | | | Resolve a 'RemovedInDjango19Warning' with the 'TEST_CHARSET' option. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
* docs: Rewrite documentationStephen Finucane2015-09-17
| | | | | | | | | | | | | | | | | | | | | | | | | | The INSTALL and HACKING documents are an important guide for new patchwork users and developers and should be as informative as possible. A number of changes were needed to these documents owing to the out-of-date or incomplete information they contained. These changes include: * Removing references to the dead mod_python/flup projects * Adding references to Gunicorn+nginx, which a credible modern alternative to Apache+mod_wsgi * Providing explanatory links to concepts/tools like ident-based authentication and tox * Referencing the newer tools available to developers, like tox and the 'requirements.txt' files * Integration with mkdocs, with eye on eventual publishing of documentation to ReadTheDocs or equivalent. These changes result in a significant rewrite which should hopefully lower the barrier to entry for people wishing to use or develop patchwork. Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
* tests: Remove old-style test runner moduleJeremy Kerr2015-05-28
| | | | | | | | | | | | | | | We get the following warning on django 1.7: System check identified some issues: WARNINGS: ?: (1_6.W001) Some project unittests may not execute as expected. HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using Django 1.5 or earlier. You should ensure your tests are all running & behaving as expected. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information. This change removes the unneeded base test module, and moves the patchparser doctests into a proper test module. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
* Update documentation and default settings to suit patchwork deployment modelJeremy Kerr2015-05-28
| | | | | | | | | | | | We've always allowed configuration without altering any of the version-controlled files. With the recent settings changes, we have an extra level of indirection with the dev/prod settings modules. Since we have to edit a config file anyway, this change moves the prod.py settings file to a template, which is then used directly by mange.py (and the wsgi application). Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
* Move to a more recent django project structureJeremy Kerr2015-05-27
This change updates patchwor to the newer project struture: we've moved the actual application out of the apps/ directory, and the patchwork-specific templates to under the patchwork application. This gives us the manage.py script in the top-level now. Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
generated by cgit v1.2.3 (git 2.25.4) at 2024-06-28 07:51:07 +0000