refstack/specs/mitaka/implemented/user-group.rst
Luz Cazares eebbd714f1 Fix specs format to improve rendered documentation
Several existing Refstack specs doesn't have the spec
name header resulting in a bad documentation formatting.
Added or fixed spec name headers under existing spec
folder so that documentation is rendered and displayed
correctly.

Change-Id: I20d0c140ddc132fad90e2b7152c71599a22a1dd8
2016-08-10 22:35:00 +00:00

193 lines
4.9 KiB
ReStructuredText
Executable File

=================================
User Group Support in RefStack
=================================
Launchpad blueprint: https://blueprints.launchpad.net/refstack/+spec/vendor-result-validation
Requirement document: https://goo.gl/bvo4FG
Data model document: https://goo.gl/zWYnoq
This spec proposes RefStack to add user group support.
Problem description
===================
As RefStack implements the vendor/product entities, RefStack needs to allow
management and visibility of these entities to a group of users not just the
user who creates the entities.
Proposed change
===============
Add the following tables to the RefStack database:
* A table named "group".
* A table named "user_to_group".
Details about these tables are described in the "Data model impact" section.
Add methods to support:
* Add a user to a group by inserting a record into the "user_to_group" table.
* Remove a user from a group
**Note:**
* Only an interop user or a user in this group can perform the action of adding a user to a group.
* Only an interop user, a user in this group, or the user himself/herself can remove a user from the group.
* In the current implementation, all users in a group are admin users with CRUD privilege.
Alternatives
------------
Alternatively, a 'role' column can be added to the user_to_group table to support
having users with different roles in a group. The various 'roles' can be
defined in a policy file.
Open to other suggestions.
Data model impact
-----------------
The following tables will be added to the RefStack database.
* "group" table
+------------------------+-------------+----------+
| Column | Type | |
+========================+=============+==========+
| created_at | datetime | |
+------------------------+-------------+----------+
| updated_at | datetime | |
+------------------------+-------------+----------+
| deleted_at | datetime | |
+------------------------+-------------+----------+
| deleted | int(11) | |
+------------------------+-------------+----------+
| id | varchar(36) | PK |
+------------------------+-------------+----------+
| name | varchar(80) | |
+------------------------+-------------+----------+
| description | text | |
+------------------------+-------------+----------+
**Note:**
The values in the "id" column are GUIDs generated with UUID4.
* "user_to_group" table
+------------------------+-------------+----------+
| Column | Type | |
+========================+=============+==========+
| created_at | datetime | |
+------------------------+-------------+----------+
| updated_at | datetime | |
+------------------------+-------------+----------+
| deleted_at | datetime | |
+------------------------+-------------+----------+
| deleted | int(11) | |
+------------------------+-------------+----------+
| created_by_user | varchar(128)| |
+------------------------+-------------+----------+
| _id | int(11) | PK |
+------------------------+-------------+----------+
| group_id | varchar(36) | FK |
+------------------------+-------------+----------+
| user_openid | varchar(128)| FK |
+------------------------+-------------+----------+
**Note:**
Since more than one users (an interop user or a user in this group) can add
a user to a group, the created_by_user field was added for auditing purpose.
REST API impact
---------------
None.
No REST API will be implemented in the initial phase because a group will only
be created implicitly when an organization is created. No "group management"
features will be exposed to the end users.
Security impact
---------------
Previously private entities such as test results can only be viewed/managed by
the owner user. The group implementation allows a group of users to
view/manage those entities.
Notifications impact
--------------------
None, for the initial implementation. In the future, RefStack may want to
notify the related parties (users or organizations) whenever a user is added to
or removed from a group.
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Andrey Pavlov
Other contributors:
TBD
Work Items
----------
* Create database tables.
* Create the specified private methods.
Dependencies
============
None
Testing
=======
None
Documentation Impact
====================
None
References
==========
None