Assembla Development

You can use the tool extension system to add new tools (tabs). You can put all files to define a new tool in a subdirectory on the /vendor/extensions directory. The system will read app/controllers, app/views, and other rails directories from inside this subdirectory.

How does a tool become part of a workspace?

Two things make a tool or external application part of a workspace. First, the permissions are integrated. A user that is in the team list should have the correct permissions in the tool – None, View, Edit, All. Second, the tool can show important events on the Stream page and in alerts.

Generate new tool

Create new tools using Rails engines

• Add it to config/tools.yml So it becomes available in the Admin/Tools page.
• Implement your own logic.

Configure or remove event type and processing

Every tool can define new event types, that show up on the sidebar of the Stream page. Each event type can have “decorators” – code that formats it on the Stream page, in an email alert, or in an RSS alert. Every tool can also define event processors that receive events. Learn more about event processors here. We added template code for the events, the decorators, and the processors.

Configure for inbound emails

You can optionally have your tool accept inbound emails and incorporate them. To do this, please refer to Email_gateway.

Enabling the tool

To add the tool to the list of the space active tools, you need to add a record for it in the breakout tools registry: breakout/config/tools.yml. The tool record is composed from tool id, order, category and other optional fields. By example, if the class name of your tool model is MyNewTool, and you want it in REPOSITORIES category between External Subversion and GitHub tools, your record should look like:

my_new_tool:
  order: 245
  category: SpaceTool::Categories::REPOSITORIES

Using the Assembla permission system

A user can have four kinds of permission for a tool

• NONE – they should be redirected to a “Not permitted” page
• VIEW – they should be able to see the content of the tool. They should not have the ability to edit, or any edit controls *
• EDIT – they can add and edit items in the tool. They cannot see settings or special controls.
• OWN – they can edit the tool settings, and have other special controls You will need to set filters that control access to tool actions that require VIEW, EDIT, or OWN privileges.

# At the top of your controller class
# list the permissions required for each action.  This example is from our wiki controller
  before_filter :has_all_permission_filter, :only => [:delete, :settings]
  before_filter :has_edit_permission_filter, :only => [:new, :create, :edit, :update, :rollback, :delete_version,
          :list, :order_wiki_pages, :xxx_update, :manage]
  before_filter :has_view_permission_filter, :only => [:show, :show_blank, :show_version, :history, :add_comment,
          :show_add_comment,:print, :extern, :no_extern]

You should modify your views to only show buttons and links that are available for the current user’s permission. You can get the permissions for the current user with:

############
# for example #
############
<%= if has_view_permission -%>
  show this data to everybody
<% end -%>

<%= if has_edit_permission -%>
  show my fields (the ones that belong to the current user) as data entries
<% end -%>

<%= if has_all_permission -%>
  show all fields as data entries
<% end -%>

Current user checks

# is the current user logged in?
<% if anonymous? -%>
  this is an anonymous user
<% end -%>

# dump the data structures of the current user
<%= current_user.inspect %>