Forum - Collaboration

Introduction

Forums are usually associated with different business objects in ]po[. In a standard installation Forums can be associated to the following objects: Projects Companies (Customers, Providers, Partners, …) Offices Users (Freelancers, Customer contacts, …) All forum items appear in the forum where they have been created.

Home Forum

The "Home Forum" acts like a like a kind of “inbox”. All unread items from all other forums appear here. Once an item has been read it will not be shown anymore in this list.

Forum Main Page

Finally, there is the "Forum main page" that you can access via the “Forum” tab in the main menu. This page shows you the list of all forum items of all projects (or business object). Also, there are two submenus for

  • Deleted Items and
  • Unresolved Items

Creating Forum Tasks

To create a Forum Task click on the "Tick" icon of an arbitrary Forum. 

 

Creating other Forum Topics

In the above example we explained the creation of a “Task” topic. Besides “Tasks” the Forum Module manages furthermore • Incidents • Discussions, • News and • Notes The basic structure of these topics is very similar to each other although each of them consists of a different set of attributes. Depending on the topic type they might start back office actions as for example email notifications. In that sense incidents can be regarded similar to tasks. News and Notes usually don’t execute email notifications of any type if not expressively desired. You will learn more about the different topic types when studying the attributes in the following chapter

Forum Attributes

A topic type consists of a combination of attributes. It can be distinguished in between common attributes that are part of all topic types and type specific attributes that are members only of some topics types.

Understanding Topic Attributes

  • Subject:
    Subject is the principle title of topic. Users decide based on the title if the content of the topic is of any use for them or not. It therefore should be chosen in a way that the reader immediately get a clear idea.
  • Posted In:
    Specifies the parent project of this topic. All are related to a project or some other P/O business object. Attribute: Posted By: Specifies the owner of this topic. Attribute: Status: Relevant only to tasks and incidents: Show whether the task or incident has been accepted by the assignee or whether it is pending. The task states correspond to the actions in Table 2.
  • Posting Date:
    Shows the generation date of the topic.
  • Priority:
    Indicates the urgency of a task or incident. Priority is represented by a number between 1 and 9 with 1 indicating a very urgent task and 9 indicating the least urgency.
  • Assigned to:
    Tasks and incidents can be assigned to other project members for resolution. This field shows the person who is currently responsible for resolving the task.
  • Due Date:
    Shows the deadline for the resolution of a task or incident. Tasks that are not “resolved” after the deadline are rendered in red.
  • Visible for:
    Specifies the access permission for this topic. Please see the section “Understanding Permissions” below for more details.
  • Receive updates?:
    This attribute allows you to specify whether you want to receive email alerts for this topic. You can choose between the following types:
    a) All: Receive email notification about all changes to the topic.
    b) Important updates: Only important modification are communicated, such as closing or canceling a task or incident..
    c) No updates: You don’t want to receive any notifications about this topic.
  • Body:
    The Body element contains the main message text. It can hold up to 4000 characters. Attribute: Action: Show the available actions for the given topic.

Forum Notifications

Notifications are emails that are sent to project members when a forum item is modified. This allows for active discussions that are very similar to an email mailing list, but that leave a track record saved on the system for reference

  • All project members become “subscribed” when somebody creates a new forum item (depending on your permissions, as explained in the next chapter)
  • All subscribed members receive email updates if a forum item is modified However, every project member can determine how many updates they will receive about a forum item. The “receive updates” status is shown when viewing a forum item (see figure 3 above) and can be modified when editing a forum item. There are the following options:
  • All Updates: You will receive email updates for all modifications of the forum item
  • No Updates
  • Important Updates: Important updates limit the email notifications to important changes. Important changes are: Closing an item, marking a task or incident as “resolved”. Replies to the initial forum topic or resignations of a task or incident are not important. In the future, ]project-open[ will support the option to group several notifications into a single email message (“Bulletins”).

Forum Permissions

Forum permissions are built around a metaphor of three different “communication spheres” in a project:

  • Clients
  • Company Staff and
  • Providers/Freelancers

This model resembles the situation that a company had to recur to external providers in order to execute a specific project. However, the client shouldn’t necessarily notice that there are external persons involved. The Forum Module approach to this situation is to introduce permissions for each Forum topic. One specific topic can have the permission levels:

  • Project Manager: This is the most restricted permission. This topic is only visible to the project manager (apart from the owner who created this topic).
  • Staff: This topic is only visible for in-house staff.
  • Staff and Providers: This topic is visible for everybody but clients.
  • Clients and PM: This topic is only visible in the clients sphere.
  • Everybody in the Project: This topic is visible to all three communication spheres
  • Public: Everybody in the system. This permission is for company wide news or incidents. 

 

However, not everybody in the system has the right to create topics with all of these permission levels.
The system administrator defines these permissions. The table below shows a typical default configuration:

   Project
Manager
 Staff  Staff and
Providers
 Clients
and PM
 Whole
Project
 Public
Customers
 X      X    
Freelancer  X    X      
Employees  X  X  X      
Project Managers  X  X  X  X    
Senior Managers  X  X  X  X  X  
System Admins  X  X  X  X  X  X

This means that customers by default can only communicate amongst themselves and the Project Manager. However, they can’t communicate with the freelancers who are working in the same project.
Freelancers or Providers on the other hand can communicate amongst themselves and with staff members. However, they have no way to get into contact with customers.
In the middle of these communication spheres is the Project Manager who can see all communication. The PM can act as a bridge between Clients and Providers and route communication amongst them as we will see in the next chapters. 


Permission rules for Incidents

All registered users are possesses the right to post incidents, although freelancers and costumers are not able to assign incidents to any another person then to the PM. Neither are they are allowed to define “Access Permissions”. An incident logged by a costumer or a freelancer is by default pre-assigned to the PM. The PM can then re-assign the item to a suitable.  

  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

E-08907 Hospitalet de Llobregat (Barcelona)

 Tel Europe: +34 932 202 088
 Tel US: +1 415 429 5995
 Mail: info@project-open.com