Upgrading to newer versions of Roundup
Please read each section carefully and edit your tracker home files accordingly. Note that there is information about upgrade procedures in the administration guide.
If a specific version transition isn’t mentioned here (eg. 0.6.7 to 0.6.8) then you don’t need to do anything. If you’re upgrading from 0.5.6 to 0.6.8 though, you’ll need to check the “0.5 to 0.6” and “0.6.x to 0.6.3” steps.
Contents
- Upgrading to newer versions of Roundup
- Migrating from 1.4.20 to 1.4.21
- Migrating from 1.4.19 to 1.4.20
- Migrating from 1.4.17 to 1.4.18
- Migrating from 1.4.x to 1.4.17
- Migrating from 1.4.x to 1.4.12
- Migrating from 1.4.x to 1.4.11
- Migrating from 1.4.x to 1.4.9
- Migrating from 1.4.x to 1.4.7
- Migrating from 1.4.2 to 1.4.3
- Migrating from 1.4.x to 1.4.2
- Migrating from 1.3.3 to 1.4.0
- Migrating from 1.2.x to 1.3.0
- Migrating from 1.1.2 to 1.2.0
- Migrating from 1.1.0 to 1.1.1
- Migrating from 1.0.x to 1.1.0
- Migrating from 0.8.x to 1.0
- Migrating from 0.8.0 to 0.8.3
- Migrating from 0.7.1 to 0.8.0
- Migrating from 0.7.2 to 0.7.3
- Migrating from 0.7.0 to 0.7.2
- Migrating from 0.7.0 to 0.7.1
- Migrating from 0.6 to 0.7
- Migrating from 0.6.x to 0.6.3
- Migrating from 0.5 to 0.6
- Migrating from 0.4.x to 0.5.0
- Migrating from 0.4.1 to 0.4.2
- Migrating from 0.4.0 to 0.4.1
- Migrating from 0.3.x to 0.4.0
- Migrating from 0.2.x to 0.3.x
Migrating from 1.4.20 to 1.4.21
The _generic.calendar.html page of the instance has been updated to include <meta name="robots" content="noindex, nofollow" />. This prevents robots to follow all the links in the calendar. If you haven’t modified the page on your local instance, you can simply replace it with the one in share/roundup/templates/classic/html/_generic.calendar.html; if you did, you can add the tag manually. See issue2550765 and changeset a099ff2ceff3.
- If you are using the xml-rpc interface, there is a change
in accessing it. You can not send text/xml data to any roundup url and get a response, you must use the /xmlrpc url. For example, if you used to send your xmlrpc request to:
http://myroundup.com/roundup
you need to change the url to read:
http://myroundup.com/roundup/xmlrpc
to invoke the xmlrpc handler. This allows us to send xml data to roundup for other handlers (e.g. REST, SOAP ...) in the future.
Migrating from 1.4.19 to 1.4.20
Roundup used to allow certain HTML-Tags in OK- and Error-messages. Since these messages are passed via the URL (due to roundup redirecting after an edit), we did have security-issues (see issue2550724).
If you have customized the OK or Error messages in your roundup-installation and you were using features like bold or italic in the message, you will have to do without this highlighting and remove HTML tags from messages.
If you were using
 tags for multi-line messages, you now should use newlines instead, these will be replaced with
 during formatting.
Note that the previous implementation also allowed links inside messages. Since these links could be set by an attacker, no links in roundup messages are supported anymore. This does not affect the “clear this message” link in OK-messages as it is generated by the template and is not part of the OK-message.
If you have not modified any roundup messages, you need not do anything, the templates shipped with roundup did not use HTML tags in messages for highlighting.
Migrating from 1.4.17 to 1.4.18
There was a bug in 1.4.17 where files were unlinked from issues if a mail without attachment was received via the mail interface. The following script will list likely issues being affected by the bug. The date in the script is the date of the 1.4.17 release. If you have installed 1.4.17 later than this date, you can change the date appropriately to your installation date. Run the script in the directory of your tracker:
#!/usr/bin/python
import os
from roundup import instance
from roundup.date import Date
dir = os.getcwd ()
tracker = instance.open (dir)
db = tracker.open ('admin')
# you may want to change this to your install date to find less candidates
last_release = Date('2011-05-13')
affected = {}
for i in db.issue.getnodeids():
for j in db.issue.history(i):
if i in affected:
break
if j[1] < last_release or j[3] != 'set' or 'files' not in j[4]:
continue
for op, p in j[4]['files']:
if op == '-':
affected [i] = 1
break
print ', '.join(sorted(affected.iterkeys()))
To find out which files where attached before you can look in the history of the affected issue. For fixing issues you can re-attach the files in question using the “set” command of roundup-admin, e.g., if the list of files attached to an issue should be files 5, 17, 23 for issue42 you will set this using
roundup-admin -i /path/to/your/tracker set issue42 files=5,17,23
Migrating from 1.4.x to 1.4.17
There is a new config-option migrate_passwords in section web to auto-migrate passwords at web-login time to a more secure storage scheme. Default for the new option is “yes” so if you don’t want that passwords are auto-migrated to a more secure password scheme on user login, set this to “no” before running your tracker(s) after the upgrade.
The standalone roundup-server now defaults to listening on localhost (no longer on all network interfaces). This will not affect you if you’re already using a configuration file for roundup-server. If you are using an empty setting for the host parameter in the config-file you should explicitly put <IP_ADDRESS> there as the use of an empty string to specify listening to all interfaces is deprecated and will go away in a future version. If you are starting the server without a configuration file and want to explicitly listen to all network interface, you should specify the -n option with the address <IP_ADDRESS>.
Searching now requires either read-permission without a check method, or you will have to add a “Search” permission for a class or a list of properties for a class (if you want to allow searching). For the classic template (or other templates derived from it) you want to add the following lines to your schema.py file:
p = db.security.addPermission(name='Search', klass='query')
db.security.addPermissionToRole('User', p)
This is needed, because for the query class users may view only their own queries (or public queries). This is implemented with a check method, therefore the default search permissions will not allow searching and you’ll have to add an explicit search permission. If you have modified your schema, you can check if you’re missing any search permissions with the following script, run it in your tracker directory, it will list for each Class and Property the roles that may search for this property:
#!/usr/bin/python
import os
from roundup import instance
tracker = instance.open(os.getcwd ())
db = tracker.open('admin')
for cl in sorted(db.getclasses()):
print "Class:", cl
for p in sorted(db.getclass(cl).properties.keys()):
print " Property:", p
roles = []
for role in sorted(db.security.role.iterkeys()):
if db.security.roleHasSearchPermission(cl,p,role):
roles.append(role)
print " roles may search:", ', '.join(roles)
Migrating from 1.4.x to 1.4.12
Item creation now checks the “Create” permission instead of the “Edit” permission for individual properties. If you have modified your tracker permissions from the default distribution, you should check that “Create” permissions exist for all properties you want users to be able to create.
Fixing some potential security holes
Enhanced checking was added to the user registration auditor. If you run a public tracker you should update your tracker’s detectors/userauditor.py using the new code from share/roundup/templates/classic/detectors/userauditor.py. In most cases you may just copy the file over, but if you’ve made changes to the auditor in your tracker then you’ll need to manually integrate the new code.
Some HTML templates were found to have formatting security problems:
html/page.html:
-tal:replace="request/user/username">username

+tal:replace="python:request.user.username.plain(escape=1)">username

