diff --git a/doc/api/need_action_specs.rst b/doc/api/need_action_specs.rst
index 1be92586e7f..c5c44419362 100644
--- a/doc/api/need_action_specs.rst
+++ b/doc/api/need_action_specs.rst
@@ -1,14 +1,14 @@
 Need action mechanism
 =====================
 
-base.needaction mixin class
-+++++++++++++++++++++++++++
+ir.needaction mixin class
+++++++++++++++++++++++++++
 
 This revision adds a mixin class for objects using the need action feature.
 
 Need action feature can be used by objects willing to be able to signal that an action is required on a particular record. If in the business logic an action must be performed by somebody, for instance validation by a manager, this mechanism allows to set a list of users asked to perform an action.
 
-This class wraps a table (base.needaction_users_rel) that behaves like a many2many field. However, no field is added to the model inheriting from base.needaction. The mixin class manages the low-level considerations of updating relationships. Every change made on the record calls a method that updates the relationships.
+This class wraps a class (ir.needaction_users) that behaves like a many2many field. However, no field is added to the model inheriting from base.needaction. The mixin class manages the low-level considerations of updating relationships. Every change made on the record calls a method that updates the relationships.
 
 Objects using the need_action feature should override the ``get_needaction_user_ids`` method. This methods returns a dictionary whose keys are record ids, and values a list of user ids, like in a many2many relationship. Therefore by defining only one method, you can specify if an action is required by defining the users that have to do it, in every possible situation.
 
diff --git a/openerp/addons/base/ir/ir_needaction.py b/openerp/addons/base/ir/ir_needaction.py
index ae13cc40900..391a0c2e3ff 100644
--- a/openerp/addons/base/ir/ir_needaction.py
+++ b/openerp/addons/base/ir/ir_needaction.py
@@ -92,7 +92,7 @@ class ir_needaction(osv.osv):
     validation by a manager, this mechanism allows to set a list of
     users asked to perform an action.
     
-    This class wraps a table (ir.needaction_users) that behaves
+    This class wraps a class (ir.needaction_users) that behaves
     like a many2many field. However, no field is added to the model
     inheriting from base.needaction. The mixin class manages the low-level
     considerations of updating relationships. Every change made on the