Mercurial > p > roundup > code
view doc/tracker_templates.txt @ 7211:506c86823abb
Add config argument to more password.Password invocations.
The work done to allow password_pbkdf2_default_rounds to be overridden
for testing requires that calls to password.Password include a config
argument.
This was needed because using the real value more than quadrupled
testing runtime.
However there are still a few places where config was not being set
when Password was called. I think this fixes all of the ones that are
called from a function that have access to a db.config object.
The remaining ones all call Password(encrypted=x). This results in
Password.unpack() being called. If x is not a propertly formatted
password string ("{scheme}...", it calls encodePassword. It then
should end up raising the ConfigNotSet exception. This is
probably what we want as it means the shape of "x" is not correct.
I don't understand why Password.unpack() attempts to encrypt the value
of encrypted if it doesn't match the right form. According to codecov,
this encryption branch is being used, so somewhere x is of the wrong
form. Hmmm....
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sat, 04 Mar 2023 00:17:26 -0500 |
| parents | 00fe67eb8a91 |
| children | 6985f0ff3df3 |
line wrap: on
line source
========================= Roundup Tracker Templates ========================= The templates distributed with Roundup are stored in the "share" directory nominated by Python. On Unix this is typically ``/usr/share/roundup/templates/`` (or ``/usr/local/share...``) and on Windows this is ``c:\python27\share\roundup\templates\``. The template loading looks in four places to find the templates: 1. *share* - eg. ``<prefix>/share/roundup/templates/*``. This should be the standard place to find them when Roundup is installed running setup.py from source. 2. ``install_dir``/../<prefix>/share/....``, where prefix is the Python's ``sys.prefix``. ``sys.base_prefix`` or `sys.base_prefix/local``. This finds templates (and locales) installed by pip. E.G. in a virtualenv located at (``sys.prefix``): ``/tools/roundup``, roundup would be at: ``/tools/roundup/lib/python3.6/site-packages/roundup``. The templates would be at: ``/tools/roundup/lib/python3.6/site-packages/tools/roundup/share/roundup/templates/``. 3. ``<roundup.admin.__file__>/../../share/roundup/templates/*``. This will be used if Roundup's run in the distro (aka. source) directory. 4. ``<current working dir>/*``. This is for when someone unpacks a 3rd-party template. 5. ``<current working dir>``. This is for someone who "cd"s to the 3rd-party template dir. Templates contain: - modules ``schema.py`` and ``initial_data.py`` - directories ``html``, ``detectors`` and ``extensions`` (with appropriate contents) - optional ``config_ini.ini`` file. It is structured like a tracker's ``config.ini`` but contains only headers (e.g. ``[main]``) and *required* parameters that are different from defaults: e.g. ``template_engine = jinja2`` and ``static_files = static``. These settings override the default values saved to the tracker's ``config.ini``. - template "marker" file ``TEMPLATE-INFO.txt``, which contains the name of the template, a description of the template and its intended audience. An example TEMPLATE-INFO.txt:: Name: classic Description: This is a generic issue tracker that may be used to track bugs, feature requests, project issues or any number of other types of issues. Most users of Roundup will find that this template suits them, with perhaps a few customisations. Intended-For: All first-time Roundup users