Mercurial > p > roundup > code
view doc/glossary.txt @ 8180:d02ce1d14acd
feat: issue2551068 - Provide way to retrieve file/msg data via rest endpoint.
Use Allow header to change format of /binary_content endpoint. If
Allow header for endpoint is not application/json, it will be matched
against the mime type for the file. */*, text/* are supported and will
return the native mime type if present.
Changes:
move */* mime type from static dict of supported types. It was
hardcoded to return json only. Now it can return a matching
non-json mime type for the /binary_content endpoint.
Edited some errors to explicitly add */* mime type.
Cleanups to use ', ' separation in lists of valid mime types rather
than just space separated.
Remove ETag header when sending raw content. See issue 2551375 for
background.
Doc added to rest.txt.
Small format fix up (add dash) in CHANGES.txt.
Make passing an unset/None/False accept_mime_type to
format_dispatch_output a 500 error. This used to be the fallback
to produce a 406 error after all processing had happened. It
should no longer be possible to take that code path as all 406
errors (with valid accept_mime_types) are generated before
processing takes place.
Make format_dispatch_output handle output other than json/xml so it
can send back binary_content data.
Removed a spurious client.response_code = 400 that seems to not be
used.
Tests added for all code paths.
Database setup for tests msg and file entry. This required a file
upload test to change so it doesn't look for file1 as the link
returned by the upload. Download the link and verify the data
rather than verifying the link.
Multiple formatting changes to error messages to make all lists of
valid mime types ', ' an not just space separated.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sun, 08 Dec 2024 17:22:33 -0500 |
| parents | 1a912887d704 |
| children | b4dfc68b7067 |
line wrap: on
line source
.. meta:: :description: Definitions of terms used in the Roundup Issue Tracker documentation. Referenced by other documents. ================ Roundup Glossary ================ .. glossary:: :sorted: class a definition of the properties and behavior of a set of items classname the name of a class. It must start with a letter, end with a letter or "_", and only have alphanumerics and "_" in the middle. db database used to store the data in the tracker. Roundup supports 4 databases: dbm (Berkeley DB/BDB), SQLite, PostgreSQL, MySQL/MariaDB. definitional class a class that exists to define a discrete set of values. For example status or priority. designator a combined :term:`classname` + :term:`itemid` reference to any item in the hyperdb. E.g. ``issue26``. Note that form values can include something that looks like a designator composed of a classname, a dash '-', and a number. E.g. ``file-1``. These are used to create new instances of a class via the web interface. hyperdb a software layer between the user and the underlying :term:`db`. It is responsible for mutating the underlying db when the schema changes. It also executes the detectors when items in the db change. item a collection of data that forms one entry in the hyperdb. itemid an integer reference to a particular item of one class. Internally it is stored as a string and not an integer number. This results in a string not numeric sort by id in some circumstances. property one element of data that makes up an item. In Roundup, the set of item properties may be changed as needed - even after the tracker has been initialized and used in production. schema the definition of all the classes and properties that make up a tracker. Contained in the file ``schema.py``. The permissions for the schema items are usually defined in the same file. tracker the schema and hyperdb that forms one issue tracker tracker home the physical location on disk of a tracker. It has the ``config.ini``, ``schema.py`` files for the tracker. ----------------- Back to `Table of Contents`_ .. _`Table of Contents`: ../docs.html