|
| 1 | +Privacy Levels |
| 2 | +============== |
| 3 | + |
| 4 | +This document describes how to handle and unify privacy levels |
| 5 | +on the community and commercial version of Read the Docs. |
| 6 | + |
| 7 | +Current state |
| 8 | +------------- |
| 9 | + |
| 10 | +Currently, we have three privacy levels for projects and versions: |
| 11 | + |
| 12 | +#. Public |
| 13 | +#. Private |
| 14 | +#. Protected (currently hidden) |
| 15 | + |
| 16 | +These levels of privacy aren't clear and bring confusion to our users. |
| 17 | +Also, the private level doesn't makes sense on the community site, |
| 18 | +since we only support public projects. |
| 19 | + |
| 20 | +Places where we use the privacy levels are: |
| 21 | + |
| 22 | +- On serving docs |
| 23 | +- Footer |
| 24 | +- Dashboard |
| 25 | + |
| 26 | +Project level privacy |
| 27 | +--------------------- |
| 28 | + |
| 29 | +Project level privacy was meant to control the dashboard visibility. |
| 30 | + |
| 31 | +This privacy level brings to confusion when users want to make a version public. |
| 32 | +We should remove all the project privacy levels. |
| 33 | + |
| 34 | +For the community site the dashboard would be always visible, |
| 35 | +and for the commercial site, the dashboard would be always hidden. |
| 36 | + |
| 37 | +The project privacy level is also used to serve the ``404.html`` page, |
| 38 | +show ``robots.txt``, and show ``sitemap.xml``. |
| 39 | +The privacy level from versions should be used instead. |
| 40 | + |
| 41 | +Some other ideas about keeping the privacy level is to dictate the default version level of new versions, |
| 42 | +but removing all other logic related to this privacy level. |
| 43 | +This can be (or is going to be) possible with automation rules, |
| 44 | +so we can just remove the field. |
| 45 | + |
| 46 | +Version level privacy |
| 47 | +--------------------- |
| 48 | + |
| 49 | +Version level privacy is mainly used to restrict access to documentation. |
| 50 | +For public level, everyone can access to the documentation. |
| 51 | +For private level, only users that are maintainers or that belong to a team with access |
| 52 | +(for the commercial site) |
| 53 | +can access to the documentation. |
| 54 | + |
| 55 | +The protected privacy level was meant to hide versions from listings and search. |
| 56 | +For the community site these versions are treated like public versions, |
| 57 | +and on the commercial site they are treated like private. |
| 58 | + |
| 59 | +The protected privacy level is currently hidden. |
| 60 | +To keep the behavior of hiding versions from listings and search, |
| 61 | +a new field should be added to the Version model and forms: ``hidden`` (`#5321 <https://github.com/readthedocs/readthedocs.org/issues/5321>`__). |
| 62 | +The privacy level (public or private) would be respected to determine access to the documentation. |
| 63 | + |
| 64 | +For the community site, the privacy level would be public and can't be changed. |
| 65 | + |
| 66 | +The default privacy level of new versions for the commercial site would be ``private`` |
| 67 | +(this is the ``DEFAULT_PRIVACY_LEVEL`` setting). |
| 68 | + |
| 69 | +Footer |
| 70 | +------ |
| 71 | + |
| 72 | +The footer is used to display not hidden versions that the current user has access to. |
| 73 | + |
| 74 | +For the community site no changes are required on the footer. |
| 75 | + |
| 76 | +For the commercial site we use the project level privacy to decide if show or not |
| 77 | +links to the project's dashboard: downloads, project home, and builds. |
| 78 | +Given that the project privacy level would be removed (and the dashboard is always under login), |
| 79 | +those links would never be shown, except for admin users (owners or from a team with admin access) |
| 80 | +since they are the only ones allowed to make changes on the project. |
| 81 | + |
| 82 | +Overview |
| 83 | +-------- |
| 84 | + |
| 85 | +For the community site: |
| 86 | + |
| 87 | +- The project's dashboard is visible to all users. |
| 88 | +- All versions are always public. |
| 89 | +- The footer shows links to the project's dashboard (build, downloads, home) to all users. |
| 90 | +- Only versions with ``hidden = False`` are listed on the footer and appear on search results. |
| 91 | +- If a project has a `404.html` file on the default version, it's served. |
| 92 | +- If a project has a ``robots.txt`` file on the default version, it's served. |
| 93 | +- A ``sitemap.xml`` file is always served. |
| 94 | + |
| 95 | +For the commercial site: |
| 96 | + |
| 97 | +- The project's dashboard is visible to only users that have read permission over the project. |
| 98 | +- The footer shows links to the project's dashboard (build, downloads, home) to only admin users. |
| 99 | +- Only versions with ``hidden = False`` are listed on the footer and appear on search results. |
| 100 | +- If a project has a ``404.html`` file on the default version, it's served if the user has permission over that version. |
| 101 | +- If a project has a ``robots.txt`` file on the default version, it's served if the user has permission over that version. |
| 102 | +- A ``sitemap.xml`` file is served if the user has at least one public version. |
| 103 | + And it will only list public versions. |
| 104 | + |
| 105 | +Migration |
| 106 | +--------- |
| 107 | + |
| 108 | +To differentiate between allowing or not privacy levels, |
| 109 | +we need to add a setting ``RTD_ALLOW_PRIVACY_LEVELS`` (``False`` by default). |
| 110 | + |
| 111 | +For the community and commercial site, we need to: |
| 112 | + |
| 113 | +- Remove/change code that depends on the project's privacy level. |
| 114 | + Use the global setting ``RTD_ALLOW_PRIVACY_LEVELS`` and default version's privacy level instead. |
| 115 | + |
| 116 | + - Display robots.txt |
| 117 | + - Serve 404.html page |
| 118 | + - Display sitemap.xml |
| 119 | + - Querysets |
| 120 | + |
| 121 | +- Remove `Project.privacy_level` field |
| 122 | +- Migrate all protected versions to have the attribute ``hidden = True`` (data migration), |
| 123 | + and set their privacy level to public for the community site and private for the commercial site. |
| 124 | +- Change all querysets used to list versions on the footer and on search to use the ``hidden`` attribute. |
| 125 | +- Update docs |
| 126 | + |
| 127 | +For the community site: |
| 128 | + |
| 129 | +- Hide all privacy level related settings from the version form. |
| 130 | +- Don't expose privacy levels on API v3. |
| 131 | +- Mark all versions as public. |
| 132 | + |
| 133 | +For the commercial site: |
| 134 | + |
| 135 | +- Always hide the dashboard |
| 136 | +- Show links to the dashboard (downloads, builds, project home) on the footer only to admin users. |
| 137 | + |
| 138 | +Upgrade path overview |
| 139 | +--------------------- |
| 140 | + |
| 141 | +Community site |
| 142 | +############## |
| 143 | + |
| 144 | +The default privacy level for the community site is public for versions and the dashboard is always public. |
| 145 | + |
| 146 | +Public project (community) |
| 147 | +~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 148 | + |
| 149 | +- Public version: |
| 150 | + Normal use case, no changes required. |
| 151 | +- Protected version: |
| 152 | + Users didn't want to list this version on the footer, |
| 153 | + but also not deactivate it. |
| 154 | + We can do a data migration of those versions to the new ``hidden`` setting and make them public. |
| 155 | +- Private version: |
| 156 | + Users didn't want to show this version to their users yet or they were testing something. |
| 157 | + This can be solved with the pull request builder feature and the ``hidden`` setting. |
| 158 | + We migrate those to public with the ``hidden`` setting. |
| 159 | + If we are worried about leaking anything from the version, we can email users before doing the change. |
| 160 | + |
| 161 | +Protected project (community) |
| 162 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 163 | + |
| 164 | +Protected projects are not listed publicly. |
| 165 | +Probably users were hosting a WIP project, |
| 166 | +or personal public project. |
| 167 | +A public project should work for them, |
| 168 | +as we are removing listing all projects publicly (except for search). |
| 169 | + |
| 170 | +The migration path for versions of protected projects is the same as a public project. |
| 171 | + |
| 172 | +Private project (community) |
| 173 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 174 | + |
| 175 | +Probably these users want to use our enterprise solution instead. |
| 176 | +Or they were hosting a personal project. |
| 177 | + |
| 178 | +The migration path for versions of private projects is the same as a public project. |
| 179 | + |
| 180 | +If we are worried about leaking anything from the dashboard or build page, |
| 181 | +we can email users before doing the change. |
| 182 | + |
| 183 | +Commercial site |
| 184 | +############### |
| 185 | + |
| 186 | +The default privacy level for the commercial site is private for versions and the dashboard is show only to admin users. |
| 187 | + |
| 188 | +Private project (commercial) |
| 189 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 190 | + |
| 191 | +- Private version: |
| 192 | + Normal usa case, not changes required. |
| 193 | +- Protected version: |
| 194 | + Users didn't want to list this version on the footer, |
| 195 | + but also not deactivate it. This can be solved by using the new ``hidden`` setting. |
| 196 | + We can do a data migration of those versions to the new ``hidden`` setting and make them private. |
| 197 | +- Public version: |
| 198 | + User has private code, but want to make public their docs. |
| 199 | + No changes required. |
| 200 | + |
| 201 | +Protected project (commercial) |
| 202 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 203 | + |
| 204 | +I can't think of a use case for protected projects, |
| 205 | +since they aren't listed publicly on the commercial site. |
| 206 | + |
| 207 | +The migration path for versions of protected projects is the same as a private project. |
| 208 | + |
| 209 | +Public project (commercial) |
| 210 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 211 | + |
| 212 | +Currently we show links back to project dashboard if the project is public, |
| 213 | +which probably users shouldn't see. |
| 214 | +With the implementation of this design doc, |
| 215 | +public versions don't have links to the project dashboard (except for admin users) and the dashboard is always under login. |
| 216 | + |
| 217 | +- Private versions: |
| 218 | + Users under the organization can see links to the dashboard. |
| 219 | + Not changes required. |
| 220 | +- Protected versions: |
| 221 | + Users under the organization can see links to the dashboard. |
| 222 | + We can do a data migration of those versions to the new ``hidden`` setting and make them private. |
| 223 | +- Public versions: |
| 224 | + All users can see links to the dashboard. |
| 225 | + Probably they have an open source project, |
| 226 | + but they still want to manage access using the same teams of the organization. |
| 227 | + Not changes are required. |
| 228 | + |
| 229 | +A breaking change here is: |
| 230 | +users outside the organization would not be able to see the dashboard of the project. |
0 commit comments