html/_generic.help-list.html:
-tal:content="structure python:item[prop]">
+tal:content="python:item[prop]">
The lines marked “+” should be added and lines marked “-” should be deleted (minus the “+”/”-” signs).
Some HTML interface tweaks
You may wish to copy the user_utils.js and style.css` files from the source distribution ``share/roundup/templates/classic/html/ directory to the html directory of your trackers as it includes a small improvement.
If you have made local changes to those files you’ll need to manually work the differences in to your versions or ignore the changes.
Migrating from 1.4.x to 1.4.11
Close potential security hole
If your tracker has untrusted users you should examine its schema.py file and look for the section granting the “Edit” permission to your users. This should look something like:
p = db.security.addPermission(name='Edit', klass='user', check=own_record,
description="User is allowed to edit their own user details")
and should be modified to restrict the list of properties they are allowed to edit by adding the properties= section like:
p = db.security.addPermission(name='Edit', klass='user', check=own_record,
properties=('username', 'password', 'address', 'realname', 'phone',
'organisation', 'alternate_addresses', 'queries', 'timezone'),
description="User is allowed to edit their own user details")
Most importantly the “roles” property should not be editable - thus not appear in that list of properties.
Grant the “Register” permission to the Anonymous role
A separate “Register” permission has been introduced to allow anonymous users to register. This means you will need to add the following to your tracker’s schema.py to add the permission and assign it to the Anonymous role (replacing any previously assigned “Create user” permission for the Anonymous role):
+db.security.addPermission(name='Register', klass='user',
+ description='User is allowed to register new user')
# Assign the appropriate permissions to the anonymous user's Anonymous
# Role. Choices here are:
# - Allow anonymous users to register
-db.security.addPermissionToRole('Anonymous', 'Create', 'user')
+db.security.addPermissionToRole('Anonymous', 'Register', 'user')
The lines marked “+” should be added and lines marked “-” should be deleted (minus the “+”/”-” signs).
You should also modify the html/page.html template to change the permission tested there:
-tal:condition="python:request.user.hasPermission('Create', 'user')"
+tal:condition="python:request.user.hasPermission('Register', 'user')"
Generic class editor may now restore retired items
The instructions for doing so won’t be present in your tracker unless you copy the _generic.index.html template from the roundup distribution in share/roundup/templates/classic/html to your tracker’s html directory.
Migrating from 1.4.x to 1.4.9
Customized MailGW Class
If you have customized the MailGW class in your tracker: The new MailGW class opens the database for each message in the method handle_message (instance.open) instead of passing the opened database as a parameter to the MailGW constructor. The old handle_message has been renamed to _handle_message. The new method opens the database and wraps the call to the old method into a try/finally.
Your customized MailGW class needs to mirror this behavior.
Fix the “remove” button in issue files and messages lists
The “remove” button(s) in the issue messages list needs to be altered. Find the following in your tracker’s html/issue.item.html template:

<form style="padding:0" tal:condition="context/is_edit_ok"
tal:attributes="action string:issue${context/id}">
<input type="hidden" name="@remove@files" tal:attributes="value file/id">
and add method="POST" as shown below:

<form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
tal:attributes="action string:issue${context/id}">
<input type="hidden" name="@remove@files" tal:attributes="value file/id">
Then also find:

<form style="padding:0" tal:condition="context/is_edit_ok"
tal:attributes="action string:issue${context/id}">
<input type="hidden" name="@remove@messages" tal:attributes="value msg/id">
and add method="POST" as shown below:

<form style="padding:0" method="POST" tal:condition="context/is_edit_ok"
tal:attributes="action string:issue${context/id}">
<input type="hidden" name="@remove@messages" tal:attributes="value msg/id">
Fixing the “retire” button in user management list
Some previous versions of this upgrading document missed method="POST" in the change to the “retire” link in the user management list in section Migrating from 1.4.x to 1.4.7. Make sure the change is done as listed below in this document.
Migrating from 1.4.x to 1.4.7
Several security issues were addressed in this release. Some aspects of your trackers may no longer function depending on your local customisations. Core functionality that will need to be modified:
Grant the “retire” permission to users for their queries
Users will no longer be able to retire their own queries. To remedy this you will need to add the following to your tracker’s schema.py just under the line that grants them permission to edit their own queries:
p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
description="User is allowed to edit their queries")
db.security.addPermissionToRole('User', p)
+ p = db.security.addPermission(name='Retire', klass='query', check=edit_query,
+ description="User is allowed to retire their queries")
+ db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Create', klass='query',
description="User is allowed to create queries")
db.security.addPermissionToRole('User', p)
The lines marked “+” should be added, minus the “+” sign.
Fix the “retire” link in the users list for admin users
The “retire” link found in the file html/user.index.html:

retire
Should be replaced with:

<form style="padding:0" method="POST"
tal:attributes="action string:user${user/id}">
<input type="hidden" name="@template" value="index">
<input type="hidden" name="@action" value="retire">
<input type="submit" value="retire" i18n:attributes="value">
</form>
Fix for Python 2.6+ users
If you use Python 2.6 you should edit your tracker’s detectors/nosyreaction.py file to change:
import sets
at the top to:
from roundup.anypy.sets_ import set
and then all instances of sets.Set() to set() in the later code.
Trackers currently allowing HTML file uploading
Trackers which wish to continue to allow uploading of HTML content against issues will need to set a new configuration variable in the [web] section of the tracker’s config.ini file:
# Setting this option enables Roundup to serve uploaded HTML # file content as HTML. This is a potential security risk # and is therefore disabled by default. Set to ‘yes’ if you # trust all users uploading content to your tracker. # Allowed values: yes, no # Default: no allow_html_file = no
Migrating from 1.4.2 to 1.4.3
If you are using the MySQL backend you will need to replace some indexes that may have been created by version 1.4.2.
You should to access your MySQL database directly and remove any indexes with a name ending in “_key_retired_idx”. You should then re-add them with the same spec except the key column name needs a size. So an index on “_user (__retired, _name)” should become “_user (__retired, _name(255))”.
Migrating from 1.4.x to 1.4.2
You should run the “roundup-admin migrate” command for your tracker once you’ve installed the latest codebase.
Do this before you use the web, command-line or mail interface and before any users access the tracker.
This command will respond with either “Tracker updated” (if you’ve not previously run it on an RDBMS backend) or “No migration action required” (if you have run it, or have used another interface to the tracker, or are using anydbm).
It’s safe to run this even if it’s not required, so just get into the habit.
Migrating from 1.3.3 to 1.4.0
Value of the “refwd_re” tracker configuration option (section “mailgw”) is treated as UTF-8 string. In previous versions, it was ISO8859-1.
If you have running trackers based on the classic template, please update the messagesummary detector as follows:
--- detectors/messagesummary.py 17 Apr 2003 03:26:38 -0000 1.1
+++ detectors/messagesummary.py 3 Apr 2007 06:47:21 -0000 1.2
@@ -8,7 +8,7 @@
if newvalues.has_key('summary') or not newvalues.has_key('content'):
return
- summary, content = parseContent(newvalues['content'], 1, 1)
+ summary, content = parseContent(newvalues['content'], config=db.config)
newvalues['summary'] = summary
In the latest version we have added some database indexes to the SQL-backends (mysql, postgresql, sqlite) for speeding up building the roundup-index for full-text search. We recommend that you create the following database indexes on the database by hand:
CREATE INDEX words_by_id ON __words (_textid);
CREATE UNIQUE INDEX __textids_by_props ON __textids (_class, _itemid, _prop);
Migrating from 1.2.x to 1.3.0
1.3.0 Web interface changes
Some of the HTML files in the “classic” and “minimal” tracker templates were changed to fix some bugs and clean them up. You may wish to compare them to the HTML files in your tracker and apply any changes.
Migrating from 1.1.2 to 1.2.0
1.2.0 Sorting and grouping by multiple properties
Starting with this version, sorting and grouping by multiple properties is possible. This means that request.sort and request.group are now lists. This is reflected in several places:
renderWith now has list attributes for sort and group, where you previously wrote:
renderWith(... sort=('-', 'activity'), group=('+', 'priority')you write now:
renderWith(... sort=[('-', 'activity')], group=[('+', 'priority')]In templates that permit to edit sorting/grouping, request.sort and request.group are (possibly empty) lists. You can now sort and group by multiple attributes. For an example, see the classic template. You may want search for the variable n_sort which can be set to the number of sort/group properties.
Templates that diplay new headlines for each group of items with equal group properties can now use the modified batch.propchanged method that can take several properties which are checked for changes. See the example in the classic template which makes use of batch.propchanged.
Migrating from 1.1.0 to 1.1.1
1.1.1 “Clear this message”
In 1.1.1, the standard page.html template includes a “clear this message” link in the green “ok” message bar that appears after a successful edit (or other) action.
To include this in your tracker, change the following in your page.html template:

error

to be:

clear this message

If you implemented the “clear this message” in your 1.1.0 tracker, then you should change it to the above and it will work much better!
Migrating from 1.0.x to 1.1.0
1.1 Login “For Session Only”
In 1.1, web logins are alive for the length of a session only, unless you add the following to the login form in your tracker’s page.html:
<input type="checkbox" name="remember" id="remember">
Remember me?

See the classic tracker page.html if you’re unsure where this should go.
1.1 Query Display Name
The dispname web variable has been renamed @dispname to avoid clashing with other variables of the same name. If you are using the display name feature, you will need to edit your tracker’s page.html and issue.index.html pages to change dispname to @dispname.
A side-effect of this change is that the renderWith method used in the home.html page may now take a dispname argument.
1.1 “Clear this message”
In 1.1, the standard page.html template includes a “clear this message” link in the green “ok” message bar that appears after a successful edit (or other) action.
To include this in your tracker, change the following in your page.html template:

error

to be:

clear this message

Migrating from 0.8.x to 1.0
1.0 New Query Permissions
New permissions are defined for query editing and viewing. To include these in your tracker, you need to add these lines to your tracker’s schema.py:
# Users should be able to edit and view their own queries. They should also
# be able to view any marked as not private. They should not be able to
# edit others' queries, even if they're not private
def view_query(db, userid, itemid):
private_for = db.query.get(itemid, 'private_for')
if not private_for: return True
return userid == private_for
def edit_query(db, userid, itemid):
return userid == db.query.get(itemid, 'creator')
p = db.security.addPermission(name='View', klass='query', check=view_query,
description="User is allowed to view their own and public queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Edit', klass='query', check=edit_query,
description="User is allowed to edit their queries")
db.security.addPermissionToRole('User', p)
p = db.security.addPermission(name='Create', klass='query',
description="User is allowed to create queries")
db.security.addPermissionToRole('User', p)
and then remove ‘query’ from the line:
# Assign the access and edit Permissions for issue, file and message
# to regular users now
for cl in 'issue', 'file', 'msg', 'query', 'keyword':
so it looks like:
for cl in 'issue', 'file', 'msg', 'keyword':
Migrating from 0.8.0 to 0.8.3
0.8.3 Nosy Handling Changes
A change was made to fix a bug in the nosyreaction.py standard detector. To incorporate this fix in your trackers, you will need to copy the nosyreaction.py file from the templates/classic/detectors directory of the source to your tracker’s templates directory.
If you have modified the nosyreaction.py file from the standard version, you will need to roll your changes into the new file.
Migrating from 0.7.1 to 0.8.0
You must fully uninstall previous Roundup version before installing Roundup 0.8.0. If you don’t do that, roundup-admin install command may fail to function properly.
0.8.0 Backend changes
Backends ‘bsddb’ and ‘bsddb3’ are removed. If you are using one of these, you must migrate to another backend before upgrading.
0.8.0 API changes
Class.safeget() was removed from the API. Test your item ids before calling Class.get() instead.
0.8.0 New tracker layout
The config.py file has been replaced by config.ini. You may use the roundup-admin command “genconfig” to generate a new config file:
roundup-admin genconfig <tracker home>/config.ini
and modify the values therein based on the contents of your old config.py. In most cases, the names of the config variables are the same.
The select_db.py file has been replaced by a file in the db directory called backend_name. As you might guess, this file contains just the name of the backend. To figure what the contents of yours should be, use the following table:
select_db.py contents backend_name contents from back_anydbm import ... anydbm from back_metakit import ... metakit from back_sqlite import ... sqlite from back_mysql import ... mysql from back_postgresql import ... postgresql
The dbinit.py file has been split into two new files, initial_data.py and schema.py. The contents of this file are:
- initial_data.py
- You don’t need one of these as your tracker is already initialised.
- schema.py
Copy the body of the def open(name=None) function from your old tracker’s dbinit.py file to this file. As the lines you’re copying aren’t part of a function definition anymore, one level of indentation needs to be removed (remove only the leading four spaces on each line).
The first few lines – those starting with from roundup.hyperdb import ... and the db = Database(config, name) line – don’t need to be copied. Neither do the last few lines – those starting with import detectors, down to return db inclusive.
You may remove the __init__.py module from the “detectors” directory as it is no longer used.
There’s a new way to write extension code for Roundup. If you have code in an interfaces.py file you should move it. See the customisation documentation for information about how extensions are now written. Note that some older trackers may use interfaces.py to customise the mail gateway behaviour. You will need to keep your interfaces.py file if this is the case.
0.8.0 Permissions Changes
The creation of a new item in the user interfaces is now controlled by the “Create” Permission. You will need to add an assignment of this Permission to your users who are allowed to create items. The most common form of this is the following in your schema.py added just under the current assignation of the Edit Permission:
for cl in 'issue', 'file', 'msg', 'query', 'keyword':
p = db.security.getPermission('Create', cl)
db.security.addPermissionToRole('User', p)
You will need to explicitly let anonymous users access the web interface so that regular users are able to see the login form. Note that almost all trackers will need this Permission. The only situation where it’s not required is in a tracker that uses an HTTP Basic Authenticated front-end. It’s enabled by adding to your schema.py:
p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('Anonymous', p)
Finally, you will need to enable permission for your users to edit their own details by adding the following to schema.py:
# Users should be able to edit their own details. Note that this
# permission is limited to only the situation where the Viewed or
# Edited item is their own.
def own_record(db, userid, itemid):
'''Determine whether the userid matches the item being accessed.'''
return userid == itemid
p = db.security.addPermission(name='View', klass='user', check=own_record,
description="User is allowed to view their own user details")
p = db.security.addPermission(name='Edit', klass='user', check=own_record,
description="User is allowed to edit their own user details")
db.security.addPermissionToRole('User', p)
0.8.0 Use of TemplatingUtils
If you used custom python functions in TemplatingUtils, they must be moved from interfaces.py to a new file in the extensions directory.
Each Function that should be available through TAL needs to be defined as a toplevel function in the newly created file. Furthermore you add an inititialization function, that registers the functions with the tracker.
If you find this too tedious, donfu wrote an automatic init function that takes an existing TemplatingUtils class, and registers all class methods that do not start with an underscore. The following hack should be placed in the extensions directory alongside other extensions:
class TemplatingUtils:
# copy from interfaces.py
def init(tracker):
util = TemplatingUtils()
def setClient(tu):
util.client = tu.client
return util
def execUtil(name):
return lambda tu, *args, **kwargs: \
getattr(setClient(tu), name)(*args, **kwargs)
for name in dir(util):
if callable(getattr(util, name)) and not name.startswith('_'):
tracker.registerUtil(name, execUtil(name))
0.8.0 Logging Configuration
See the administration guide for information about configuring the new logging implemented in 0.8.0.
Migrating from 0.7.2 to 0.7.3
0.7.3 Configuration
If you choose, you may specify the directory from which static files are served (those which use the URL component @@file). Currently the directory defaults to the TEMPLATES configuration variable. You may define a new variable, STATIC_FILES which overrides this value for static files.
Migrating from 0.7.0 to 0.7.2
0.7.2 DEFAULT_TIMEZONE is now required
The DEFAULT_TIMEZONE configuration variable is now required. Add the following to your tracker’s config.py file:
# You may specify a different default timezone, for use when users do not
# choose their own in their settings.
DEFAULT_TIMEZONE = 0 # specify as numeric hour offest
Migrating from 0.7.0 to 0.7.1
0.7.1 Permission assignments
If you allow anonymous access to your tracker, you might need to assign some additional View (or Edit if your tracker is that open) permissions to the “anonymous” user. To do so, find the code in your dbinit.py that says:
for cl in 'issue', 'file', 'msg', 'query', 'keyword':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Edit', cl)
db.security.addPermissionToRole('User', p)
for cl in 'priority', 'status':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
Add add a line:
db.security.addPermissionToRole('Anonymous', p)
next to the existing 'User' lines for the Permissions you wish to assign to the anonymous user.
Migrating from 0.6 to 0.7
0.7.0 Permission assignments
Due to a change in the rendering of web widgets, permissions are now checked on Classes where they previously weren’t (this is a good thing).
You will need to add some additional Permission assignments for your regular users, or some displays will break. After the following in your tracker’s dbinit.py:
# Assign the access and edit Permissions for issue, file and message
# to regular users now
for cl in 'issue', 'file', 'msg', 'query', 'keyword':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Edit', cl)
db.security.addPermissionToRole('User', p)
add:
for cl in 'priority', 'status':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
0.7.0 Getting the current user id
The Database.curuserid attribute has been removed.
Any code referencing this attribute should be replaced with a call to Database.getuid().
0.7.0 ZRoundup changes
The templates in your tracker’s html directory will need updating if you wish to use ZRoundup. If you’ve not modified those files (or some of them), you may just copy the new versions from the Roundup source in the templates/classic/html directory.
If you have modified the html files, then you’ll need to manually edit them to change all occurances of special form variables from using the colon “:” special character to the at “@” special character. That is, variables such as:
:action :required :template :remove:messages ...
should become:
@action @required @template @remove@messages ...
Note that tal: statements are unaffected. So are TAL expression type prefixes such as python: and string:. Please ask on the roundup-users mailing list for help if you’re unsure.
0.7.0 Edit collision detection
Roundup now detects collisions with editing in the web interface (that is, two people editing the same item at the same time).
You must copy the _generic.collision.html file from Roundup source in the templates/classic/html directory. to your tracker’s html directory.
Migrating from 0.6.x to 0.6.3
0.6.3 Configuration
You will need to copy the file:
templates/classic/detectors/__init__.py
to your tracker’s detectors directory, replacing the one already there. This fixes a couple of bugs in that file.
Migrating from 0.5 to 0.6
0.6.0 Configuration
Introduced EMAIL_FROM_TAG config variable. This value is inserted into the From: line of nosy email. If the sending user is “Foo Bar”, the From: line is usually:
"Foo Bar"<EMAIL_ADDRESS>the EMAIL_FROM_TAG goes inside the “Foo Bar” quotes like so:
"Foo Bar EMAIL_FROM_TAG"<EMAIL_ADDRESS>I’ve altered the mechanism in the detectors __init__.py module so that it doesn’t cross-import detectors from other trackers (if you run more than one in a single roundup-server). This change means that you’ll need to copy the __init__.py from roundup/templates/classic/detectors/__init__.py to your <tracker home>/detectors/__init__.py. Don’t worry, the “classic” __init__ is a one-size-fits-all, so it’ll work even if you’ve added/removed detectors.
0.6.0 Templating changes
The user.item template (in the tracker home “templates” directory) needs to have the following hidden variable added to its form (between the <form...> and </form> tags:
<input type="hidden" name=":template" value="item">
0.6.0 Form handling changes
Roundup’s form handling capabilities have been significantly expanded. This should not affect users of 0.5 installations - but if you find you’re getting errors from form submissions, please ask for help on the Roundup users mailing list:
http://lists.sourceforge.net/lists/listinfo/roundup-users
See the customisation doc section on Form Values for documentation of the new form variables possible.
0.6.0 Multilingual character set support
Added internationalization support. This is done via encoding all data stored in roundup database to utf-8 (unicode encoding). To support utf-8 in web interface you should add the folowing line to your tracker’s html/page and html/_generic.help files inside  tag:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Since latin characters in utf-8 have the same codes as in ASCII table, this modification is optional for users who use only plain latin characters.
After this modification, you will be able to see and enter any world character via web interface. Data received via mail interface also converted to utf-8, however only new messages will be converted. If your roundup database contains some of non-ASCII characters in one of 8-bit encoding, they will not be visible in new unicode environment. Some of such data (e.g. user names, keywords, etc) can be edited by administrator, the others (e.g. messages’ contents) is not editable via web interface. Currently there is no tool for converting such data, the only solution is to close appropriate old issues and create new ones with the same content.
0.6.0 User timezone support
From version 0.6.0 roundup supports displaying of Date data in user’ local timezone if he/she has provided timezone information. To make it possible some modification to tracker’s schema and HTML templates are required. First you must add string property ‘timezone’ to user class in dbinit.py like this:
user = Class(db, "user",
username=String(), password=Password(),
address=String(), realname=String(),
phone=String(), organisation=String(),
alternate_addresses=String(),
queries=Multilink('query'), roles=String(),
timezone=String())
And second - html interface. Add following lines to $TRACKER_HOME/html/user.item template:

Timezone
timezone

After that all users should be able to provide their timezone information. Timezone should be a positive or negative integer - offset from GMT.
After providing timezone, roundup will show all dates values, found in web and mail interfaces in local time. It will also accept any Date info in local time, convert and store it in GMT.
0.6.0 Search page structure
In order to accomodate query editing the search page has been restructured. If you want to provide your users with query editing, you should update your search page using the macros detailed in the customisation doc section Searching on categories.
Also, the url field in the query class no longer starts with a ‘?’. You’ll need to remove this question mark from the url field to support queries. There’s a script in the “tools” directory called migrate-queries.py that should automatically change any existing queries for you. As always, make a backup of your database before running such a script.
0.6.0 Notes for metakit backend users
Roundup 0.6.0 introduced searching on ranges of dates and intervals. To support it, some modifications to interval storing routine were made. So if your tracker uses metakit backend and your db schema contains intervals property, searches on that property will not be accurate for db items that was stored before roundup’ upgrade. However all new records should be searchable on intervals.
It is possible to convert your database to new format: you can export and import back all your data (consult “Migrating backends” in “Maintenance” documentation). After this operation all your interval properties should become searchable.
Users of backends others than metakit should not worry about this issue.
Migrating from 0.4.x to 0.5.0
This has been a fairly major revision of Roundup:
- Brand new, much more powerful, flexible, tasty and nutritious templating. Unfortunately, this means all your current templates are useless. Hopefully the new documentation and examples will be enough to help you make the transition. Please don’t hesitate to ask on roundup-users for help (or complete conversions if you’re completely stuck)!
- The database backed got a lot more flexible, allowing Metakit and SQL databases! The only decent SQL database implemented at present is sqlite, but others shouldn’t be a whole lot more work.
- A brand new, highly flexible and much more robust security system including a system of Permissions, Roles and Role assignments to users. You may now define your own Permissions that may be checked in CGI transactions.
- Journalling has been made less storage-hungry, so has been turned on by default except for author, recipient and nosy link/unlink events. You are advised to turn it off in your trackers too.
- We’ve changed the terminology from “instance” to “tracker”, to ease the learning curve/impact for new users.
- Because of the above changes, the tracker configuration has seen some major changes. See below for the details.
Please, back up your database before you start the migration process. This is as simple as copying the “db” directory and all its contents from your tracker to somewhere safe.
0.5.0 Configuration
First up, rename your instance_config.py file to just config.py.
Then edit your tracker’s __init__.py module. It’ll currently look like this:
from instance_config import *
try:
from dbinit import *
except ImportError:
pass # in installdir (probably :)
from interfaces import *
and it needs to be:
import config
from dbinit import open, init
from interfaces import Client, MailGW
Due to the new templating having a top-level page that defines links for searching, indexes, adding items etc, the following variables are no longer used:
- HEADER_INDEX_LINKS
- HEADER_ADD_LINKS
- HEADER_SEARCH_LINKS
- SEARCH_FILTERS
- DEFAULT_INDEX
- UNASSIGNED_INDEX
- USER_INDEX
- ISSUE_FILTER
The new security implementation will require additions to the dbinit module, but also removes the need for the following tracker config variables:
- ANONYMOUS_ACCESS
- ANONYMOUS_REGISTER
but requires two new variables which define the Roles assigned to users who register through the web and e-mail interfaces:
- NEW_WEB_USER_ROLES
- NEW_EMAIL_USER_ROLES
in both cases, ‘User’ is a good initial setting. To emulate ANONYMOUS_ACCESS='deny', remove all “View” Permissions from the “Anonymous” Role. To emulate ANONYMOUS_REGISTER='deny', remove the “Web Registration” and/or the “Email Registration” Permission from the “Anonymous” Role. See the section on customising security in the customisation documentation for more information.
Finally, the following config variables have been renamed to make more sense:
- INSTANCE_HOME -> TRACKER_HOME
- INSTANCE_NAME -> TRACKER_NAME
- ISSUE_TRACKER_WEB -> TRACKER_WEB
- ISSUE_TRACKER_EMAIL -> TRACKER_EMAIL
0.5.0 Schema Specification
0.5.0 Database backend changes
Your select_db module in your tracker has changed a fair bit. Where it used to contain:
# WARNING: DO NOT EDIT THIS FILE!!!
from roundup.backends.back_anydbm import Database
it must now contain:
# WARNING: DO NOT EDIT THIS FILE!!!
from roundup.backends.back_anydbm import Database, Class, FileClass, IssueClass
Yes, I realise the irony of the “DO NOT EDIT THIS FILE” statement :) Note the addition of the Class, FileClass, IssueClass imports. These are very important, as they’re going to make the next change work too. You now need to modify the top of the dbinit module in your tracker from:
import instance_config
from roundup import roundupdb
from select_db import Database
from roundup.roundupdb import Class, FileClass
class Database(roundupdb.Database, select_db.Database):
''' Creates a hybrid database from:
. the selected database back-end from select_db
. the roundup extensions from roundupdb
'''
pass
class IssueClass(roundupdb.IssueClass):
''' issues need the email information
'''
pass
to:
import config
from select_db import Database, Class, FileClass, IssueClass
Yes, remove the Database and IssueClass definitions and those other imports. They’re not needed any more!
Look for places in dbinit.py where instance_config is used too, and rename them config.
0.5.0 Journalling changes
Journalling has been optimised for storage. Journalling of links has been turned back on by default. If your tracker has a large user base, you may wish to turn off journalling of nosy list, message author and message recipient link and unlink events. You do this by adding do_journal='no' to the Class initialisation in your dbinit. For example, your msg class initialisation probably looks like this:
msg = FileClass(db, "msg",
author=Link("user"), recipients=Multilink("user"),
date=Date(), summary=String(),
files=Multilink("file"),
messageid=String(), inreplyto=String())
to turn off journalling of author and recipient link events, add do_journal='no' to the author=Link("user") part of the statement, like so:
msg = FileClass(db, "msg",
author=Link("user", do_journal='no'),
recipients=Multilink("user", do_journal='no'),
date=Date(), summary=String(),
files=Multilink("file"),
messageid=String(), inreplyto=String())
Nosy list link event journalling is actually turned off by default now. If you want to turn it on, change to your issue class’ nosy list, change its definition from:
issue = IssueClass(db, "issue",
assignedto=Link("user"), topic=Multilink("keyword"),
priority=Link("priority"), status=Link("status"))
to:
issue = IssueClass(db, "issue", nosy=Multilink("user", do_journal='yes'),
assignedto=Link("user"), topic=Multilink("keyword"),
priority=Link("priority"), status=Link("status"))
noting that your definition of the nosy Multilink will override the normal one.
0.5.0 User schema changes
Users have two more properties, “queries” and “roles”. You’ll have something like this in your dbinit module now:
user = Class(db, "user",
username=String(), password=Password(),
address=String(), realname=String(),
phone=String(), organisation=String(),
alternate_addresses=String())
user.setkey("username")
and you’ll need to add the new properties and the new “query” class to it like so:
query = Class(db, "query",
klass=String(), name=String(),
url=String())
query.setkey("name")
# Note: roles is a comma-separated string of Role names
user = Class(db, "user",
username=String(), password=Password(),
address=String(), realname=String(),
phone=String(), organisation=String(),
alternate_addresses=String(),
queries=Multilink('query'), roles=String())
user.setkey("username")
The “queries” property is used to store off the user’s favourite database queries. The “roles” property is explained below in 0.5.0 Security Settings.
0.5.0 Security Settings
See the security documentation for an explanation of how the new security system works. In a nutshell though, the security is handled as a four step process:
- Permissions are defined as having a name and optionally a hyperdb class they’re specific to,
- Roles are defined that have one or more Permissions,
- Users are assigned Roles in their “roles” property, and finally
- Roundup checks that users have appropriate Permissions at appropriate times (like editing issues).
Your tracker dbinit module’s open function now has to define any Permissions that are specific to your tracker, and also the assignment of Permissions to Roles. At the moment, your open function ends with:
import detectors
detectors.init(db)
return db
and what we need to do is insert some commands that will set up the security parameters. Right above the import detectors line, you’ll want to insert these lines:
#
# SECURITY SETTINGS
#
# new permissions for this schema
for cl in 'issue', 'file', 'msg', 'user':
db.security.addPermission(name="Edit", klass=cl,
description="User is allowed to edit "+cl)
db.security.addPermission(name="View", klass=cl,
description="User is allowed to access "+cl)
# Assign the access and edit permissions for issue, file and message
# to regular users now
for cl in 'issue', 'file', 'msg':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Edit', cl)
db.security.addPermissionToRole('User', p)
# and give the regular users access to the web and email interface
p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Email Access')
db.security.addPermissionToRole('User', p)
# May users view other user information? Comment these lines out
# if you don't want them to
p = db.security.getPermission('View', 'user')
db.security.addPermissionToRole('User', p)
# Assign the appropriate permissions to the anonymous user's Anonymous
# Role. Choices here are:
# - Allow anonymous users to register through the web
p = db.security.getPermission('Web Registration')
db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous (new) users to register through the email gateway
p = db.security.getPermission('Email Registration')
db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous users access to the "issue" class of data
# Note: this also grants access to related information like files,
# messages, statuses etc that are linked to issues
#p = db.security.getPermission('View', 'issue')
#db.security.addPermissionToRole('Anonymous', p)
# - Allow anonymous users access to edit the "issue" class of data
# Note: this also grants access to create related information like
# files and messages etc that are linked to issues
#p = db.security.getPermission('Edit', 'issue')
#db.security.addPermissionToRole('Anonymous', p)
# oh, g'wan, let anonymous access the web interface too
p = db.security.getPermission('Web Access')
db.security.addPermissionToRole('Anonymous', p)
Note in the comments there the places where you might change the permissions to restrict users or grant users more access. If you’ve created additional classes that users should be able to edit and view, then you should add them to the “new permissions for this schema” section at the start of the security block. Then add them to the “Assign the access and edit permissions” section too, so people actually have the new Permission you’ve created.
One final change is needed that finishes off the security system’s initialisation. We need to add a call to db.post_init() at the end of the dbinit open() function. Add it like this:
import detectors
detectors.init(db)
# schema is set up - run any post-initialisation
db.post_init()
return db
You may verify the setup of Permissions and Roles using the new “roundup-admin security” command.
0.5.0 User changes
To support all those schema changes, you’ll need to massage your user database a little too, to:
- make sure there’s an “anonymous” user - this user is mandatory now and is the one that unknown users are logged in as.
- make sure all users have at least one Role.
If you don’t have the “anonymous” user, create it now with the command:
roundup-admin create user username=anonymous roles=Anonymous
making sure the capitalisation is the same as above. Once you’ve done that, you’ll need to set the roles property on all users to a reasonable default. The admin user should get “Admin”, the anonymous user “Anonymous” and all other users “User”. The fixroles.py script in the tools directory will do this. Run it like so (where python is your python 2+ binary):
python tools/fixroles.py -i <tracker home> fixroles
0.5.0 CGI interface changes
The CGI interface code was completely reorganised and largely rewritten. The end result is that this section of your tracker interfaces module will need changing from:
from roundup import cgi_client, mailgw
from roundup.i18n import _
class Client(cgi_client.Client):
''' derives basic CGI implementation from the standard module,
with any specific extensions
'''
pass
to:
from roundup import mailgw
from roundup.cgi import client
class Client(client.Client):
''' derives basic CGI implementation from the standard module,
with any specific extensions
'''
pass
You will also need to install the new version of roundup.cgi from the source cgi-bin directory if you’re using it.
0.5.0 HTML templating
You’ll want to make a backup of your current tracker html directory. You should then copy the html directory from the Roundup source “classic” template and modify it according to your local schema changes.
If you need help with the new templating system, please ask questions on the roundup-users mailing list (available through the roundup web page on sourceforge, http://www.roundup-tracker.org/.
0.5.0 Detectors
The nosy reactor has been updated to handle the tracker not having an “assignedto” property on issues. You may want to copy it into your tracker’s detectors directory. Chances are you’ve already fixed it though :)
Migrating from 0.4.1 to 0.4.2
0.4.2 Configuration
The USER_INDEX definition introduced in 0.4.1 was too restrictive in its allowing replacement of ‘assignedto’ with the user’s userid. Users must change the None value of ‘assignedto’ to ‘CURRENT USER’ (the string, in quotes) for the replacement behaviour to occur now.
The new configuration variables are:
- EMAIL_KEEP_QUOTED_TEXT
- EMAIL_LEAVE_BODY_UNCHANGED
- ADD_RECIPIENTS_TO_NOSY
See the sample configuration files in:
<roundup source>/roundup/templates/classic/instance_config.py
and:
<roundup source>/roundup/templates/extended/instance_config.py
and the customisation documentation for information on how they’re used.
0.4.2 Changes to detectors
You will need to copy the detectors from the distribution into your instance home “detectors” directory. If you used the classic schema, the detectors are in:
<roundup source>/roundup/templates/classic/detectors/
If you used the extended schema, the detectors are in:
<roundup source>/roundup/templates/extended/detectors/
The change means that schema-specific code has been removed from the mail gateway and cgi interface and made into auditors:
- nosyreactor.py has now got an updatenosy auditor which updates the nosy list with author, recipient and assignedto information.
- statusauditor.py makes the unread or resolved -> chatting changes and presets the status of an issue to unread.
There’s also a bug or two fixed in the nosyreactor code.
0.4.2 HTML templating changes
The link() htmltemplate function now has a “showid” option for links and multilinks. When true, it only displays the linked item id as the anchor text. The link value is displayed as a tooltip using the title anchor attribute. To use in eg. the superseder field, have something like this:

<display call="field('superseder', showid=1)">
<display call="classhelp('issue', 'id,title', label='list', width=500)">
<property name="superseder">

View: <display call="link('superseder', showid=1)">
</property>

The stylesheets have been cleaned up too. You may want to use the newer versions in:
<roundup source>/roundup/templates/<template>/html/default.css
Migrating from 0.4.0 to 0.4.1
0.4.1 Files storage
Messages and files from newly created issues will be put into subdierectories in thousands e.g. msg123 will be put into files/msg/0/msg123, file2003 will go into files/file/2/file2003. Previous messages are still found, but could be put into this structure.
0.4.1 Configuration
To allow more fine-grained access control, the variable used to check permission to auto-register users in the mail gateway is now called ANONYMOUS_REGISTER_MAIL rather than overloading ANONYMOUS_REGISTER. If the variable doesn’t exist, then ANONYMOUS_REGISTER is tested as before.
Configuring the links in the web header is now easier too. The following variables have been added to the classic instance_config.py:
HEADER_INDEX_LINKS - defines the "index" links to be made available
HEADER_ADD_LINKS - defines the "add" links
DEFAULT_INDEX - specifies the index view for DEFAULT
UNASSIGNED_INDEX - specifies the index view for UNASSIGNED
USER_INDEX - specifies the index view for USER
See the <roundup source>/roundup/templates/classic/instance_config.py for more information - including how the variables are to be set up. Most users will just be able to copy the variables from the source to their instance home. If you’ve modified the header by changing the source of the interfaces.py file in the instance home, you’ll need to remove that customisation and move it into the appropriate variables in instance_config.py.
The extended schema has similar variables added too - see the source for more info.
0.4.1 Alternate E-Mail Addresses
If you add the property “alternate_addresses” to your user class, your users will be able to register alternate email addresses that they may use to communicate with roundup as. All email from roundup will continue to be sent to their primary address.
If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:
<roundup source>/roundup/templates/classic/dbinit.py
If you used the extended schema, the file is in:
<roundup source>/roundup/templates/extended/dbinit.py
If you have modified your dbinit.py file, you need to edit the dbinit.py file in your instance home directory. Find the lines which define the user class:
user = Class(db, "msg",
username=String(), password=Password(),
address=String(), realname=String(),
phone=String(), organisation=String(),
alternate_addresses=String())
You will also want to add the property to the user’s details page. The template for this is the “user.item” file in your instance home “html” directory. Similar to above, you may copy the file from the roundup source if you haven’t modified it. Otherwise, add the following to the template:
<display call="multiline('alternate_addresses')">
with appropriate labelling etc. See the standard template for an idea.
Migrating from 0.3.x to 0.4.0
0.4.0 Message-ID and In-Reply-To addition
0.4.0 adds the tracking of messages by message-id and allows threading using in-reply-to. Most e-mail clients support threading using this feature, and we hope to add support for it to the web gateway. If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:
<roundup source>/roundup/templates/classic/dbinit.py
If you used the extended schema, the file is in:
<roundup source>/roundup/templates/extended/dbinit.py
If you have modified your dbinit.py file, you need to edit the dbinit.py file in your instance home directory. Find the lines which define the msg class:
msg = FileClass(db, "msg",
author=Link("user"), recipients=Multilink("user"),
date=Date(), summary=String(),
files=Multilink("file"))
and add the messageid and inreplyto properties like so:
msg = FileClass(db, "msg",
author=Link("user"), recipients=Multilink("user"),
date=Date(), summary=String(),
files=Multilink("file"),
messageid=String(), inreplyto=String())
Also, configuration is being cleaned up. This means that your dbinit.py will also need to be changed in the open function. If you haven’t changed your dbinit.py, the above copy will be enough. If you have, you’ll need to change the line (round line 50):
db = Database(instance_config.DATABASE, name)
to:
db = Database(instance_config, name)
0.4.0 Configuration
TRACKER_NAME and EMAIL_SIGNATURE_POSITION have been added to the instance_config.py. The simplest solution is to copy the default values from template in the core source.
The mail gateway now checks ANONYMOUS_REGISTER to see if unknown users are to be automatically registered with the tracker. If it is set to “deny” then unknown users will not have access. If it is set to “allow” they will be automatically registered with the tracker.
0.4.0 CGI script roundup.cgi
The CGI script has been updated with some features and a bugfix, so you should copy it from the roundup cgi-bin source directory again. Make sure you update the ROUNDUP_INSTANCE_HOMES after the copy.
0.4.0 Nosy reactor
The nosy reactor has also changed - copy the nosyreactor.py file from the core source:
<roundup source>/roundup/templates/<template>/detectors/nosyreactor.py
to your instance home “detectors” directory.
0.4.0 HTML templating
The field() function was incorrectly implemented - links and multilinks now display as text fields when rendered using field(). To display a menu (drop- down or select box) you need to use the menu() function.
Migrating from 0.2.x to 0.3.x
0.3.x Cookie Authentication changes
0.3.0 introduces cookie authentication - you will need to copy the interfaces.py file from the roundup source to your instance home to enable authentication. If you used the classic schema, the interfaces file is in:
<roundup source>/roundup/templates/classic/interfaces.py
If you used the extended schema, the file is in:
<roundup source>/roundup/templates/extended/interfaces.py
If you have modified your interfaces.Client class, you will need to take note of the login/logout functionality provided in roundup.cgi_client.Client (classic schema) or roundup.cgi_client.ExtendedClient (extended schema) and modify your instance code apropriately.
0.3.x Password encoding
This release also introduces encoding of passwords in the database. If you have not edited the dbinit.py file in your instance home directory, you may simply copy the new dbinit.py file from the core code. If you used the classic schema, the interfaces file is in:
<roundup source>/roundup/templates/classic/dbinit.py
If you used the extended schema, the file is in:
<roundup source>/roundup/templates/extended/dbinit.py
If you have modified your dbinit.py file, you may use encoded passwords:
Edit the dbinit.py file in your instance home directory a. At the first code line of the open() function:
from roundup.hyperdb import String, Date, Link, Multilink alter to include Password, as so:: from roundup.hyperdb import String, Password, Date, Link, Multilink
Where the password property is defined (around line 66):
user = Class(db, "user", username=String(), password=String(), address=String(), realname=String(), phone=String(), organisation=String()) user.setkey("username")
alter the “password=String()” to “password=Password()”:
user = Class(db, "user", username=String(), password=Password(), address=String(), realname=String(), phone=String(), organisation=String()) user.setkey("username")
Any existing passwords in the database will remain cleartext until they are edited. It is recommended that at a minimum the admin password be changed immediately:
roundup-admin -i <instance home> set user1 password=<new password>
0.3.x Configuration
FILTER_POSITION, ANONYMOUS_ACCESS, ANONYMOUS_REGISTER have been added to the instance_config.py. Simplest solution is to copy the default values from template in the core source.
MESSAGES_TO_AUTHOR has been added to the IssueClass in dbinit.py. Set to ‘yes’ to send nosy messages to the author. Default behaviour is to not send nosy messages to the author. You will need to add MESSAGES_TO_AUTHOR to your dbinit.py in your instance home.
0.3.x CGI script roundup.cgi
There have been some structural changes to the roundup.cgi script - you will need to install it again from the cgi-bin directory of the source distribution. Make sure you update the ROUNDUP_INSTANCE_HOMES after the copy.


TWICE's Dahyun Calling JYP by His Real Name and Talking Informally Had Netizens Laughing
by HelloAnonJTBC's Knowing Bros recently released the episode preview of Park Jin Young's appearance on the show with TWICE's Nayeon and Dahyun to be aired on November 30.
Fans and netizens were caught off guard by some of the funny scenes as the TWICE members become extra savage with their company boss who they had to treat like a same age schoolmate to follow the premise of the show.
Check out the full preview:
Here are some reactions from viewers:


jsrsasign - RSA Signing and Verification in JavaScript
Kenji Urushima
Last Update: Apr 30, 2012
The 'jsrsasign'(RSA-Sign JavaScript Library) is a open source free pure JavaScript implementation of
PKCS#1 v2.1 RSASSA-PKCS1-v1_5 RSA signing and validation algorithm.
NEWS
Release 1.2 is now available on Apr 30, 2012 for fixing critical zero padding bug and supporting some other hash
functions.
DEMO
SOURCE CODES
The 'rsa-sign' library contains following source codes.
- rsa-sign.js - RSAKey class extension for RSA signing and verification.
- x509.js - X509 class to read subject public key from a PEM formatted X.509 certificate.
- rsa-pem.js - RSAKey class extension to read PKCS#1 RSA private key PEM file
- asn1hex.js - simple ASN.1 parser to read hexadecimal encoded ASN.1 DER
LICENSE
The 'jsrsasign'(RSA-Sign JavaScript Library) is licensed under the terms of the MIT license
reproduced below.
How to sign
var rsa = new RSAKey();
rsa.readPrivateKeyFromPEMString(_PEM_PRIVATE_KEY_STRING_);
var hSig = rsa.signString("aaa", "sha1"); // sign a string "aaa" with key
How to verify signature
vr x509 = new X509();
x509.readCertPEM(_PEM_X509CERT_STRING_);
var result = x509.subjectPublicKeyRSA.verifyString("aaa", _HEX_SIGNATURE_);
How to add supported signature algorithms
The script "rsa-sign.js" currently supports
SHA1withRSA,
SHA256withRSA,
SHA512withRSA,
MD5withRSA and
RIPEMD160withRSA
signature algorithms. However you can extend other signature algorithms
such like MD2withRSA or SHA384withRSA by just specifying two variables in it.
_RSASIGN_DIHEAD['md2'] = "30..."; // Hexadecimal DigestInfo prefix for MD5
_RSASIGN_HASHHEXFUNC['md2'] = md2hex; // function which returns value in hex.
Required Third Party Source Codes
- Tom Wu's jsbn library - BigInteger and RSA
- base64.js - String encoder for Base64 and Hex
- jsbn.js - basic BigInteger class
- jsbn2.js - BigInteger class extension
- prng4.js - Random number generator
- rng.js - Random number generator
- rsa_api.js - RSAKey class for RSA public key encryption.
- rsa2.js - RSA class extension for RSA private key decryption.
-
Paul Johnston's JavaScript MD5
- You can download MD5, SHA1, SHA256, SHA512 and RIPEMD-160 implementation of JavaScript.
NOTE: As for hash algorithm, you can use any other hash implementations.
The requirement is to provide a function which returns hexadecimal
string as the result.
Release
- Release 1.2: Apr 30, 2012 - Critical zero padding bug fix and some other hash support
- Release 1.1: Sep 25, 2010 - Web contents update
- Release 1.0: Jun 03, 2010 - Initial release
See 'ChangeLog.txt' in detail.
Copyright © 2010-2012 Kenji Urushima. All rights reserved.


Link Nudge jQuery Plugin::Demo
- Should be nudged.
- Should not be nudged.
- Should be nudged again.
- Nope, nothing here.

- Better try the one below for some nudgeness.
- Oh yeah, that's the spot.
Nudge the below list for alternate usage:
- Well, you can tell by the way I use my walk,
- I'm a woman's man, no time to talk.
- Music loud and women warm.
- I've been kicked around since I was born.


The agency
Elegant, unified, and a creative agency.
play_circle_outlinePlay video
Welcome to Ark!
We hope to dramatically improve customers’ lives and acquire new customers—or expand our relationship with existing customers—by designing effortless experiences for them.
About Us
Business & Creative Agency
We'll help you to build your future connected products and services.
Learn more about usA simple sleek interface
Our vision
It’s so important to deeply understand the type of customer you’re designing for.
100
Times Faster75
New Branches850
Weekly Downloads789
Items have Sold
Analyse, Understand
and
Improve
Done is better than perfect
It's at the heart of everything we do. From sticking to the deadlines we've agreed, right through to keeping the promises we've made and being both honest and transparent always about our business practises.
Responsive Design
Ark Responsive Web Design makes your web page look good on all devices (desktops, tablets, and phones) and fits everywhere.
More about Responsive DesignSmart Design
Ark Responsive Web Design makes your web page look good on all devices (desktops, tablets, and phones) and fits everywhere.
More about Responsive DesignDone is better than perfect
You’ve wrapped up a project, and now you’re ready to ship it. But then your mind starts racing: is it even good? Did I miss anything? Will people like it? Is it actually done?
Webinar Recap: Done is better than perfect
Nine Labs’ Brad Weaver covered the steps to getting more work out there more often—and how to build better
Responsive Design
Ark Responsive Web Design makes your web page look good on all devices (desktops, tablets, and phones) and fits everywhere.
More about Responsive Design
Our Amazing Work.
We
build
the real
value!
Email Address:
<EMAIL_ADDRESS>Number:
+123 456 7890
Address:
795 Folsom Ave, Suite 600, San Francisco, CA 94107
Contact us
Do you have other questions?
Just fill out the form below and we’ll get back to you as soon as possible (usually within one business day).


Installation¶
Compiling the low-level library¶
Although Fieldosophy is a Python package, much of its functionality is based on lower level functions written in C and C++. These are packaged into a dynamically linked library that needs to be compiled before installing the package.
Before compiling this library, some third-party libraries has to be installed on your system. These are:
- Eigen
Can be downloaded from: https://eigen.tuxfamily.org. Once installed, go to the “Makefile”-file in the main directory of Fieldosophy and point the variable “EIGENPATH” to the location of the “Eigen” directory of the Eigen library.
- GNU Scientific library
Can be donwloaded from: https://www.gnu.org/software/gsl. Make sure to install it such that the libraries and headers are available in the default search paths of the compiler.
When these libraries are installed and set up, compile the Fieldosophy library by typing “make” in the main directory of the Fieldosophy package. The libary-file should now reside in the “./fieldosophy/libraries” directory.
Installing the Python package¶
If fieldosophy’s low-level library has been compiled successfully and resides in the “./fieldosophy/libraries” directory, the Python package can be installed by typing: “pip install .”. Fieldosophy is now installed and can be imported in python using “import fieldosophy”.


This documentation refers to the devel (rev (rev not found)) release. Compiling nmag libraries and nmag from sourceWe assume that you are reasonable familiar with the install procedure. If not, look it up in installation instructions (method A). Download the latest overall tar file nmag-devel.tar.gz. Updating the nmag-core onlyAssuming you have downloaded nmag-devel.tar.gz before, and you just want an update of the nmag core (not the other libraries such as python, petsc, qhull, ...), then:
|


Toggle navigation
L
Parent has Submitted Goel..
M
Parent has Submitted Goel..
P
Parent has Submitted Goel..
View All Notifications
Pamela Sims
person
My Profile
settings
Settings
power_settings_new
Logout
stars
Services
stars
Add New Services
Download
Service ID
Service Name
Service Description
Action
1.
Window Cleaning
Neque porro quisquam est qui dolorem ipsum quia
2.
Commercial Cleaning
Contrary to popular belief, Lorem Ipsum is not simply
3.
Residential Cleaning
There are many variations of passages of Lorem
4.
Gutter Cleaning
This book is a treatise on the theory of ethics
5.
Professioanl Cleaning
Neque porro quisquam est qui dolorem ipsum quia
Show
10
Per Page
Showing 1-10 of 75


Search
Register
Log In
About Us
Products
Home
products
Home System
HD Television
Laptop
The perfect choice for your home appliance are....
here !!
Hot-Cold Water Dispenser
Serving Dishes
Oven
The perfect choice for your Office / business appliance are....
here !!
Dish Rack
Carpets
Curtains
Your one stop for all home and business appliances


Field Type Expansion in the Data Formatter Function¶
The specifications of the formatter functions provided in this sample are described.
For an overview of the formatter functions and more information on basic general data formatting functions, see the description for general data formatting functions in the Nablarch Application Framework manual.
Summary¶
When data linking double-byte characters of EBCDIC (CP930), a shift code may be added before and after the item. However, when data linking with a host computer, the shift code may not be added since it is assumed that the item starts in the shift out state even if it is a double-byte character.
Thus, depending on the interface with the connection destination system, the shift code may or may not be added and each case must be handled.
This sample provides a data type class for double-byte characters of EBCDIC (CP930) with a shift code, and a data type class for double-byte characters of EBCDIC (CP930) without a shift code.
Since it is assumed that the double-byte string data type (DoubleByteCharacterString) provided in Nablarch by default is used for input/output of the full-width characters (double-byte characters) field when the character code of the file is Shift_JIS or MS932, each project must expand when handling EBCDIC (CP930).
(Whether a shift code is added or not depends on the JDK, and CP930 used in the JDK must have a shift code added to double-byte characters.)
Since the shift code is added and removed transparently when this data type is used, it is possible to absorb the difference mentioned above and convert it into a string or encode it into a byte sequence.
Delivery package¶
The functions are provided in the below package.
please.change.me. core.dataformat.convertor.datatype
Structure of field type¶
The sample is an assumption that corresponds to both the case where a 2-byte string item in a fixed length file in EBCDIC (CP930) is assigned a shift code and the case where it is not assigned. Hence, the following field type classes are added.
The following is a list of classes used in this function.
Package name Class name Summary please.change.me. core.dataformat. convertor.datatype EbcdicDoubleByteCharacterString Data type class for double-byte strings of EBCDIC (CP930).It is used for input/output of full-width character (double-byte character) field of fixed-length data format.It is implemented as a data type that assumes the shift code is used for the input/output byte data.please.change.me. core.dataformat. convertor.datatype EbcdicNoShiftCodeDoubleByteCharacterString Data type class for double-byte strings of EBCDIC (CP930).It is used for input/output of full-width character (double-byte character) field of fixed-length data format.It is implemented as a data type that assumes the shift code is not used for the input/output byte data.
How to use the field type¶
When using the data type classes that have been added, it must be configured as follows. The data types “ESN” and “EN” have been added to the default configuration in the sample below.
<component name="fixedLengthConvertorSetting" class="nablarch.core.dataformat.convertor.FixedLengthConvertorSetting"> <property name="convertorTable"> <map> <!-- Add data types ESN and EN for EBCDIC (CP930) --> <entry key="ESN" value="please.change.me.core.dataformat.convertor.datatype.EbcdicDoubleByteCharacterString"/> <entry key="EN" value="please.change.me.core.dataformat.convertor.datatype.EbcdicNoShiftCodeDoubleByteCharacterString"/> <!-- The default configuration is given below --> <entry key="X" value="nablarch.core.dataformat.convertor.datatype.SingleByteCharacterString"/> <entry key="N" value="nablarch.core.dataformat.convertor.datatype.DoubleByteCharacterString"/> <entry key="XN" value="nablarch.core.dataformat.convertor.datatype.ByteStreamDataString"/> <entry key="Z" value="nablarch.core.dataformat.convertor.datatype.ZonedDecimal"/> <entry key="SZ" value="nablarch.core.dataformat.convertor.datatype.SignedZonedDecimal"/> <entry key="P" value="nablarch.core.dataformat.convertor.datatype.PackedDecimal"/> <entry key="SP" value="nablarch.core.dataformat.convertor.datatype.SignedPackedDecimal"/> <entry key="B" value="nablarch.core.dataformat.convertor.datatype.Bytes"/> <entry key="X9" value="nablarch.core.dataformat.convertor.datatype.NumberStringDecimal"/> <entry key="SX9" value="nablarch.core.dataformat.convertor.datatype.SignedNumberStringDecimal"/> <entry key="pad" value="nablarch.core.dataformat.convertor.value.Padding"/> <entry key="encoding" value="nablarch.core.dataformat.convertor.value.UseEncoding"/> <entry key="_LITERAL_" value="nablarch.core.dataformat.convertor.value.DefaultValue"/> <entry key="number" value="nablarch.core.dataformat.convertor.value.NumberString"/> <entry key="signed_number" value="nablarch.core.dataformat.convertor.value.SignedNumberString"/> <entry key="replacement" value="nablarch.core.dataformat.convertor.value.CharacterReplacer"/> </map> </property> </component>
Field type and field converter definition list¶
This section describes the field types that have been added.
Field type
Type identifier Java type Details ESN String Double-byte string (byte length = number of characters x 2 + 2 (shift code part))This sample performs right trim and padding with full-width empty space by default.During input, the shift-out/shift-in codes are assumed to be added and converted to a string without anything being done,while during output, the shift-out/shift-in codes are added automatically.Sample implementation class: please.change.me.core.dataformat.converter.datatype.EbcdicDoubleByteCharacterStringargument: Byte length (numerical value, specification required)EN String Double-byte string (byte length = number of characters x 2)This sample performs right trim and padding with full-width empty space by default.During input, the shift-out/shift-in codes are complemented internally and converted into a string,while during output, the shift-out/shift-in codes are not added.Sample implementation class: please.change.me.core.dataformat.converter.datatype.EbcdicNoShiftCodeDoubleByteCharacterStringargument: Byte length (numerical value, specification required)


| Package | Description |
|---|---|
| org.apache.hadoop.yarn.server.federation.policies |
Federation Policies.
|
| org.apache.hadoop.yarn.server.federation.policies.manager |
Various implementation of FederationPolicyManager.
|
| org.apache.hadoop.yarn.server.federation.store.records |
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.
|
| org.apache.hadoop.yarn.server.federation.store.records.impl.pb |
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.
|
| org.apache.hadoop.yarn.server.federation.utils |
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.
|
| Modifier and Type | Method and Description |
|---|---|
SubClusterPolicyConfiguration |
FederationPolicyInitializationContext.getSubClusterPolicyConfiguration()
Getter for the
SubClusterPolicyConfiguration . |
static SubClusterPolicyConfiguration |
FederationPolicyUtils.loadPolicyConfiguration(String queue,
org.apache.hadoop.conf.Configuration conf,
FederationStateStoreFacade federationFacade)
Get Federation policy configuration from state store, using default queue
and configuration as fallback.
|
| Modifier and Type | Method and Description |
|---|---|
void |
FederationPolicyInitializationContext.setSubClusterPolicyConfiguration(SubClusterPolicyConfiguration fedPolicyConfiguration)
Setter for the
SubClusterPolicyConfiguration . |
| Constructor and Description |
|---|
FederationPolicyInitializationContext(SubClusterPolicyConfiguration policy,
SubClusterResolver resolver,
FederationStateStoreFacade storeFacade,
SubClusterId home) |
| Modifier and Type | Method and Description |
|---|---|
SubClusterPolicyConfiguration |
WeightedLocalityPolicyManager.serializeConf() |
SubClusterPolicyConfiguration |
AbstractPolicyManager.serializeConf() |
SubClusterPolicyConfiguration |
PriorityBroadcastPolicyManager.serializeConf() |
SubClusterPolicyConfiguration |
HomePolicyManager.serializeConf() |
SubClusterPolicyConfiguration |
FederationPolicyManager.serializeConf()
This method is invoked to derive a
SubClusterPolicyConfiguration . |
| Modifier and Type | Method and Description |
|---|---|
abstract SubClusterPolicyConfiguration |
GetSubClusterPolicyConfigurationResponse.getPolicyConfiguration()
Get the policy configuration.
|
abstract SubClusterPolicyConfiguration |
SetSubClusterPolicyConfigurationRequest.getPolicyConfiguration()
Get the policy configuration assigned to the queue.
|
static SubClusterPolicyConfiguration |
SubClusterPolicyConfiguration.newInstance(String queue,
String policyType,
ByteBuffer policyParams) |
static SubClusterPolicyConfiguration |
SubClusterPolicyConfiguration.newInstance(SubClusterPolicyConfiguration conf) |
| Modifier and Type | Method and Description |
|---|---|
abstract List<SubClusterPolicyConfiguration> |
GetSubClusterPoliciesConfigurationsResponse.getPoliciesConfigs()
Get all the policies configured in the system.
|
| Modifier and Type | Method and Description |
|---|---|
static SubClusterPolicyConfiguration |
SubClusterPolicyConfiguration.newInstance(SubClusterPolicyConfiguration conf) |
static GetSubClusterPolicyConfigurationResponse |
GetSubClusterPolicyConfigurationResponse.newInstance(SubClusterPolicyConfiguration policy) |
static SetSubClusterPolicyConfigurationRequest |
SetSubClusterPolicyConfigurationRequest.newInstance(SubClusterPolicyConfiguration policy) |
abstract void |
GetSubClusterPolicyConfigurationResponse.setPolicyConfiguration(SubClusterPolicyConfiguration policyConfiguration)
Sets the policyConfiguration configuration.
|
abstract void |
SetSubClusterPolicyConfigurationRequest.setPolicyConfiguration(SubClusterPolicyConfiguration policyConfiguration)
Set the policyConfiguration configuration for the queue.
|
| Modifier and Type | Method and Description |
|---|---|
static GetSubClusterPoliciesConfigurationsResponse |
GetSubClusterPoliciesConfigurationsResponse.newInstance(List<SubClusterPolicyConfiguration> policyConfigurations) |
abstract void |
GetSubClusterPoliciesConfigurationsResponse.setPoliciesConfigs(List<SubClusterPolicyConfiguration> policyConfigurations)
Sets all the policies configured in the system.
|
| Modifier and Type | Class and Description |
|---|---|
class |
SubClusterPolicyConfigurationPBImpl
Protobuf based implementation of
SubClusterPolicyConfiguration . |
| Modifier and Type | Method and Description |
|---|---|
SubClusterPolicyConfiguration |
SetSubClusterPolicyConfigurationRequestPBImpl.getPolicyConfiguration() |
SubClusterPolicyConfiguration |
GetSubClusterPolicyConfigurationResponsePBImpl.getPolicyConfiguration() |
| Modifier and Type | Method and Description |
|---|---|
List<SubClusterPolicyConfiguration> |
GetSubClusterPoliciesConfigurationsResponsePBImpl.getPoliciesConfigs() |
| Modifier and Type | Method and Description |
|---|---|
void |
SetSubClusterPolicyConfigurationRequestPBImpl.setPolicyConfiguration(SubClusterPolicyConfiguration policyConfiguration) |
void |
GetSubClusterPolicyConfigurationResponsePBImpl.setPolicyConfiguration(SubClusterPolicyConfiguration policyConfiguration) |
| Modifier and Type | Method and Description |
|---|---|
void |
GetSubClusterPoliciesConfigurationsResponsePBImpl.setPoliciesConfigs(List<SubClusterPolicyConfiguration> policyConfigurations) |
| Modifier and Type | Method and Description |
|---|---|
SubClusterPolicyConfiguration |
FederationStateStoreFacade.getPolicyConfiguration(String queue)
Returns the
SubClusterPolicyConfiguration for the specified queue. |
| Modifier and Type | Method and Description |
|---|---|
Map<String,SubClusterPolicyConfiguration> |
FederationStateStoreFacade.getPoliciesConfigurations()
Get the policies that is represented as
SubClusterPolicyConfiguration for all currently active queues in
the system. |
Copyright © 2008–2020 Apache Software Foundation. All rights reserved.


lens Fix
Lens Designs
EVOLVE WITH STUDIO A is more than a set of courses. It is a compilation of all the secrets from Studio A's journey, for you to take inspiration and implement practically. Every course is tailored keeping your needs in mind, and most importantly the Industry's latest standards. Practicality is one thing we made sure stays on the top for we don't want you to just get inspired, but directly implement them in your routine.
This 2-day workshop is aimed to take you on a live shooting learning experience..
₹30,000
4 days of live experience with the masters who will take you on a journey to ...
₹30,000
Selva is the Lead Editor in Studio A, with over 8 years of solid experience
₹15,000
A 2-day-impact course that will elevate your art and business of photography.
₹3,800
From importing the pictures to editing them with the right tools/techniques
₹2,900
An impact course on creativity to elevate your business of life...
₹2,980
Lorem ipsum dolor sit amet consectetur adipisicing elit. Iusto provident qui tempore natus quos quibusdam soluta at.
Lorem ipsum dolor sit amet consectetur adipisicing elit. Iusto provident qui tempore natus quos quibusdam soluta at.
Lorem ipsum dolor sit amet consectetur adipisicing elit. Iusto provident qui tempore natus quos quibusdam soluta at.
Are you interested in LEARNING ? Every course is tailored keeping your needs in mind, and most importantly the Industry's latest standards. Practicality is one thing we made sure stays on the top for we don't want you to just get inspired, but directly implement them in your routine.
© 2021 phoARTography. All Rights Reserved. Images by GraphicBurger & Unsplash


Housing counselors near you
The counseling agencies on this list are approved by the U.S. Department of Housing and Urban Development (HUD), and they can offer independent advice about whether a particular set of mortgage loan terms is a good fit based on your objectives and circumstances, often at little or no cost to you. This list shows you several approved agencies in your area. You can find other approved counseling agencies at the Consumer Financial Protection Bureau’s (CFPB) website: consumerfinance.gov/mortgagehelp or by calling 1-855-411-CFPB (2372). You can also access a list of nationwide HUD-approved counseling agencies at: https://apps.hud.gov/offices/hsg/sfh/hcc/hcs.cfm
Find a housing counselor
Housing counselors throughout the country can provide advice on buying a home, renting, defaults, foreclosures, and credit issues. Using the search box below, you can find one near you. The counseling agencies on this list are approved by the U.S. Department of Housing and Urban Development (HUD) and they can offer independent advice about whether a particular set of mortgage loan terms is a good fit based on your objectives and circumstances, often at little or no cost to you. This list will show you several approved agencies in your area. There is also a list of nationwide HUD-approved counseling agencies {{ svg_icon( 'external-link' ) }}.
Displaying the {{ api_json.counseling_agencies | length }} locations closest to ZIP code {{ zipcode | escape }}
| Agency | Services | Distance |
|---|---|---|
|
|
{{ counselor.distance | round( 1 ) }} miles |
Paperwork Reduction Act statement
According to the Paperwork Reduction Act of 1995, an agency may not conduct or sponsor, and a person is not required to respond to a collection of information unless it displays a valid OMB control number. The OMB control number for this collection is 3170-0025 {{ svg_icon( 'external-link' ) }}. It expires on 04/30/2016. Using this tool to generate a list of HUD-Approved Housing Counseling Agencies is voluntary however, if you are an entity subject to 12 CFR § 1024 (78 FR 6856 (Jan. 31, 2013)), you are required to provide this list as specified in the regulation. Comments regarding this collection of information, including suggestions for improving the usefulness of the information, or suggestions for reducing the burden to respond to this collection should be submitted to the Consumer Financial Protection Bureau (Attention: PRA Office), 1700 G Street NW, Washington, DC 20552, or by email to PRA@cfpb.gov.


The crested newt is an amphibian that is red listed in Sweden. It usually becomes 10-16 cm long. They live most of the year on land, in forests and in wet meadows. It prefers to have plenty of dead woods and leaves where it can find food and hiding places. Stone rocks, blocks and caves contribute good wintering sites. The eggs are laid in April and May in smaller stagnant collections of that are free from fish. Like most other amphibians, the fry lives in the water and breathes with gills. After three to four months they develop bones and lungs, and walk on land. It is important that the water collections do not dry out before the fry has become so large that they can leave the water.
The crested newt is threatened by regrowth around the natural water collections, and the thickening and implantation of fish and crayfish. It has disappeared from many places where it previously existed in Sweden.
Is available and open source code for public.
Comprise a valuable source of elevation information data required for many engineering applications. In this case, it represents the possibilities of species migration in terrain’s surfaces. The source of data can be extracted from Google Earth TMImagery.
If the five mapping data are combined, the optimal solution for urbanization in 2050 can be mapped. Native resolution data are organized in array values which available as TIFF extension files. The authors believe that this technique is promising to increase the awareness for next generation. The user-friendly interface android application is also expected to be built and it can be implemented to other species.


--- title: Name product three excerpt: This product is product 3 date: 2021:07:21 ---
# stars
What do you like and dislike about this product?


SMAudioCodecConfiguration Class Reference
| Inherits from | NSObject |
|---|---|
| Declared in | SMAudioCodecConfiguration.h |
opusMaxAverageBitRate
Maxaveragebitrate specifies the maximum average receive bitrate of a session in bits per second (bit/s). The actual value of the bitrate can vary, as it is dependent on the characteristics of the media in a packet. Note that the maximum average bitrate MAY be modified dynamically during a session. Any positive integer is allowed, but values outside the range 6000 to 510000 SHOULD be ignored. If no value is specified, the maximum value will equals to corresponding mode of Opus and corresponding maxplaybackrate is the default. Decreasing MaxAverageBitRate will cause less bandwidth usage (For further information check RFC-7587).
@property (nonatomic) NSInteger opusMaxAverageBitRate
Discussion
Maxaveragebitrate specifies the maximum average receive bitrate of a session in bits per second (bit/s). The actual value of the bitrate can vary, as it is dependent on the characteristics of the media in a packet. Note that the maximum average bitrate MAY be modified dynamically during a session. Any positive integer is allowed, but values outside the range 6000 to 510000 SHOULD be ignored. If no value is specified, the maximum value will equals to corresponding mode of Opus and corresponding maxplaybackrate is the default. Decreasing MaxAverageBitRate will cause less bandwidth usage (For further information check RFC-7587).
MobileSDK default maxAverageBitRate=20000 6000 <= MaxAverageBitRate <= 510000 In case this value set as -1 WebRTC defaults will be use.
Declared In
SMAudioCodecConfiguration.h
ptime
Ptime is the preferred duration of media represented by a packet that a decoder wants to receive, in milliseconds rounded up to the next full integer value. For Opus, possible values are 3, 5, 10, 20, 40, 60, or an arbitrary multiple of frame size rounded up to the next full integer value, up to a maximum value of 120. If no value is specified, the default is 20. Changing ptime effects all audio codecs. Increasing Ptime will cause less bandwidth usage (For further information check RFC-7587).
@property (nonatomic) NSInteger ptime
Discussion
Ptime is the preferred duration of media represented by a packet that a decoder wants to receive, in milliseconds rounded up to the next full integer value. For Opus, possible values are 3, 5, 10, 20, 40, 60, or an arbitrary multiple of frame size rounded up to the next full integer value, up to a maximum value of 120. If no value is specified, the default is 20. Changing ptime effects all audio codecs. Increasing Ptime will cause less bandwidth usage (For further information check RFC-7587).
MobileSDK default ptime=60 3 <= MaxAverageBitRate <= 120 and it should be multiple of an Opus frame size rounded up to the next full integer value In case this value set as -1 WebRTC defaults will be use.
Declared In
SMAudioCodecConfiguration.h
opusDtx
Sets DTX value which will enable or disable Discontinuous Transmission feature of Opus codec. When using continuous transmission, Variable Bitrate will reduce the bitrate when the characteristics of the input signal permit, but it will never interrupt the transmission to the receiver. Therefore, the received signal will maintain the same high level of audio quality over the full duration of a transmission while minimizing the average bitrate over time. In cases where the bitrate of Opus needs to be reduced even further or in cases where only constant bitrate is available, the Opus encoder can use Discontinuous Transmission (DTX), where parts of the encoded signal that correspond to periods of silence in the input speech or audio signal are not transmitted to the receiver. A receiver can distinguish between DTX and packet loss by looking for gaps in the sequence number. On default DTX is disabled and enabling DTX will cause less bandwidth usage (For further information check RFC-7587). If application set dtxEnable parameter as ‘YES’ DTX will be enable, if application set it as ‘NO’ DTX will be disable.
@property (nonatomic) BOOL opusDtx
Discussion
Sets DTX value which will enable or disable Discontinuous Transmission feature of Opus codec. When using continuous transmission, Variable Bitrate will reduce the bitrate when the characteristics of the input signal permit, but it will never interrupt the transmission to the receiver. Therefore, the received signal will maintain the same high level of audio quality over the full duration of a transmission while minimizing the average bitrate over time. In cases where the bitrate of Opus needs to be reduced even further or in cases where only constant bitrate is available, the Opus encoder can use Discontinuous Transmission (DTX), where parts of the encoded signal that correspond to periods of silence in the input speech or audio signal are not transmitted to the receiver. A receiver can distinguish between DTX and packet loss by looking for gaps in the sequence number. On default DTX is disabled and enabling DTX will cause less bandwidth usage (For further information check RFC-7587). If application set dtxEnable parameter as ‘YES’ DTX will be enable, if application set it as ‘NO’ DTX will be disable.
MobileSDK default DTX is enabled
Declared In
SMAudioCodecConfiguration.h
opusFec
Sets FEC value which will enable or disable ForwardErrorCorrection feature of Opus codec. The voice mode of Opus allows for embedding in-band Forward Error Correction (FEC) data into the Opus bitstream. This FEC scheme adds redundant information about the previous packet (N-1) to the current output packet N. On the receiving side, the decoder can take advantage of this additional information when it loses a packet and the next packet is available. Disabling FEC cause cause less bandwidth usage (For further information check RFC-7587). If application set fecEnable parameter as ‘YES’ FEC will be enable, if application set it as ‘NO’ FEC will be disable.
@property (nonatomic) BOOL opusFec
Discussion
Sets FEC value which will enable or disable ForwardErrorCorrection feature of Opus codec. The voice mode of Opus allows for embedding in-band Forward Error Correction (FEC) data into the Opus bitstream. This FEC scheme adds redundant information about the previous packet (N-1) to the current output packet N. On the receiving side, the decoder can take advantage of this additional information when it loses a packet and the next packet is available. Disabling FEC cause cause less bandwidth usage (For further information check RFC-7587). If application set fecEnable parameter as ‘YES’ FEC will be enable, if application set it as ‘NO’ FEC will be disable.
MobileSDK default FEC is enabled
Declared In
SMAudioCodecConfiguration.h
opusMaxPlaybackRate
Sets the MaxPlaybackRate. Maxplaybackrate is a hint about the maximum output sampling rate that the receiver is capable of rendering in Hz. The decoder MUST be capable of decoding any audio bandwidth, but, due to hardware limitations, only signals up to the specified sampling rate can be played back. Sending signals with higher audio bandwidth results in higher than necessary network usage and encoding complexity, so an encoder SHOULD NOT encode frequencies above the audio bandwidth specified by maxplaybackrate. This parameter can take any value between 8000 and 48000, although commonly the value will match one of the Opus bandwidths . By default, the receiver is assumed to have no limitations, i.e., 48000. Decreasing MaxPlaybackRate will cause less bandwidth usage. Decreasing MaxPlaybackRate will cause less bandwidth usage (For further information check RFC-7587).
@property (nonatomic) NSInteger opusMaxPlaybackRate
Discussion
Sets the MaxPlaybackRate. Maxplaybackrate is a hint about the maximum output sampling rate that the receiver is capable of rendering in Hz. The decoder MUST be capable of decoding any audio bandwidth, but, due to hardware limitations, only signals up to the specified sampling rate can be played back. Sending signals with higher audio bandwidth results in higher than necessary network usage and encoding complexity, so an encoder SHOULD NOT encode frequencies above the audio bandwidth specified by maxplaybackrate. This parameter can take any value between 8000 and 48000, although commonly the value will match one of the Opus bandwidths . By default, the receiver is assumed to have no limitations, i.e., 48000. Decreasing MaxPlaybackRate will cause less bandwidth usage. Decreasing MaxPlaybackRate will cause less bandwidth usage (For further information check RFC-7587).
MobileSDK default MaxPlaybackRate=16000
8000 <= maxPlaybackRate <= 48000 In case this value set as -1 WebRTC defaults will be use.
Declared In
SMAudioCodecConfiguration.h
+ configurationWithMobileSDKPreferredSet
Init SMAudioCodecConfiguration with MobileSDK preferred sets. If an application use this configuration MobileSDK will modify the Audio Codec parameters automatically with it’s preferred set.
+ (instancetype)configurationWithMobileSDKPreferredSet
Discussion
Init SMAudioCodecConfiguration with MobileSDK preferred sets. If an application use this configuration MobileSDK will modify the Audio Codec parameters automatically with it’s preferred set.
Declared In
SMAudioCodecConfiguration.h
+ configurationWithWebRTCDefaultSet
Init SMAudioCodecConfiguration with WebRTC default sets. If an application use this configuration MobileSDK will not modify the Audio Codec parameters automatically.
+ (instancetype)configurationWithWebRTCDefaultSet
Discussion
Init SMAudioCodecConfiguration with WebRTC default sets. If an application use this configuration MobileSDK will not modify the Audio Codec parameters automatically.
Declared In
SMAudioCodecConfiguration.h
– getOpusFMtpLine
This method will return the opus fmtp line parameters which will be in the fmtp line of SDP. Only Utils in WebRTC should call this method. Using this method Utils will modify the SDP and bitrate will decrease.
- (NSString *)getOpusFMtpLine
Return Value
String fmtpLine
Discussion
This method will return the opus fmtp line parameters which will be in the fmtp line of SDP. Only Utils in WebRTC should call this method. Using this method Utils will modify the SDP and bitrate will decrease.
Declared In
SMAudioCodecConfiguration.h


cowboy_route_match() = '_' | iodata()
cowboy_route_path() = {Path::cowboy_route_match(), Handler::module(), Opts::any()}
url() = string()
| get_recent/1 | Fetches a record from the recorder FIFO queue. |
| start/0 | Starts a stubby server with default configuration. |
| start/1 | Starts a stubby server with optional routes. |
| start/2 | Starts a stubby server with optional hostname and routes configurations. |
| stop/0 | Stops a running stubby server. |
get_recent(Path::string()) -> stubby_recorder:result()
Fetches a record from the recorder FIFO queue. If empty, the call is blocked until the next enqueue.
start() -> url()
Starts a stubby server with default configuration.
start(Routes::[cowboy_route_path()]) -> url()
Starts a stubby server with optional routes.
start(Host::string(), Routes::[cowboy_route_path()]) -> url()
Starts a stubby server with optional hostname and routes configurations.
stop() -> ok
Stops a running stubby server.
Generated by EDoc


Help
Community
Community Server
Overcast on Github
Translations
Download
Community Server
Community server coming soon...


You need to login in at PheKB.org in order to do that.
You don't have access to that. Click below to start a new phenotype.
Get Started
Make your phenotype definition portable across different institutions by representing it in a standard format.


{% include 'menu.html' %}
Welcome to my contact book
{% if 'user' in session %}
You are logged in as {{ session['user'] }}
To logout click
here
{% else %}
Login
Enter your username:
Enter your password:
{% endif %}


Game Realm
GitHub repository: https://github.com/RyanEllingson/nurd
Deployed App: https://nurd-game-realm.netlify.com/
Busi
GitHub repository: https://github.com/RyanEllingson/Busi
Deployed App: https://ryan-busi.herokuapp.com/index.html
Brew Cruze
GitHub repository: https://github.com/RyanEllingson/Squirtle-Squad
Deployed App: https://ryanellingson.github.io/Squirtle-Squad/
Burger
GitHub repository: https://github.com/RyanEllingson/Burger
Deployed App: https://ryan-burger.herokuapp.com/
Team Profile Generator
GitHub repository: https://github.com/RyanEllingson/Team-Profile-Generator
Weather Dashboard
GitHub repository: https://github.com/RyanEllingson/Weather-Dashboard
Deployed App: https://ryanellingson.github.io/Weather-Dashboard/
Code Quiz
GitHub repository: https://github.com/RyanEllingson/Code-Quiz
Deployed App: https://ryanellingson.github.io/Code-Quiz/