Allura has an admin interface at http://MYSITE/nf/admin/ You must be an admin of the
/p/allura project on the site to access it. If you want to use another project to control
admin access, change the site_admin_project
setting in :file:`development.ini`.
The admin interface allows you to:
You can set up logo to be displayed in the top left corner of the site.
Add the following to your :file:`development.ini`:
[app:main] ... logo.link = / ; link to attach to the logo (optional, defaults to "/") logo.path = sf10a.png ; fs path to the logo image, relative to Allura/allura/public/nf/images/ logo.width = 78 ; logo width in pixels (optional) logo.height = 30 ; logo height in pixels (optional)
Allura has many commands and scripts that can be run from the server commandline to
administrate Allura. There are also tasks that can be run through the taskd
system
in the background. These tasks can be submitted via the web at
http://MYSITE/nf/admin/task_manager Some paster scripts have been set up
so that they are runnable as tasks too, giving you the convenience of starting
them through the web and letting taskd
execute them, rather than from a server
shell.
Commands can be discovered and run via the paster
command when you are in the
'Allura' directory that has your .ini file. For example:
paster help ... all commands listed here ... paster create-neighborhood --help ... specific command help ... paster create-neighborhood development.ini myneighborhood myuser ...
Scripts are in the :file:`scripts/` directory and run slightly differently, via paster script
. An extra
:kbd:`--` is required to separate script arguments from paster arguments. Example:
paster script development.ini ../scripts/add_user_to_group.py -- --help ... help output ... paster script development.ini ../scripts/add_user_to_group.py -- --nbhd /u/ johndoe Admin
To run these when using docker, prefix with docker compose run taskd
and use :file:`docker-dev.ini` like:
docker compose run --rm taskd paster create-neighborhood docker-dev.ini myneighborhood myuser ...
Or with the docker production setup:
docker compose run --rm oneoff paster create-neighborhood /allura-data/production.ini myneighborhood myuser ...
Tasks can be run via the web interface at http://MYSITE/nf/admin/task_manager You must know
the full task name, e.g. allura.tasks.admin_tasks.install_app
You can
optionally provide a username and project and app which will get set on the
current context (:kbd:`c`). You should specify what args and kwargs will be passed
as parameters to the task. They are specified in JSON format on the form. If you are
running a script via this interface, the :kbd:`args/kwargs` JSON should be like:
{ "args": ["--foo --bar baz"], "kwargs": {} }
See the listing of :mod:`some available tasks <allura.tasks.admin_tasks>`.
Available scripts and commands are:
Blog tools may optionally be configured to fetch external RSS feeds. If that is in place, this command should be used to fetch all those rss feeds and convert new entries into blog posts.
Requires html2text, a GPL library.
cd ../ForgeBlog paster pull-rss-feeds development.ini --help
Can be run as a background task using task name: allura.scripts.disable_users.DisableUsers
Can be run as a background task using task name: allura.scripts.delete_projects.DeleteProjects
More convenient way to delete project is :ref:`this site admin page <delete-projects>`. It uses this script under the hood.
Can be run as a background task using task name: allura.scripts.refreshrepo.RefreshRepo
Can be run as a background task using task name: allura.scripts.reindex_projects.ReindexProjects
Can be run as a background task using task name: allura.scripts.reindex_users.ReindexUsers
Can be run as a background task using task name: allura.scripts.create_sitemap_files.CreateSitemapFiles
Can be run as a background task using task name: allura.scripts.clear_old_notifications.ClearOldNotifications
Cannot currently be run as a background task.
Cannot currently be run as a background task.
Allura has support for site-wide notifications that appear below the site header. UI for managing them can be found under "Site Notifications" in the left sidebar on the :ref:`site admin interface <site-admin-interface>`.
For example, setting available options to:
Active: ✓
Impressions: 10
Content: You can now reimport exported project data.
User Role: Developer
Page Regex: (Home|browse_pages)
Page Type: wiki
will create a notification that will be shown for 10 page views or until
the user closes it manually. The notification will be shown only for users
which have role 'Developer' or higher in one of their projects. And if url of
the current page is matching regex (Home|browse_pages)
and app
tool type is wiki
. An "Impressions" value of 0 will show the
notification indefinitely (until closed). The notification content can contain
HTML. The most recent notification that is active and matches for the visitor
will be shown. "User Role", "Page Regex" and "Page Type" are optional.
Site administrators can delete projects using web interface. This is running :ref:`delete_projects.py script <delete-projects-py>` under the hood. You can access it choosing "Delete projects" from the left sidebar on the :ref:`site admin interface <site-admin-interface>`.
Be careful, projects and all related data are actually deleted from the database!
Just copy and paste URLs of the project you want to delete into "Projects"
field, separated by newlines. You can also use nbhd_prefix/project_shortname
or just project_shortname
format, e.g.
http://MYSITE/p/test3/wiki/ p/test2 test
will delete projects test3
, test2
and test
.
NOTE: if you omit neighborhood prefix project will be matched only if
project with such short name are unique across all neighborhoods, i.e. if you
have project with short name test
in p2
neighborhood and
project with the same short name in p
neighborhood project will not be
deleted. In this case you should specify neighborhood explicitly to
disambiguate it.
The "Reason" field allows you to specify a reason for deletion, which will be logged to disk.
"Disable all project members" checkbox disables all users belonging to groups "Admin" and "Developer" in these projects. The reason will be also recorded in the users' audit logs if this option is checked.
After clicking "Delete" you will see a confirmation page. It shows which projects are going to be deleted and which are failed to parse, so you can go back and edit your input.
We currently don't have any further documentation for basic operations of managing users, projects, and tools on Allura. However, SourceForge has help docs that cover these functions https://sourceforge.net/p/forge/documentation/Docs%20Home/ Note that this documentation also covers some SourceForge features that are not part of Allura.
All url endpoints are prefixed with /rest/ and the path to the project and tool.
For example, in order to access a wiki installed in the 'test' project with the mount point 'docs' the API endpoint would be /rest/p/test/docs.
Explore Allura's REST API documentation here. You can also try the API live there.
Allura includes some client scripts that demonstrate use of the Allura REST API and do not have to be run from an Allura environment. They do require some python packages to be installed, though.
Illustrates creating a new ticket, using the simple OAuth Bearer token.