| 54 | |
| 55 | In addition to activating record approval for a table, you will also need to give user roles permission to review/approve/reject records in this table. |
| 56 | |
| 57 | These permissions are encoded as auth.permission.REVIEW (permission to access unapproved records) and auth.permission.APPROVE (permission to approve or reject unapproved records). |
| 58 | |
| 59 | {{{ |
| 60 | acl = current.auth.permission |
| 61 | acl.update_acl(ROLE_XY, |
| 62 | t="some_table", |
| 63 | uacl=acl.READ|acl.CREATE|acl.REVIEW|acl.APPROVE, |
| 64 | oacl=acl.READ|acl.UPDATE|acl.REVIEW|acl.APPROVE) |
| 65 | |
| 66 | }}} |
| 67 | |
| 68 | ''Note:'' that users can have review permission (=permission to ''see'' unapproved records) without need to also have approve/reject permission. |
| 69 | |
| 70 | ''Note:'' REVIEW permission alone doesn't give any access to unapproved records: it merely extends the READ/UPDATE permissions so they also apply for unapproved records. That means, if the user besides REVIEW has only READ permission in this table, then they can ''read'' unapproved records but not update them. To do that, they would need REVIEW+UPDATE permission. |
| 71 | |
| 72 | The permission to review/approve/reject records of this role is realm-limited (see [wiki:S3AAA/OrgAuth] for more details). |
| 73 | |
| 74 | Admin can always see all records, regardless whether they are approved or not. Other users can only see approved records, unless they have the approver role and use one of the approval methods "review", "approve", "reject". |