Mercurial > p > roundup > code
view doc/tracker_templates.txt @ 7723:8147f6deac9f
fix(db): Make using pg_service work again.
When I did the merge of schema support I broke pg_service.conf support
by replacing get_database_name with db_schema_split. This commit
fixes it.
Also this commit returns the schema if one is specified in
pg_service.conf.
back_postgresql.py:
Replace calls to db_schema_split() with get_database_schema_names()
(new name for get_database_name()). Rename db_schema_split to
_db_schema_split. It now returns a tuple (dbname, schema) rather
than a list. It is used only by get_database_schema_names() which
also returns tuples.
get_database_schema_names() can also get schema info for the service
(if present) as specified by pg_service.conf.
Add get_database_user() to get the user from either RDBMS_USER or
pg_service.conf. (User needed for creating schema, so not needed
before schema patch.
import re at the top of file and remove lower import.
Remove some schema code from db_command as it's not needed. The
database conection is done to either postgresql or template1
existing databases. This command never connects to the roundp
specified db.
test/test_postgresql.py:
Reorganize top level imports, add import os. Replace import of
db_schema_split with get_database_schema_names. Also replace calls
to db_schema_split.
Create new Opener for the service file. Set PGSERVICEFILE to point
to test/pg_service.conf.
Add three new classes to test Service:
1) using regular db
2) using schema within db
3) Unable to parse schema name from pg_service.conf.
The last doesn't need a db. Number 1 and 2 reuse the tests in ROTest
to verify db connectivity.
test/pg_service.conf:
three service connections for: db only, db and schema, and incorrectly
specified schema test cases.
doc/upgrading.txt:
updated to current status. Included example schema definition in
service file.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 28 Dec 2023 15:13:42 -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
