Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
- Timestamp:
-
03/14/12 12:05:26 (12 years ago)
- Author:
-
jmoore
- Comment:
-
Updating after discussion in devteam about the choice between canAnnotate(event, call) and just canAnnotate()
Legend:
- Unmodified
- Added
- Removed
- Modified
-
|
v2
|
v3
|
|
| 3 | 3 | This work includes: |
| 4 | 4 | * Add methods `canLink` and `canEdit` |
| 5 | | * ~~Add the call context map to the permissions object~~ (see "Storing context" below) |
| | 5 | * Add the call context, the event context, and the client/session object to the details of all objects. |
| 6 | 6 | * Make the default object factory for permissions return a non-editable version |
| 7 | 7 | * Perform the adjustment before returning any objects. Unloaded objects will not have permission objects, and therefore will need to be reloaded by the user. |
| 8 | 8 | |
| 9 | 9 | See: https://www.openmicroscopy.org/site/community/minutes/minigroup/2012.03.12-groupperms |
| 10 | | |
| 11 | | === Storing Context === |
| 12 | | |
| 13 | | It would be possible to add the callcontext (#3527) to the permissions object as an `Ice.Context` string-string-map, but this might only make sense with the `EventContext` itself. However, it's not possible to have an `EventContext` in the `Permissions` object because there's already a `Permissions` object in the `EventContext` object (i.e. cyclical dep). Instead, we could move both of these context fields to `Details`, but then it's no longer possible for the `Permissions` object to make use of them in making decisions. Ergo, it's probably not that useful, and I won't worry about it for the minute. It's then the '''client's responsibility''' to keep up with the mapping from objects to the context that they were acquired from. |
1.3.13-PRO © 2008-2011
Agilo Software all
rights reserved
(this page was served in: 0.23188 sec.)
