Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History
New Proposal Template
  • A user CAN be member of one or more roles
  • A role CAN be the parent of one or more other roles
  • An object CAN be assigned to one or more roles
  • If a user is member of a role (or any of the role's childs) to which the
    requested object was assigned, the user MUST be allowed access. Otherwise, MUST NOT.

Following example based on:

Object 1 -----\ /------User 1
\ /
= H E A L E R == ---------User 2
/ | \
Object 2 -----/ ^ ------User 3


Object 3 -----\ ^ /------User 4
\ | /
== I N T E R N == ---------User 5
/ | \
Object 4 -----/ ^ ------User 6


Object 5 -----\ ^ /-------User 7
\ | /
== D O C T O R == ---------User 8
/ \
Object 6 -----/ -------User 9

Interns can do everything a healer can do
Doctors can do everything an intern can

Healers have access to object 1 & 2 only
Interns have access to object 1, 2, 3 & 4 only
Doctors have access to object 1, 2, 3, 4, 5 & 6 only

$rbac = new Zend_Rbac();

$rbac->assign('intern', 'user4');
$rbac->assign('intern', 'user5');
$rbac->assign('intern', 'user6');

$rbac->assign('doctor', array('user7','user8','user9');

$rbac->setChild('intern', 'healer'); // <parent>, <child>
$rbac->setChild('doctor', 'intern');

$rbac->subscribe('healer', array('object1', 'object2');
$rbac->subscribe('intern', array('object3', 'object4');
$rbac->subscribe('doctor', array('object5', 'object6');

$rbac->isAllowed('user1', 'object1'); // True
$rbac->isAllowed('user1', 'object3'); // False
$rbac->isAllowed('user4', 'object1'); // True
$rbac->isAllowed('user4', 'object3'); // True
$rbac->isAllowed('user4', 'object5'); // False
$rbac->isAllowed('user9', 'object1'); // True
$rbac->isAllowed('user9', 'object3'); // True
$rbac->isAllowed('user9', 'object5'); // True

No placeholders allowed!
Please do not create placeholders. Wait until you have sufficient content to replace all sample data in the proposal template before creating your proposal document.

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Magic Component Proposal

Proposed Component Name Zend_Magic
Developer Notes
Proposers My Name
Zend Liaison TBD
Revision 1.0 - 1 January 2008: Initial Draft. (wiki revision: 1)

Table of Contents

1. Overview

Zend_Magic is a simple component that reads my mind and generates code dynamically to do what I want.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.

  • This component will correctly reads a developers mind for intent and generate the right configuration file.
  • The generated config file will not support XML, but will provide an extension point in the API.
  • This component will use no more memory than twice the size of all data it contains.
  • This component will include a factory method.
  • This component will not allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
  • This component will only generate data exports strictly complying with RFC 12345.
  • This component will validate input data against formats supported by ZF component Foo.
  • This component will not save any data using Zend_Cache or the filesystem. All transient data will be saved using Zend_Session.

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

The component is instantiated with a mind-link that ...

6. Milestones / Tasks

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

  • Zend_Magic_Exception
  • Zend_Magic (factory class)
  • Zend_Magic_MindProbe
  • Zend_Magic_MindProbe_Intent
  • Zend_Magic_Action
  • Zend_Magic_CodeGen

8. Use Cases


... (see good use cases book)

9. Class Skeletons


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.