# Multi Location Permissions ## TODO 1. Discuss with PM * The 'office' collection and the Global Location Filter. * The Team and Member pages - what will be seen and what not, and what else should be hidden. 2. Migrate permissions out of Organization * Check for references to `oranization.permissions`. * The new collection name should be `userRoles` * Check how used is the `PermissionManager` as we have to rework it. 4. Introduce `restLocations` permission with options `no access` and `viewer` and UI to set it for a teammate. 5. Enable GET requests for rest locations viewer for `members` and `teammates`. * New `LocationBasedController` (`MultiLocationControllerBase`) that changes the way we build the get query for the DB. 7. Protect CUD requests for `members` and `teammates`. * Implement descriptor functions for req params and add them to AuthDecorator 9. Protect UI buttons for CUD requests. * Add `perm-context` to the `perm` directive. ## Spike Discussion **I. API ENDPOINTS** 1. Expose only `members` and `teams` API endpoints for multi location read. 2. MAJOR QUESTION: Should we expose the `offices` API endpoints? 2.1. SECURITY: Before we protect all endpoints will be security problem. Anyone can delete things from other offices if their ids are served. 2.2. COMPLEXITY: Will have to figure a new way to set data for ALL office selection dropdowns in the UI. They depend on that endpoint. 2.3. UX: (is this bad?) This means you will NOT see the offices that you are only viewer to in the global location filter. You will see `members` and `teams` from all offices if you select `All Locations`. 2.4. UX: This means you will NOT see the office names of items from other offices. We can put "unknown office" there or populate just the names, but not the ids. 3. MAJOR QUESTION: Should we omit `office` from items with office that you don't have access to? 3.1. SECURITY: this will make the temporal solution more secure as users won't have the office ids to abuse the other API endpoints. 3.2. COMPLEXITY: too much data to omit from all kinds of endpoints, nested documents, etc. Is this manageable? Maybe only for GET collection requests? **FUTURE VISION: -> Expose all controllers and protect all meaningful endpoints.** --- **II. GET request** 1. `prepareQuery` override where we remove the query if `secondary` is `viewer` using a class `LocationBasedController` that inherits `ControllerBase` and requires a `manager` for collecting items. 2. MAJOR QUESTION: Should we omit `office` from items with office that you don't have access to? 2.1. SECURITY: this will make the temporal solution more secure as users won't have the office ids to abuse the other API endpoints. 2.2. COMPLEXITY: this will make it easier to determine which items you have access to in the UI. If the item has an office Id, you have access to it. **FUTURE VISION: -> Cross-check offices for granular permissions and construct a query based on that (enable custom roles for rest) -> Remove the omission of `office` when all endpoints are secure.** --- **III. CUD request** 1. decorator + migrate to TS 1.1. Will need function descriptors for finding ids and updates from request. OR 2. `validateLocationAccess` method in `LocationBasedController` and use from `super` 2.1. This is not connected to the rest of the authorization which happens on route registration, so not future proof. OR BOTH **FUTURE VISION: -> Cross check granular permissions with location access to allow custom roles for rest.** --- **IV. UI** 1. MAJOR QUESTION: In the UI, permissions come as headers to `organizations` GET or `authorize` request. This is not scalable down the road. Will work for now, if we just add info about perm locations. 2. Add `perm-context` attribute to `perm` directive to pass items (more flexible) 2.1. We can pass the whole item as context or just the offices. 2.2. This context can also be used when we have grid selection. OR 3. Use `applicationContextService` to set a full context each time you: 3.1. visit a page 3.2. load an item 3.3. select items from a grid 3.4. Problem 1: how to trigger change in the perm directive. 3.5. Problem 2: how to describe app context for nested contexts. 4. Use this context to determine perm. OR 5. Extend items with `permissions` calculated on the server. 5.1. Ditch the `perm` directive. Client framework agnostic. 5.2. `perm` object for each item depends on how many granular permissions we have for the collection. 5.3. requested items will become larger, but we have paging. 5.4. We need option to call the items without the permissions. 5.5. Will make it easier for 3rd party implementations to provide better UX. 6. We can implement 5. in the same way we do `prepareQuery`. There can be a `preparePerm` method in the controller base or they can be merged.