-
Notifications
You must be signed in to change notification settings - Fork 162
Planning Organization Decoupling
This is a planning document intended to decouple Accounts from Organizations. The decoupling is being pursued towards several goals, the ability for journalists to belong to multiple organizations, as well as individuals to signup for DocumentCloud accounts in order to comment/annotate documents privately.
- Accounts have_and_belong_to_many Organizations :through OrganizationMembership
- Documents belong to Organization and Account (and no Document can be published w/o an organization)
- Annotations belong to Document and Account, and optionally Organization.
- The accessible methods can be rehabilitated to take a list of organizations, if a user wishes to see all the documents they have access to.
- Should accounts have a default organization if available?
- By and large clear.
- Documents will still require Organization
- Document#set_owner will now require an organization as well as an account
- Document#accessible will need to be refactored to take a list of organizations.
- Will Document.accessible require an organization?
- Don't think it can require one. If it required an organization, that would shut out commentors who lack one. It could/should restrict them to only PUBLIC documents. - nathan
- How will the concept of a 'current organization' be chosen and displayed in the workspace for account's who belong to multiple organization.
- Pages get organization_id from their Document
- Remains the same otherwise
- Annotation.accessible scope
- Annotation.populate_author_info
- Annotation.public_note_counts_by_organization
- Annotation#canonical(see author_organization)
- Annotation#to_json
- Account#authenticate
- Account#collaborates?
- Account#shared?
- Account#allowed_to_edit_account?
- Account#upgrade_reviewer_to_real
- Account#canonical
- Organization id can't be stored in Session cookies any longer.
- We could expand this concept to store an array of their organization_id's. Then in Document#accessible and others we could use organization_id in (?) for the query. -nathan
- Collborators list for projects display an organization (should accounts have a default organization?)
- Most of the controllers require a current_organization. Either a current_organization must always be supplied/found, or most of the controllers need to be restructured to not require an organization.
- AccountController#create should be isolated from organizations, with association into an organization being managed
- Disregarded temporarily.
- Annotations are currently created/updated with an account's organization id. Should organization_id be a record of access to a document for journalists? If so how does that shake out?
- Requires current_organization for Document.accessible and alsow in the upload handler
- Should accounts be forced to pick an organization to act under? This assumption should be made for the time being.
- Requires returning a list of accounts with an organization for each.
- Only requires current_organization for Document.accessible
- Only requires current_organization for Document.accessible
- Only requires an organization for Document.upload
- Only requires current_organization for Document.accessible
- requires current_organization for Document.accessible and uses current_organization as a scope for creating reviewer accounts.
- uses organization_id in the embed action
- Only requires current_organization for Document.accessible
- current_organization used as a scope to get a list of accounts
All of these are in the app/views/jst/workspace directory. I did not find any references to organization in any of the other JST directories.
-
account/collaborator displays the project's organization_name.
-
document/document_dialog has option to make document private to dc.account.organization.name. This needs either replaced by the default organization or by a listing of all the organizations the account belongs to.
-
document/upload_dialog Should be make clear what organization the current one for the upload. Could be extended to contain a selector for the uploader to select the organization that should own the document.
-
document/upload_document_tile has the same issue as document_dialog. The private option will have to refer to a list or just the default organization.
-
organizer/account_links displays the other accounts belonging to the organization. It can be expanded to have all accounts broken down by organization.
-
organizer/sidebar doesn't contain any overt references to organizations, but the above mentioned account_links template is rendered inside it. Depending on what's decided with how to display the organizations, this may need to be modified.
-
account/admin displays only the user's organization. Should be expanded to show all organizations the user is an admin of.
-
document/note describes who created an annotation by displaying their name and then the annotation's author_organization. This should still be safe as long as we make sure the field is still populated when the annotation is created.
-
modal/accounts Has an organization method and several other references to the organization in the file. We could leave this as-is and return the 'default organization'. Needs methods added to:
- Return list of all organizations
- Support for setting (and maybe saving?) the current organization.
-
- Has an editAcccess method that displays a dialog. The dialog has option to mark private to dc.account.organization(). If we rename the account accessor mentioned above, we'll need to update this as well.
- _checkForPending method also references dc.account.organization(). Same issue here.
-
model/projects Also references dc.account.organization()
-
ui/accounts/account_dialog also references dc.account.organization(). It will need expanded in order to allow an account to edit any organization that they are an admin of.
-
ui/documents/document attempts to display the organization by retrieving it from dc.account.organization(). Would be better re-written to use document#organization_name.
-
ui/documents/upload_dialog Organization isn't referenced directly here, but is included in the JST template. Should default to the currently selected organization
-
ui/organizer/organizer. Responsible for rendering the organizer. May need methods added to render the organization's listing on the sidebar.
-
admin/admin sorts the accounts list by the organization they belong to. Not sure if we'll be able to support that except by the 'default account' means.
-
model/projects has a standalone function: dc.model.Project.topLevelTitle which calls dc.account.organization().get('name') The topLevelTitle function is only called from model.DocumentSet's entitle method. Tracing that down, it's how the header for a search is determined.