Mercurial > p > roundup > code
view doc/features.txt @ 5710:0b79bfcb3312
Add support for making an idempotent POST. This allows retrying a POST
that was interrupted. It involves creating a post once only (poe) url
/rest/data/<class>/@poe/<random_token>. This url acts the same as a
post to /rest/data/<class>. However once the @poe url is used, it
can't be used for a second POST.
To make these changes:
1) Take the body of post_collection into a new post_collection_inner
function. Have post_collection call post_collection_inner.
2) Add a handler for POST to rest/data/class/@poe. This will return a
unique POE url. By default the url expires after 30 minutes. The
POE random token is only good for a specific user and is stored in
the session db.
3) Add a handler for POST to rest/data/<class>/@poe/<random token>.
The random token generated in 2 is validated for proper class (if
token is not generic) and proper user and must not have expired.
If everything is valid, call post_collection_inner to process the
input and generate the new entry.
To make recognition of 2 stable (so it's not confused with
rest/data/<:class_name>/<:item_id>), removed @ from
Routing::url_to_regex.
The current Routing.execute method stops on the first regular
expression to match the URL. Since item_id doesn't accept a POST, I
was getting 405 bad method sometimes. My guess is the order of the
regular expressions is not stable, so sometime I would get the right
regexp for /data/<class>/@poe and sometime I would get the one for
/data/<class>/<item_id>. By removing the @ from the url_to_regexp,
there was no way for the item_id case to match @poe.
There are alternate fixes we may need to look at. If a regexp matches
but the method does not, return to the regexp matching loop in
execute() looking for another match. Only once every possible match
has failed should the code return a 405 method failure.
Another fix is to implement a more sophisticated mechanism so that
@Routing.route("/data/<:class_name>/<:item_id>/<:attr_name>", 'PATCH')
has different regexps for matching <:class_name> <:item_id> and
<:attr_name>. Currently the regexp specified by url_to_regex is used
for every component.
Other fixes:
Made failure to find any props in props_from_args return an empty
dict rather than throwing an unhandled error.
Make __init__ for SimulateFieldStorageFromJson handle an empty json
doc. Useful for POSTing to rest/data/class/@poe with an empty
document.
Testing:
added testPostPOE to test/rest_common.py that I think covers
all the code that was added.
Documentation:
Add doc to rest.txt in the "Client API" section titled: Safely
Re-sending POST". Move existing section "Adding new rest endpoints" in
"Client API" to a new second level section called "Programming the
REST API". Also a minor change to the simple rest client moving the
header setting to continuation lines rather than showing one long
line.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sun, 14 Apr 2019 21:07:11 -0400 |
| parents | 3e1b66c4e1e2 |
| children | e48b039b0ec0 |
line wrap: on
line source
================ Roundup Features ================ Roundup is a simple-to-use and -install issue-tracking system with web, e-mail and command-line interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. *simple to install* - installation (including web interface) takes about 30 minutes - instant-gratification ``python demo.py`` :) - two templates included in the distribution for you to base your tracker on - play with the demo, customise it and then use *it* as the template for your production tracker - requires *no* additional support software - python (2.7 or 3.4+) is enough to get you going - easy to set up higher-performance storage backends like sqlite_, mysql_ and postgresql_ *simple to use* - accessible through the web, email, command-line or Python programs - may be used to track bugs, features, user feedback, sales opportunities, milestones, ... - automatically keeps a full history of changes to issues with configurable verbosity and easy access to information about who created or last modified *any* item in the database - issues have their own mini mailing list (nosy list) - users may sign themselves up, there may be automatic signup for incoming email and users may handle their own password reset requests *highly configurable* - web interface HTML is fully editable - database schema is also fully editable (only the "user" class is required) with a full set of data types (including dates and many-to-many relations) across all storages available - customised automatic auditors and reactors may be written that perform actions before and after changes are made to entries in the database, or may veto the creation or modification of items in the database - samples are provided for all manner of configuration changes and customisations *fast, scalable* - with the sqlite, mysql and postgresql backends, roundup is also fast and scalable, easily handling thousands of issues and users with decent response times - database indexes are automatically added for those backends that support them (sqlite, mysql and postgresql) - indexed text searching giving fast responses to searches across all messages and indexed string properties - support for the Xapian or Whoosh full-text indexing engine for large trackers *documented* - documentation exists for installation, upgrading, maintenance, users and customisation *web interface* - fully editable interfaces for listing and display of items - extendable to include wizards, parent/meta bug displays, ... - differentiates between anonymous, known and admin users - may be set up to require login, and may also only allow admin users to register new users - authentication of user registration and user-driven password resetting using email and one time keys - may be run using WSGI or through CGI as a normal cgi script, as a stand-alone web server, under mod_python or through Zope - searching may be performed using many constraints, including a full-text search of messages attached to issues - file attachments (added through the web or email) are served up with the correct content-type and filename - email change messages generated by roundup appear to be sent by the person who made the change, but responses will go back through the nosy list by default - flexible access control built around Permissions and Roles with assigned Permissions - generates valid HTML4 or XHTML - detects concurrent user changes - saving and editing of user-defined queries which may optionally be shared with other users *e-mail interface* - may be set up using sendmail-like delivery alias, POP polling or mailbox polling - may auto-register users who send in mail and aren't known to roundup - nosy list configuration controls how people are added and when messages are sent to the list - auto-filing of "unformatted" messages into a particular class - e-mail attachments are handled sanely, being attached to the issue they're intended for, and forwarded on to the nosy list - sane handling of content-type and content-encoding of messages (text/plain preferred in all situations) - email packages that display threading will show issue messages correctly threaded - users may send in messages from multiple addresses and be associated with the same roundup username - built-in security features like TLS and APOP *command-line* - may be used to interactively manage roundup databases - may be scripted using standard shell scripting - roundup's API may also be used by other Python programs - a sample is provided that runs once a day and emails people their assigned issues - a variety of sample shell scripts are provided (weekly reports, issue generation, ...) *xmlrpc interface* - simple remote tracker interface with basic HTTP authentication available at the /xmlrpc endpoint. - provides same access to tracker as roundup-admin, but based on XMLRPC calls - see the `xmlrpc guide`_ for more details simple clients etc. *restful interface* - accessible using basic HTTP authentication at /rest starting point - see the `rest guide`_ for details. .. _sqlite: http://www.hwaci.com/sw/sqlite/ .. _mysql: https://pypi.org/project/MySQL-python/ .. _postgresql: http://initd.org/software/initd/psycopg .. _`xmlrpc guide`: xmlrpc.html .. _`rest guide`: rest.html