How to customize the settings to suit your needs. Do this in local_settings so patches and upstream pulls don’t cause havoc to your installation
Used to control the URL for the admin in production.
Used to create the name of the site.
Used to determine how packages have extended data sets. See package_extenders
In the case of Django Packages, autocomplete searches for something like ‘forms’ was problematic because so many packages start with ‘django’. The same will hold for searches in Python Packages and Pyramid Packages. This prefix is accommodated in searches to prevent this sort of problem.
example:
PACKAGINATOR_SEARCH_PREFIX = 'pyramid'
Used in the Package add/edit form in both the admin and the UI, these are assigned to model form help text arguments. Takes a dict of the following items:
Example (also the default):
PACKAGINATOR_HELP_TEXT = {
"REPO_URL" : "Enter your project repo hosting URL here.<br />Example: https://bitbucket.org/ubernostrum/django-registration",
"PYPI_URL" : "<strong>Leave this blank if this package does not have a PyPI release.</strong><br />What PyPI uses to index your package. <br />Example: django-registration"
}
The launchpad Python client tool requires an unbelievable amount of requirements to handle a simple JSON ReST based webservice. These requirements can be tricky to install. Therefore, OpenComparison out of the box does not support Launchpad.
Warning
Launchpad hasn’t been tested or maintained in a while. This probably won’t work at this time.
If you have problems, please refer to troubleshooting.
If you want your instance of OpenComparison to support Launchpad, set this setting to true in local_settings.py:
LAUNCHPAD_ACTIVE = True
Used to point LAUNCHPAD commands against the appropriate cache. Important in real hosting machines.
Example:
LAUNCHPAD_CACHE_DIR = "/tmp/lp-cache"
OpenComparison provides several ways to control who can make what changes to things like packages, features, and grids. By default, a OpenComparison project is open to contributions from any registered user. If a given project would like more control over this, there are two settings that can be used.
RESTRICT_PACKAGE_EDITORS RESTRICT_GRID_EDITORS
If these are not set, the assumption is that you do not want to restrict editing.
If set to True, a user must have permission to add or edit the given object. These permissions are set in the Django admin, and can be applied per user, or per group.
By default registered users can do the following:
Packages
Grids
In the default condition, only super users or those with permission can delete.
A context processor will add the user profile to every template context, the profile model also handles checking for permissions:
{% if profile.can_edit_package %}
<edit package UI here>
{% endif %}
The follow properties can be used in templates: