diff --git a/dev/api/openapi.json b/dev/api/openapi.json
index 33a9fb4752..ed36063d4d 100644
--- a/dev/api/openapi.json
+++ b/dev/api/openapi.json
@@ -2,7 +2,7 @@
   "openapi": "3.1.0",
   "info": {
     "title": "fides",
-    "version": "2.52.1b0.post0.dev4"
+    "version": "2.52.1b0.post0.dev5"
   },
   "paths": {
     "/api/v1/data_category": {
diff --git a/dev/config/fides.toml b/dev/config/fides.toml
index 5304e79e16..d882ef5240 100644
--- a/dev/config/fides.toml
+++ b/dev/config/fides.toml
@@ -32,7 +32,7 @@ task_always_eager = true # boolean
 
 # A fully anonymized unique identifier that is automatically generated
 # by the application. Used for anonymous analytics when opted-in.
-analytics_id = "ed8b148eff59133f52d78700b726958c" # string
+analytics_id = "dc3e438ddaaf3cd7c251c877ce7b9e77" # string
 
 # When set to True, disables functionality that requires making calls
 # to a Fides webserver.
diff --git a/dev/config/index.html b/dev/config/index.html
index f3bb259c15..f0cc5c8230 100644
--- a/dev/config/index.html
+++ b/dev/config/index.html
@@ -1553,7 +1553,7 @@ <h2 id="configuration-file-reference">Configuration File Reference</h2>
 
 <span class="c1"># A fully anonymized unique identifier that is automatically generated</span>
 <span class="c1"># by the application. Used for anonymous analytics when opted-in.</span>
-<span class="n">analytics_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ed8b148eff59133f52d78700b726958c&quot;</span><span class="w"> </span><span class="c1"># string</span>
+<span class="n">analytics_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;dc3e438ddaaf3cd7c251c877ce7b9e77&quot;</span><span class="w"> </span><span class="c1"># string</span>
 
 <span class="c1"># When set to True, disables functionality that requires making calls</span>
 <span class="c1"># to a Fides webserver.</span>
diff --git a/dev/search/search_index.json b/dev/search/search_index.json
index 23977e9e52..6bbfea1160 100644
--- a/dev/search/search_index.json
+++ b/dev/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"The Fides Ecosystem Fides (pronounced /fee-dhez/ , from Latin: Fid\u0113s) is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in your runtime environment, and the enforcement of privacy regulations in your code. The Fides developer tools allow engineers and legal teams to label system privacy characteristics, orchestrate programmatic rights fulfillment, and audit stored personal identifiable information (PII) throughout application systems and infrastructure. This includes support for major privacy regulations (e.g. GDPR , CCPA and LGPD ), and standards like ISO 19944 by default. Key Features End-to-End Data Subject Request Automation Privacy-as-Code Compliance-minded Data Mapping Comprehensive Privacy Standard Support For more information, please visit our official docs site over at https://docs.ethyca.com","title":"What is Fides?"},{"location":"#the-fides-ecosystem","text":"Fides (pronounced /fee-dhez/ , from Latin: Fid\u0113s) is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in your runtime environment, and the enforcement of privacy regulations in your code. The Fides developer tools allow engineers and legal teams to label system privacy characteristics, orchestrate programmatic rights fulfillment, and audit stored personal identifiable information (PII) throughout application systems and infrastructure. This includes support for major privacy regulations (e.g. GDPR , CCPA and LGPD ), and standards like ISO 19944 by default.","title":"The Fides Ecosystem"},{"location":"#key-features","text":"End-to-End Data Subject Request Automation Privacy-as-Code Compliance-minded Data Mapping Comprehensive Privacy Standard Support For more information, please visit our official docs site over at https://docs.ethyca.com","title":"Key Features"},{"location":"ethyca/","text":"About Ethyca The mission of Ethyca is to make Internet-scale technology respectful and ethical. We're a venture-backed privacy technology team headquartered in New York, but working as a distributed team across the US to solve what we believe is the most important problem in technology today: the human right to privacy in vastly complex data-driven systems. What is Fides? Fides is a universally understandable, open-source language that can be used to describe privacy within tech infrastructure. Our existing tools use this language to power a low friction set of developer tools that integrate with your existing CI pipelines, making privacy a feature of your tech stack. With Fides, we hope everyone can build better tools for privacy in the next decade and beyond. What we Believe Data privacy is a human right that should be a native feature of any respectful technology. Today building great privacy as a feature in software is friction-filled and complicated. We're building open-source privacy tools for the developer community because we believe the only way to achieve a respectful internet is to make privacy an easy-to-implement layer of any tech stack. The Future We've been working on this problem since 2018 and have a clear view of our next five years. We're excited about the roadmap of features we'll add to Fides in order to make it the comprehensive tool for addressing the major challenges of privacy in both the code management and runtime environments. We'd love you to contribute to Fides, and you can do this directly as part of the open-source community. If you're interested in solving some of the toughest and most important problems facing internet scale data-driven software, join us now and get paid to work on this problem too! Your Participation Fides' success is predicated on your participation -- Privacy as Code can only become a reality if we ensure it's easy to understand, implement, and held as an interoperable standard for wide adoption. Your feedback, contributions, and improvements are encouraged as we build community with the sole objective of creating respectful software for everyone on the internet.","title":"About Ethyca"},{"location":"ethyca/#about-ethyca","text":"The mission of Ethyca is to make Internet-scale technology respectful and ethical. We're a venture-backed privacy technology team headquartered in New York, but working as a distributed team across the US to solve what we believe is the most important problem in technology today: the human right to privacy in vastly complex data-driven systems.","title":"About Ethyca"},{"location":"ethyca/#what-is-fides","text":"Fides is a universally understandable, open-source language that can be used to describe privacy within tech infrastructure. Our existing tools use this language to power a low friction set of developer tools that integrate with your existing CI pipelines, making privacy a feature of your tech stack. With Fides, we hope everyone can build better tools for privacy in the next decade and beyond.","title":"What is Fides?"},{"location":"ethyca/#what-we-believe","text":"Data privacy is a human right that should be a native feature of any respectful technology. Today building great privacy as a feature in software is friction-filled and complicated. We're building open-source privacy tools for the developer community because we believe the only way to achieve a respectful internet is to make privacy an easy-to-implement layer of any tech stack.","title":"What we Believe"},{"location":"ethyca/#the-future","text":"We've been working on this problem since 2018 and have a clear view of our next five years. We're excited about the roadmap of features we'll add to Fides in order to make it the comprehensive tool for addressing the major challenges of privacy in both the code management and runtime environments. We'd love you to contribute to Fides, and you can do this directly as part of the open-source community. If you're interested in solving some of the toughest and most important problems facing internet scale data-driven software, join us now and get paid to work on this problem too!","title":"The Future"},{"location":"ethyca/#your-participation","text":"Fides' success is predicated on your participation -- Privacy as Code can only become a reality if we ensure it's easy to understand, implement, and held as an interoperable standard for wide adoption. Your feedback, contributions, and improvements are encouraged as we build community with the sole objective of creating respectful software for everyone on the internet.","title":"Your Participation"},{"location":"license/","text":"License 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License. \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\" \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets \"[]\" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \"printed page\" as the copyright notice for easier identification within third-party archives. Copyright 2021- Ethyca, Inc. Licensed under the Apache License, Version 2.0 (the \"License\"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.","title":"License"},{"location":"license/#license","text":"1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License. \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\" \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets \"[]\" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \"printed page\" as the copyright notice for easier identification within third-party archives. Copyright 2021- Ethyca, Inc. Licensed under the Apache License, Version 2.0 (the \"License\"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.","title":"License"},{"location":"api/","text":"API Reference You can view the live, interactive Swagger API docs for Fides by visiting /docs on a running instance. This is a great way to experiment with the APIs using Swagger's built-in \"Try it out\" functionality. Below, we've embedded the latest release's API documentation as a living reference. These work largely the same, but since this documentation site isn't connected to a live instance, the \"Try it out\" and \"Authorize\" buttons won't work, sorry! All API routes will automatically matched with and without a trailing slash / . So /api/v1/config and /api/v1/config/ are both valid API calls. const ui = SwaggerUIBundle({ url: 'openapi.json', dom_id: '#swagger-ui', }) /*If there is an anchor tag, reload it after the page loads to scroll to * that section, since the Swagger UI takes some time to render. */ if (location.hash) { setTimeout(function() { location.href = location.href }, 200); }","title":"API"},{"location":"api/#api-reference","text":"You can view the live, interactive Swagger API docs for Fides by visiting /docs on a running instance. This is a great way to experiment with the APIs using Swagger's built-in \"Try it out\" functionality. Below, we've embedded the latest release's API documentation as a living reference. These work largely the same, but since this documentation site isn't connected to a live instance, the \"Try it out\" and \"Authorize\" buttons won't work, sorry! All API routes will automatically matched with and without a trailing slash / . So /api/v1/config and /api/v1/config/ are both valid API calls. const ui = SwaggerUIBundle({ url: 'openapi.json', dom_id: '#swagger-ui', }) /*If there is an anchor tag, reload it after the page loads to scroll to * that section, since the Swagger UI takes some time to render. */ if (location.hash) { setTimeout(function() { location.href = location.href }, 200); }","title":"API Reference"},{"location":"cli/","text":"CLI These are autogenerated CLI docs that reflect the latest PyPI release. fides 1 2 3 4 5 __Command-line tool for the Fides privacy engineering platform.__ --- _Note: The common MANIFESTS_DIR argument _always_ defaults to \".fides/\" if not specified._ Usage: 1 fides [OPTIONS] COMMAND [ARGS]... Options: 1 2 3 4 5 6 --version Show the version and exit. -f, --config-path TEXT Path to a Fides config file. _Defaults to `.fides/fides.toml`._ --local Run in `local_mode`. Where possible, this will force commands to run without the need for a server. --help Show this message and exit. fides annotate 1 Interactively annotate Fides resources. Usage: 1 fides annotate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides annotate dataset 1 Interactively annotate a dataset file in-place. Usage: 1 fides annotate dataset [OPTIONS] INPUT_FILENAME Options: 1 2 3 4 -a, --all-members Annotate all parts of the dataset including schemas and tables. -v, --validate Validate annotation inputs. --help Show this message and exit. fides db 1 Run actions against the application database. Usage: 1 fides db [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides db init 1 2 3 4 5 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. **WARNING**: Deprecated, use `upgrade` instead. Usage: 1 fides db init [OPTIONS] Options: 1 --help Show this message and exit. fides db reset 1 Reset the database back to its initial state. Usage: 1 fides db reset [OPTIONS] Options: 1 2 -y, --yes Automatically responds `yes` to any prompts. --help Show this message and exit. fides db upgrade 1 2 3 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. Usage: 1 fides db upgrade [OPTIONS] Options: 1 --help Show this message and exit. fides delete 1 Delete an object from the server. Usage: 1 2 fides delete [OPTIONS] {data_category|data_subject|data_use|dataset|organizati on|policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit. fides deploy 1 Deploy a sample project locally to try out Fides. Usage: 1 fides deploy [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides deploy down 1 Stops the sample project and removes all volumes. Usage: 1 fides deploy down [OPTIONS] Options: 1 --help Show this message and exit. fides deploy up 1 Starts a sample project via docker compose. Usage: 1 fides deploy up [OPTIONS] Options: 1 2 3 4 5 6 7 8 --no-pull Use a local image instead of trying to pull from DockerHub. --no-init Disable the initialization of the Fides CLI, to run in headless mode. --env-file PATH Use a custom ENV file for the Fides container to override settings. --image TEXT Use a custom image for the Fides container instead of the default ('ethyca/fides'). --help Show this message and exit. fides evaluate 1 Evaluate System-level Privacy Declarations against Organization-level Policy Rules. Usage: 1 fides evaluate [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 -k, --fides-key TEXT The fides_key of a specific policy to evaluate. -m, --message TEXT Describe the context of this evaluation. -a, --audit Validate that the objects in this evaluation produce a valid data map. --dry Do not upload objects or results to the Fides webserver. --help Show this message and exit. fides generate 1 Programmatically generate Fides objects. Usage: 1 fides generate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset 1 Generate Fides datasets. Usage: 1 fides generate dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset aws 1 Generate Fides datasets from specific Amazon Web Services. Usage: 1 fides generate dataset aws [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset aws dynamodb 1 Generates a dataset object from DynamoDB using the AWS boto3 connection config. Usage: 1 fides generate dataset aws dynamodb [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --single-dataset BOOLEAN --include-null Include null attributes. --help Show this message and exit. fides generate dataset db 1 Generate a Fides dataset by walking a database and recording every schema/table/field. Usage: 1 fides generate dataset db [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. --include-null Include null attributes. --help Show this message and exit. fides generate dataset gcp 1 Generate Fides datasets from Google Cloud Platform. Usage: 1 fides generate dataset gcp [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset gcp bigquery 1 Generate a dataset object from BigQuery using a SQLAlchemy connection string. Usage: 1 fides generate dataset gcp bigquery [OPTIONS] DATASET_NAME OUTPUT_FILENAME Options: 1 2 3 4 --credentials-id TEXT Use credentials keys defined within Fides config. --keyfile-path TEXT --include-null Include null attributes. --help Show this message and exit. fides generate system 1 Generate Fides systems. Usage: 1 fides generate system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate system aws 1 2 Connect to an aws account and generate a system manifest file that consists of every tracked resource. Usage: 1 fides generate system aws [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit. fides generate system okta 1 2 Generates systems from your Okta applications. Connects via an Okta admin account. Usage: 1 fides generate system okta [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit. fides get 1 View an object from the server. Usage: 1 2 fides get [OPTIONS] {data_category|data_subject|data_use|dataset|organization| policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit. fides init 1 2 Initializes a Fides instance by creating the default directory and configuration file if not present. Usage: 1 fides init [OPTIONS] [FIDES_DIR] Options: 1 2 --opt-in Automatically opt-in to anonymous usage analytics. --help Show this message and exit. fides ls 1 View all objects of a single type from the server. Usage: 1 2 fides ls [OPTIONS] {data_category|data_subject|data_use|dataset|organization|p olicy|system|evaluation} Options: 1 2 -v, --verbose Displays the entire object list as YAML. --help Show this message and exit. fides parse 1 Parse all Fides objects located in the supplied directory. Usage: 1 fides parse [OPTIONS] [MANIFESTS_DIR] Options: 1 2 -v, --verbose Enable verbose output. --help Show this message and exit. fides pull 1 Update local resource files based on the state of the objects on the server. Usage: 1 fides pull [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides pull all 1 Retrieve all resources from the server and update the local manifest files. Usage: 1 fides pull all [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 -a, --all-resources TEXT Pulls all locally missing resources from the server into this file. --help Show this message and exit. fides pull data_category 1 Retrieve a specific data_category from the server and update the local manifest files. Usage: 1 fides pull data_category [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull data_subject 1 Retrieve a specific data_subject from the server and update the local manifest files. Usage: 1 fides pull data_subject [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull data_use 1 Retrieve a specific data_use from the server and update the local manifest files. Usage: 1 fides pull data_use [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull dataset 1 Retrieve a specific dataset from the server and update the local manifest files. Usage: 1 fides pull dataset [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull system 1 Retrieve a specific system from the server and update the local manifest files. Usage: 1 fides pull system [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides push 1 Parse local manifest files and upload them to the server. Usage: 1 fides push [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 --dry Do not upload results to the Fides webserver. --diff Print any diffs between the local & server objects --help Show this message and exit. fides scan 1 Scan and report on discrepancies between Fides resource files and real infrastructure. Usage: 1 fides scan [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan dataset 1 Scan and report on Fides Dataset resources. Usage: 1 fides scan dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan dataset db 1 2 3 4 Scan a database directly using a SQLAlchemy-style connection string. _If there are fields within the database that aren't listed and categorized within one of the datasets, this counts as lacking coverage._ Usage: 1 fides scan dataset db [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides scan system 1 Scan and report on Fides System resources. Usage: 1 fides scan system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan system aws 1 2 3 Scan an AWS account and compare objects with annotated Fides Systems. _Scannable resources: [Redshift, RDS, DynamoDb, S3]_ Usage: 1 fides scan system aws [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides scan system okta 1 Scan an Okta account and compare applications with annotated Fides Systems. Usage: 1 fides scan system okta [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides status 1 Check Fides server availability. Usage: 1 fides status [OPTIONS] Options: 1 --help Show this message and exit. fides user 1 Click command group for interacting with user-related functionality. Usage: 1 fides user [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides user create 1 Use the credentials file to create a new user. Gives full permissions to the new user. Usage: 1 fides user create [OPTIONS] USERNAME PASSWORD EMAIL_ADDRESS Options: 1 2 3 -f, --first-name TEXT -l, --last-name TEXT --help Show this message and exit. fides user login 1 2 Authenticate with the webserver and generate a user access token. Then store those credentials in a credentials file. Usage: 1 fides user login [OPTIONS] Options: 1 2 3 4 5 -u, --username TEXT If not provided, will be pulled from the config file or prompted for. -p, --password TEXT If not provided, will be pulled from the config file or prompted for. --help Show this message and exit. fides user permissions 1 List the directly-assigned scopes and roles available to the current user. Usage: 1 fides user permissions [OPTIONS] Options: 1 --help Show this message and exit. fides view 1 View various resources types. Usage: 1 fides view [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides view config 1 2 3 Prints the configuration values being used for this command-line instance. _Note: To see the configuration values being used by the webserver, `GET` the `/api/v1/config` endpoint._ Usage: 1 fides view config [OPTIONS] [SECTION] Options: 1 2 --exclude-unset Only print configuration values explicitly set by the user. --help Show this message and exit. fides view credentials 1 Prints the credentials file. Usage: 1 fides view credentials [OPTIONS] Options: 1 --help Show this message and exit. fides webserver 1 2 3 Start the Fides webserver. _Requires Redis and Postgres to be configured and running_ Usage: 1 fides webserver [OPTIONS] Options: 1 2 -p, --port INTEGER --help Show this message and exit. fides worker 1 Start a Celery worker for the Fides webserver. Usage: 1 fides worker [OPTIONS] Options: 1 --help Show this message and exit.","title":"CLI"},{"location":"cli/#cli","text":"These are autogenerated CLI docs that reflect the latest PyPI release.","title":"CLI"},{"location":"cli/#fides","text":"1 2 3 4 5 __Command-line tool for the Fides privacy engineering platform.__ --- _Note: The common MANIFESTS_DIR argument _always_ defaults to \".fides/\" if not specified._ Usage: 1 fides [OPTIONS] COMMAND [ARGS]... Options: 1 2 3 4 5 6 --version Show the version and exit. -f, --config-path TEXT Path to a Fides config file. _Defaults to `.fides/fides.toml`._ --local Run in `local_mode`. Where possible, this will force commands to run without the need for a server. --help Show this message and exit.","title":"fides"},{"location":"cli/#fides-annotate","text":"1 Interactively annotate Fides resources. Usage: 1 fides annotate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"annotate"},{"location":"cli/#fides-annotate-dataset","text":"1 Interactively annotate a dataset file in-place. Usage: 1 fides annotate dataset [OPTIONS] INPUT_FILENAME Options: 1 2 3 4 -a, --all-members Annotate all parts of the dataset including schemas and tables. -v, --validate Validate annotation inputs. --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-db","text":"1 Run actions against the application database. Usage: 1 fides db [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"db"},{"location":"cli/#fides-db-init","text":"1 2 3 4 5 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. **WARNING**: Deprecated, use `upgrade` instead. Usage: 1 fides db init [OPTIONS] Options: 1 --help Show this message and exit.","title":"init"},{"location":"cli/#fides-db-reset","text":"1 Reset the database back to its initial state. Usage: 1 fides db reset [OPTIONS] Options: 1 2 -y, --yes Automatically responds `yes` to any prompts. --help Show this message and exit.","title":"reset"},{"location":"cli/#fides-db-upgrade","text":"1 2 3 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. Usage: 1 fides db upgrade [OPTIONS] Options: 1 --help Show this message and exit.","title":"upgrade"},{"location":"cli/#fides-delete","text":"1 Delete an object from the server. Usage: 1 2 fides delete [OPTIONS] {data_category|data_subject|data_use|dataset|organizati on|policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit.","title":"delete"},{"location":"cli/#fides-deploy","text":"1 Deploy a sample project locally to try out Fides. Usage: 1 fides deploy [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"deploy"},{"location":"cli/#fides-deploy-down","text":"1 Stops the sample project and removes all volumes. Usage: 1 fides deploy down [OPTIONS] Options: 1 --help Show this message and exit.","title":"down"},{"location":"cli/#fides-deploy-up","text":"1 Starts a sample project via docker compose. Usage: 1 fides deploy up [OPTIONS] Options: 1 2 3 4 5 6 7 8 --no-pull Use a local image instead of trying to pull from DockerHub. --no-init Disable the initialization of the Fides CLI, to run in headless mode. --env-file PATH Use a custom ENV file for the Fides container to override settings. --image TEXT Use a custom image for the Fides container instead of the default ('ethyca/fides'). --help Show this message and exit.","title":"up"},{"location":"cli/#fides-evaluate","text":"1 Evaluate System-level Privacy Declarations against Organization-level Policy Rules. Usage: 1 fides evaluate [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 -k, --fides-key TEXT The fides_key of a specific policy to evaluate. -m, --message TEXT Describe the context of this evaluation. -a, --audit Validate that the objects in this evaluation produce a valid data map. --dry Do not upload objects or results to the Fides webserver. --help Show this message and exit.","title":"evaluate"},{"location":"cli/#fides-generate","text":"1 Programmatically generate Fides objects. Usage: 1 fides generate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"generate"},{"location":"cli/#fides-generate-dataset","text":"1 Generate Fides datasets. Usage: 1 fides generate dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-generate-dataset-aws","text":"1 Generate Fides datasets from specific Amazon Web Services. Usage: 1 fides generate dataset aws [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-generate-dataset-aws-dynamodb","text":"1 Generates a dataset object from DynamoDB using the AWS boto3 connection config. Usage: 1 fides generate dataset aws dynamodb [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --single-dataset BOOLEAN --include-null Include null attributes. --help Show this message and exit.","title":"dynamodb"},{"location":"cli/#fides-generate-dataset-db","text":"1 Generate a Fides dataset by walking a database and recording every schema/table/field. Usage: 1 fides generate dataset db [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. --include-null Include null attributes. --help Show this message and exit.","title":"db"},{"location":"cli/#fides-generate-dataset-gcp","text":"1 Generate Fides datasets from Google Cloud Platform. Usage: 1 fides generate dataset gcp [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"gcp"},{"location":"cli/#fides-generate-dataset-gcp-bigquery","text":"1 Generate a dataset object from BigQuery using a SQLAlchemy connection string. Usage: 1 fides generate dataset gcp bigquery [OPTIONS] DATASET_NAME OUTPUT_FILENAME Options: 1 2 3 4 --credentials-id TEXT Use credentials keys defined within Fides config. --keyfile-path TEXT --include-null Include null attributes. --help Show this message and exit.","title":"bigquery"},{"location":"cli/#fides-generate-system","text":"1 Generate Fides systems. Usage: 1 fides generate system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-generate-system-aws","text":"1 2 Connect to an aws account and generate a system manifest file that consists of every tracked resource. Usage: 1 fides generate system aws [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-generate-system-okta","text":"1 2 Generates systems from your Okta applications. Connects via an Okta admin account. Usage: 1 fides generate system okta [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit.","title":"okta"},{"location":"cli/#fides-get","text":"1 View an object from the server. Usage: 1 2 fides get [OPTIONS] {data_category|data_subject|data_use|dataset|organization| policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit.","title":"get"},{"location":"cli/#fides-init","text":"1 2 Initializes a Fides instance by creating the default directory and configuration file if not present. Usage: 1 fides init [OPTIONS] [FIDES_DIR] Options: 1 2 --opt-in Automatically opt-in to anonymous usage analytics. --help Show this message and exit.","title":"init"},{"location":"cli/#fides-ls","text":"1 View all objects of a single type from the server. Usage: 1 2 fides ls [OPTIONS] {data_category|data_subject|data_use|dataset|organization|p olicy|system|evaluation} Options: 1 2 -v, --verbose Displays the entire object list as YAML. --help Show this message and exit.","title":"ls"},{"location":"cli/#fides-parse","text":"1 Parse all Fides objects located in the supplied directory. Usage: 1 fides parse [OPTIONS] [MANIFESTS_DIR] Options: 1 2 -v, --verbose Enable verbose output. --help Show this message and exit.","title":"parse"},{"location":"cli/#fides-pull","text":"1 Update local resource files based on the state of the objects on the server. Usage: 1 fides pull [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"pull"},{"location":"cli/#fides-pull-all","text":"1 Retrieve all resources from the server and update the local manifest files. Usage: 1 fides pull all [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 -a, --all-resources TEXT Pulls all locally missing resources from the server into this file. --help Show this message and exit.","title":"all"},{"location":"cli/#fides-pull-data_category","text":"1 Retrieve a specific data_category from the server and update the local manifest files. Usage: 1 fides pull data_category [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_category"},{"location":"cli/#fides-pull-data_subject","text":"1 Retrieve a specific data_subject from the server and update the local manifest files. Usage: 1 fides pull data_subject [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_subject"},{"location":"cli/#fides-pull-data_use","text":"1 Retrieve a specific data_use from the server and update the local manifest files. Usage: 1 fides pull data_use [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_use"},{"location":"cli/#fides-pull-dataset","text":"1 Retrieve a specific dataset from the server and update the local manifest files. Usage: 1 fides pull dataset [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-pull-system","text":"1 Retrieve a specific system from the server and update the local manifest files. Usage: 1 fides pull system [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-push","text":"1 Parse local manifest files and upload them to the server. Usage: 1 fides push [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 --dry Do not upload results to the Fides webserver. --diff Print any diffs between the local & server objects --help Show this message and exit.","title":"push"},{"location":"cli/#fides-scan","text":"1 Scan and report on discrepancies between Fides resource files and real infrastructure. Usage: 1 fides scan [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"scan"},{"location":"cli/#fides-scan-dataset","text":"1 Scan and report on Fides Dataset resources. Usage: 1 fides scan dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-scan-dataset-db","text":"1 2 3 4 Scan a database directly using a SQLAlchemy-style connection string. _If there are fields within the database that aren't listed and categorized within one of the datasets, this counts as lacking coverage._ Usage: 1 fides scan dataset db [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"db"},{"location":"cli/#fides-scan-system","text":"1 Scan and report on Fides System resources. Usage: 1 fides scan system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-scan-system-aws","text":"1 2 3 Scan an AWS account and compare objects with annotated Fides Systems. _Scannable resources: [Redshift, RDS, DynamoDb, S3]_ Usage: 1 fides scan system aws [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-scan-system-okta","text":"1 Scan an Okta account and compare applications with annotated Fides Systems. Usage: 1 fides scan system okta [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"okta"},{"location":"cli/#fides-status","text":"1 Check Fides server availability. Usage: 1 fides status [OPTIONS] Options: 1 --help Show this message and exit.","title":"status"},{"location":"cli/#fides-user","text":"1 Click command group for interacting with user-related functionality. Usage: 1 fides user [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"user"},{"location":"cli/#fides-user-create","text":"1 Use the credentials file to create a new user. Gives full permissions to the new user. Usage: 1 fides user create [OPTIONS] USERNAME PASSWORD EMAIL_ADDRESS Options: 1 2 3 -f, --first-name TEXT -l, --last-name TEXT --help Show this message and exit.","title":"create"},{"location":"cli/#fides-user-login","text":"1 2 Authenticate with the webserver and generate a user access token. Then store those credentials in a credentials file. Usage: 1 fides user login [OPTIONS] Options: 1 2 3 4 5 -u, --username TEXT If not provided, will be pulled from the config file or prompted for. -p, --password TEXT If not provided, will be pulled from the config file or prompted for. --help Show this message and exit.","title":"login"},{"location":"cli/#fides-user-permissions","text":"1 List the directly-assigned scopes and roles available to the current user. Usage: 1 fides user permissions [OPTIONS] Options: 1 --help Show this message and exit.","title":"permissions"},{"location":"cli/#fides-view","text":"1 View various resources types. Usage: 1 fides view [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"view"},{"location":"cli/#fides-view-config","text":"1 2 3 Prints the configuration values being used for this command-line instance. _Note: To see the configuration values being used by the webserver, `GET` the `/api/v1/config` endpoint._ Usage: 1 fides view config [OPTIONS] [SECTION] Options: 1 2 --exclude-unset Only print configuration values explicitly set by the user. --help Show this message and exit.","title":"config"},{"location":"cli/#fides-view-credentials","text":"1 Prints the credentials file. Usage: 1 fides view credentials [OPTIONS] Options: 1 --help Show this message and exit.","title":"credentials"},{"location":"cli/#fides-webserver","text":"1 2 3 Start the Fides webserver. _Requires Redis and Postgres to be configured and running_ Usage: 1 fides webserver [OPTIONS] Options: 1 2 -p, --port INTEGER --help Show this message and exit.","title":"webserver"},{"location":"cli/#fides-worker","text":"1 Start a Celery worker for the Fides webserver. Usage: 1 fides worker [OPTIONS] Options: 1 --help Show this message and exit.","title":"worker"},{"location":"community/code_of_conduct/","text":"Fides Code of Conduct Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Our Standards Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct that could reasonably be considered inappropriate in a professional setting Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. Scope This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Fides core team at fides@ethyca.com . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. Attribution This Code of Conduct is adapted from the Contributor Covenant , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq","title":"Code of Conduct"},{"location":"community/code_of_conduct/#fides-code-of-conduct","text":"","title":"Fides Code of Conduct"},{"location":"community/code_of_conduct/#our-pledge","text":"In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.","title":"Our Pledge"},{"location":"community/code_of_conduct/#our-standards","text":"Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct that could reasonably be considered inappropriate in a professional setting","title":"Our Standards"},{"location":"community/code_of_conduct/#our-responsibilities","text":"Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.","title":"Our Responsibilities"},{"location":"community/code_of_conduct/#scope","text":"This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.","title":"Scope"},{"location":"community/code_of_conduct/#enforcement","text":"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Fides core team at fides@ethyca.com . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.","title":"Enforcement"},{"location":"community/code_of_conduct/#attribution","text":"This Code of Conduct is adapted from the Contributor Covenant , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq","title":"Attribution"},{"location":"community/hints_tips/","text":"Community The Fides project welcomes issues, contributions and discussion from all users, regardless of background or experience level. In order to create a positive and welcoming environment, all interactions are governed by the Fides Code of Conduct . Guidelines Whether it's giving us feedback, raising a question, or showing your Fides-related work, we are looking forward to hearing from you. The Fides community is vibrant because of the quality of its members and the discussions they bring. To keep the workspace inviting and helpful for everyone, there are a few guidelines that we ask all members to follow. Rule 1: Assume Positive Intent Being nice is the most important pillar of the Fides community. We are considerate to each other's effort and time. It's also easy to misinterpret people through Slack, so we make an extra effort to chat in a positive tone. We assume that you are here to learn and exchange ideas, and we ask that you contribute to making a welcoming community. If someone is helping you, be mindful of the effort they are putting in. While we are always happy to help users, we can not help users with step-by-step debugging. Use your professional judgment in discerning whether requests are unreasonable. The Fides team always tries to listen to the community. Please be understanding if your issue or feature request is not deemed an immediate priority. Rule 2: Use threads for larger messages Because of the size of our community and frequency of posts, it's easy for large messages to drown out smaller messages. Using threads helps people see more messages on their screen. Larger code blocks should be posted in threads. Rule 3: Avoid posting sensitive information Community members sometimes need to post code snippets as they ask for help. Be sure to remove sensitive information from posts to the public channels. If your Fides account information is needed to help you, we will ask you to direct message such information. Be cautious of anyone asking for information through direct messages. Rule 4: Write high quality questions The Fides community is here to support you. That said, it is significantly easier to answer well-researched and clearly-written questions. Even adding potentially relevant links to a post helps tremendously. Informative Slack threads are archived by our resident bot Marvin. Having well-written threads helps future users encountering the same problem. Oftentimes your question may have been answered somewhere else; some good resources to start looking before asking a question: Fides Documentation GitHub Issues StackOverflow Rule 5: Don't abuse tagging users Requests for help will be seen by the Fides team, and will be directed to the appropriate person. Tagging individual users is highly discouraged unless it is in the context of a conversation thread. Rule 6: Avoid using DMs to ask for help Fides employees should not be sent questions in DMs unless we specifically ask you to send us private information. There are times when it makes sense to directly message another community member experiencing a similar issue, or working with similar technologies. Just be aware that some people may not want to be messaged. It also helps other people if you post your question publicly. Similar to above, informative Slack threads are archived. Having conversations in public channels drives better quality discussions that can be referenced in the future. Rule 7: Don't advertise material unrelated to Fides Our community is in the channel to learn more about Fides. Showing us Fides-related stuff that you're working on is highly encouraged. Advertising products and events unrelated to Fides will be removed.","title":"Community Hints and Tips"},{"location":"community/hints_tips/#community","text":"The Fides project welcomes issues, contributions and discussion from all users, regardless of background or experience level. In order to create a positive and welcoming environment, all interactions are governed by the Fides Code of Conduct .","title":"Community"},{"location":"community/hints_tips/#guidelines","text":"Whether it's giving us feedback, raising a question, or showing your Fides-related work, we are looking forward to hearing from you. The Fides community is vibrant because of the quality of its members and the discussions they bring. To keep the workspace inviting and helpful for everyone, there are a few guidelines that we ask all members to follow.","title":"Guidelines"},{"location":"community/hints_tips/#rule-1-assume-positive-intent","text":"Being nice is the most important pillar of the Fides community. We are considerate to each other's effort and time. It's also easy to misinterpret people through Slack, so we make an extra effort to chat in a positive tone. We assume that you are here to learn and exchange ideas, and we ask that you contribute to making a welcoming community. If someone is helping you, be mindful of the effort they are putting in. While we are always happy to help users, we can not help users with step-by-step debugging. Use your professional judgment in discerning whether requests are unreasonable. The Fides team always tries to listen to the community. Please be understanding if your issue or feature request is not deemed an immediate priority.","title":"Rule 1: Assume Positive Intent"},{"location":"community/hints_tips/#rule-2-use-threads-for-larger-messages","text":"Because of the size of our community and frequency of posts, it's easy for large messages to drown out smaller messages. Using threads helps people see more messages on their screen. Larger code blocks should be posted in threads.","title":"Rule 2: Use threads for larger messages"},{"location":"community/hints_tips/#rule-3-avoid-posting-sensitive-information","text":"Community members sometimes need to post code snippets as they ask for help. Be sure to remove sensitive information from posts to the public channels. If your Fides account information is needed to help you, we will ask you to direct message such information. Be cautious of anyone asking for information through direct messages.","title":"Rule 3: Avoid posting sensitive information"},{"location":"community/hints_tips/#rule-4-write-high-quality-questions","text":"The Fides community is here to support you. That said, it is significantly easier to answer well-researched and clearly-written questions. Even adding potentially relevant links to a post helps tremendously. Informative Slack threads are archived by our resident bot Marvin. Having well-written threads helps future users encountering the same problem. Oftentimes your question may have been answered somewhere else; some good resources to start looking before asking a question: Fides Documentation GitHub Issues StackOverflow","title":"Rule 4: Write high quality questions"},{"location":"community/hints_tips/#rule-5-dont-abuse-tagging-users","text":"Requests for help will be seen by the Fides team, and will be directed to the appropriate person. Tagging individual users is highly discouraged unless it is in the context of a conversation thread.","title":"Rule 5: Don't abuse tagging users"},{"location":"community/hints_tips/#rule-6-avoid-using-dms-to-ask-for-help","text":"Fides employees should not be sent questions in DMs unless we specifically ask you to send us private information. There are times when it makes sense to directly message another community member experiencing a similar issue, or working with similar technologies. Just be aware that some people may not want to be messaged. It also helps other people if you post your question publicly. Similar to above, informative Slack threads are archived. Having conversations in public channels drives better quality discussions that can be referenced in the future.","title":"Rule 6: Avoid using DMs to ask for help"},{"location":"community/hints_tips/#rule-7-dont-advertise-material-unrelated-to-fides","text":"Our community is in the channel to learn more about Fides. Showing us Fides-related stuff that you're working on is highly encouraged. Advertising products and events unrelated to Fides will be removed.","title":"Rule 7: Don't advertise material unrelated to Fides"},{"location":"community/overview/","text":"Join the Fides Community We believe the only way to solve privacy is as a community of likeminded developers that care to solve these problems for the rest of the world. To make it easier to connect and share ideas, we've created a set of community channels which we'd love to hear from you on: Start Contributing \u2003 Chat on Slack \u2003 Chat on Discord","title":"Github, Slack, and Discord"},{"location":"community/overview/#join-the-fides-community","text":"We believe the only way to solve privacy is as a community of likeminded developers that care to solve these problems for the rest of the world. To make it easier to connect and share ideas, we've created a set of community channels which we'd love to hear from you on: Start Contributing \u2003 Chat on Slack \u2003 Chat on Discord","title":"Join the Fides Community"},{"location":"config/","text":"Configuration Setting Configuration Values Fides can be configured in two different ways: either via a toml file or via environment variables. Both methods can be used simultaneously, with environment variables taking precedence over the toml file values. Using a Configuration File Fides will use the first config file it can read from the following locations. Listed in order of precedence they are: At the path specified using the config file argument passed through the CLI, i.e. fides -f <config_path> At the path specified by the FIDES__CONFIG_PATH environment variable In the current working directory it will check for a subdir .fides and a file within named fides.toml , i.e. ./.fides/fides.toml Generating a Config File If you'd like to generate a new config file automatically using default values, run fides init . This will create the file at the default location of ./.fides/fides.toml Setting Values Via Environment Variables Fides follows a set pattern for configuration via environment variables. It looks for environment variables that start with FIDES followed by the config subsection name, followed by the key name, all separated with double underscores. In practice this would look like FIDES__<SUBSECTION>__<KEY> As a toml configuration value: 1 2 [database] host = config _ example As an environment variable: 1 EXPORT FIDES__DATABASE__HOST = config_example Viewing your configuration You can view the current configuration of your application via either the CLI or API. CLI To view your application configuration via the CLI, run: 1 fides view config This will show all configuration variables, including sensitive ones. It is printed to the console as valid toml , so this can be copy/pasted as needed. API To view your application configuration in the API, run: 1 GET /api/v1/config For security reasons, sensitive configuration values will not be shown here. Special Sections There are a few \"special\" configuration sections that behave in unique ways compared to the other sections. These sections will be addressed in the following documentation. Celery Fides uses Celery for asynchronous task management. To simplify deployments and remove the need for two different toml configuration files, it is possible to configure Celery via the Fides configuration file. Any valid configuration key/value pair for Celery can instead be added to the Fides toml configuration file and will automatically be passed through to the Celery deployment. Note that Fides will not validate any of these key/value pairs. See the above configuration file reference for an example of using celery configuration pass-through. For a full list of possible variable overrides, see the Celery configuration documentation . Example Celery Section 1 2 3 4 [celery] event_queue_prefix = \"fides_worker\" task_default_queue = \"fides\" task_always_eager = true Credentials The credentials section uses custom keys which can be referenced in specific commands that take the --credentials-id option. For example, a command that uses a credential might look like fides scan dataset db --credentials-id app_postgres . The credential object itself will be validated at the time of use depending on what type of credential is required. For instance if fides scan system okta is used, it will expect the object to contain orgUrl and token key/value pairs. In the case of a typical database like postgres, it will only expect a connection_string. The following is an example of what a credentials section might look like in a given deployment with various applications: Example Credentials Section 1 2 [credentials] app_postgres = { connection_string = \"postgresql+psycopg2://postgres:fides@fides-db:5432/fides\" } Configuration File Reference This following file is an autogenerated configuration reference file. It shows application defaults and is a valid toml file that can be used for configuration of Fides. fides.toml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 # Fides Configuration File # Additional Documentation at : https://ethyca.github.io/fides/stable/config/ #--------------# #-- ADMIN_UI --# #--------------------------------------------------------------------# [admin_ui] # Configuration settings for the Admin UI. # Toggle whether the Admin UI is served. enabled = true # boolean #------------# #-- CELERY --# #--------------------------------------------------------------------# [celery] # Configuration settings for Celery. Only a small subset can be configured through Fides env vars # The prefix to use for event receiver queue names event_queue_prefix = \"fides_worker\" # string # The name of the default queue if a message has no route or no custom # queue has been specified task_default_queue = \"fides\" # string # If true, tasks are executed locally instead of being sent to the # queue. If False, tasks are sent to the queue. task_always_eager = true # boolean #---------# #-- CLI --# #--------------------------------------------------------------------# [cli] # Configuration settings for the command-line application. # A fully anonymized unique identifier that is automatically generated # by the application. Used for anonymous analytics when opted-in. analytics_id = \"ed8b148eff59133f52d78700b726958c\" # string # When set to True, disables functionality that requires making calls # to a Fides webserver. local_mode = false # boolean # The protocol used by the Fides webserver. server_protocol = \"http\" # string # The hostname of the Fides webserver. server_host = \"localhost\" # string # The port of the Fides webserver server_port = \"8080\" # string # The path of the Fides webserver server_path = \"/\" # string #-------------# #-- CONSENT --# #--------------------------------------------------------------------# [consent] # Configuration settings for Consent. # Toggle whether TCF is enabled. tcf_enabled = false # boolean # Toggle whether Google AC Mode is enabled. ac_enabled = false # boolean # Whether or not vendor purposes can be globally overridden. override_vendor_purposes = false # boolean #--------------# #-- DATABASE --# #--------------------------------------------------------------------# [database] # Configuration settings for the application database. # Automatically runs migrations on webserver startup. If set to # `false`, will require the user to run migrations manually via the CLI # or API. WARNING: Must be set to `true` for first-time startup. automigrate = true # boolean # Number of concurrent database connections Fides will use for API # requests. Note that the pool begins with no connections, but as they # are requested the connections are maintained and reused up to this # limit. api_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for API requests if the pool reaches the limit. These # overflow connections are discarded afterwards and not maintained. api_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. api_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. api_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. api_engine_keepalives_count = 5 # integer # The name of the application database. db = \"default_db\" # string # When set to True, initializes the database with sample data for # testing (Systems, Datasets, Connectors, etc.) Used by 'fides deploy' # to configure the sample project. load_samples = false # boolean # The password with which to login to the application database. password = \"defaultpassword\" # string # The port at which the application database will be accessible. port = \"5432\" # string # The hostname of the application database server. server = \"default-db\" # string # Number of concurrent database connections Fides will use for # executing privacy request tasks, either locally or on each worker. # Note that the pool begins with no connections, but as they are # requested the connections are maintained and reused up to this limit. task_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for executing privacy request tasks, either locally or on # each worker, if the pool reaches the limit. These overflow # connections are discarded afterwards and not maintained. task_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. task_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. task_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. task_engine_keepalives_count = 5 # integer # The database user with which to login to the application database. user = \"defaultuser\" # string # Additional connection parameters used when connecting to the # application database. params = {} # object #---------------# #-- EXECUTION --# #--------------------------------------------------------------------# [execution] # Configuration settings for DSR execution. # If set to True, only use UPDATE requests to mask data. If False, # Fides will use any defined DELETE or GDPR DELETE endpoints to remove # PII, which may extend beyond the specific data categories that # configured in your execution policy. masking_strict = true # boolean # The amount of time to wait for actions which delay privacy requests # (e.g., pre- and post-processing webhooks). privacy_request_delay_timeout = 3600 # integer # Whether privacy requests require explicit approval to execute. require_manual_request_approval = false # boolean # Whether privacy requests require user identity verification. subject_identity_verification_required = false # boolean # The backoff factor for retries, to space out repeated retries. task_retry_backoff = 1 # integer # The number of times a failed request will be retried. task_retry_count = 0 # integer # The delays between retries in seconds. task_retry_delay = 1 # integer # Allows the collection of custom privacy request fields from incoming # privacy requests. allow_custom_privacy_request_field_collection = false # boolean # Allows custom privacy request fields to be used in request execution. allow_custom_privacy_request_fields_in_request_execution = false # boolean # The number of seconds a request task should live. request_task_ttl = 604800 # integer # Seconds between polling for Privacy Requests that should change state state_polling_interval = 30 # integer # Temporary flag to switch to using DSR 3.0 to process your tasks. use_dsr_3_0 = false # boolean #-------------# #-- LOGGING --# #--------------------------------------------------------------------# [logging] # Configuration settings for application logging. # The output location for log files. Accepts any valid file path. If # left unset, log entries are printed to stdout and log files are not # produced. destination = \"\" # string # Force colored logs. Any value set via environment variables is # considered 'True'. colorize = false # boolean # The minimum log entry level to produce. Also accepts TRACE, DEBUG, # WARNING, ERROR, or CRITICAL (case insensitive). level = \"INFO\" # string # The format with which to produce log entries. If left unset, produces # log entries formatted using the internal custom formatter. Also # accepts 'JSON' (case insensitive). serialization = \"\" # string # If True, PII values will display unmasked in log output. This # variable should always be set to 'False' in production systems. log_pii = false # boolean #-------------------# #-- NOTIFICATIONS --# #--------------------------------------------------------------------# [notifications] # Configuration settings for Data Subject and/or Data Processor notifications. # When set to True, enables subject notifications upon privacy request # completion. send_request_completion_notification = false # boolean # When set to True, enables subject notifications upon privacy request # receipt. send_request_receipt_notification = false # boolean # When set to True, enables subject notifications upon privacy request # review. send_request_review_notification = false # boolean # When set to True, enables property specific messaging feature, # otherwise fall back on the messaging template type env flags set # above. enable_property_specific_messaging = false # boolean #-----------# #-- REDIS --# #--------------------------------------------------------------------# [redis] # Configuration settings for Redis. # Character set to use for Redis, defaults to 'utf8'. Not recommended # to change. charset = \"utf8\" # string # The application will use this index in the Redis cache to cache data. db_index = 0 # integer # Whether or not to automatically decode the values fetched from Redis. # Decodes using the `charset` configuration value. decode_responses = true # boolean # The number of seconds for which data will live in Redis before # automatically expiring. default_ttl_seconds = 604800 # integer # Whether the application's Redis cache should be enabled. Only set to # false for certain narrow uses of the application. enabled = true # boolean # The network address for the application Redis cache. host = \"redis\" # string # Sets TTL for cached identity verification code as part of subject # requests. identity_verification_code_ttl_seconds = 600 # integer # The password with which to login to the Redis cache. password = \"testpassword\" # string # The port at which the application cache will be accessible. port = 6379 # integer # Whether the application's connections to the cache should be # encrypted using TLS. ssl = false # boolean # If using TLS encryption, set this to 'required' if you wish to # enforce the Redis cache to provide a certificate. Note that not all # cache providers support this without setting ssl_ca_certs (e.g. AWS # Elasticache). ssl_cert_reqs = \"required\" # string # If using TLS encryption rooted with a custom Certificate Authority, # set this to the path of the CA certificate. ssl_ca_certs = \"\" # string # The user with which to login to the Redis cache. user = \"\" # string #--------------# #-- SECURITY --# #--------------------------------------------------------------------# [security] # Configuration settings for application security. # Length of desired encryption key when using Fides to generate a # random secure string used for AES encryption. aes_encryption_key_length = 16 # integer # Length of desired random byte str for the AES GCM encryption used # throughout Fides. aes_gcm_nonce_length = 12 # integer # The key used to sign Fides API access tokens. app_encryption_key = \"\" # string # Text encoding to use for the application. encoding = \"UTF-8\" # string # The default, `dev`, does not apply authentication to endpoints # typically used by the CLI. The other option, `prod`, requires # authentication for _all_ endpoints that may contain sensitive # information. env = \"prod\" # string # The number of times identity verification will be attempted before # raising an error. identity_verification_attempt_limit = 3 # integer # The value used to identify the Fides application root API client. oauth_root_client_id = \"\" # string # The secret value used to authenticate the Fides application root API # client. oauth_root_client_secret = \"\" # string # The time in minutes for which Fides API tokens will be valid. Default # value is equal to 8 days. oauth_access_token_expire_minutes = 11520 # integer # Sets desired length in bytes of generated client id used for oauth. oauth_client_id_length_bytes = 16 # integer # Sets desired length in bytes of generated client secret used for # oauth. oauth_client_secret_length_bytes = 16 # integer # The number of requests from a single IP address allowed to hit a # public endpoint within the specified time period public_request_rate_limit = \"2000/minute\" # string # The prefix given to keys in the Redis cache used by the rate limiter. rate_limit_prefix = \"fides-\" # string # The number of requests from a single IP address allowed to hit an # endpoint within a rolling 60 second period. request_rate_limit = \"1000/minute\" # string # The list of scopes that are given to the root user. root_user_scopes = [] # array # The list of roles that are given to the root user. root_user_roles = [] # array # If set to True, the user interface will display a download button for # subject requests. subject_request_download_ui_enabled = false # boolean # If set to True, contributor and owner roles will be able to run test # privacy requests. dsr_testing_tools_enabled = false # boolean # The number of seconds that a pre-signed download URL when using S3 # storage will be valid. The default is equal to 5 days. subject_request_download_link_ttl_seconds = 432000 # integer # Either enables the collection of audit log resource data or bypasses # the middleware enable_audit_log_resource_middleware = false # boolean # The timeout in seconds for the transport socket # (``socket.settimeout``) bastion_server_ssh_timeout = 0.1 # number # The timeout in seconds for tunnel connection (open_channel timeout) bastion_server_ssh_tunnel_timeout = 10 # number #----------# #-- USER --# #--------------------------------------------------------------------# [user] # Configuration settings that apply to the current user as opposed to the entire application instance. # When set to true, prevents sending privacy-respecting anonymous # analytics data to Ethyca. analytics_opt_out = true # boolean # An arbitrary string used to encrypt the user data stored in the # database. Encryption is implemented using PGP. encryption_key = \"test_encryption_key\" # string # The username used to log into the Fides webserver. username = \"\" # string # The password used to log into the Fides webserver. password = \"\" # string #-----------------# #-- CREDENTIALS --# #--------------------------------------------------------------------# [credentials] # This is a special section that is used to store arbitrary key/value pairs to be used as credentials. # For more info, please visit: https://ethyca.github.io/fides/stable/config/#credentials","title":"Configuration"},{"location":"config/#configuration","text":"","title":"Configuration"},{"location":"config/#setting-configuration-values","text":"Fides can be configured in two different ways: either via a toml file or via environment variables. Both methods can be used simultaneously, with environment variables taking precedence over the toml file values.","title":"Setting Configuration Values"},{"location":"config/#using-a-configuration-file","text":"Fides will use the first config file it can read from the following locations. Listed in order of precedence they are: At the path specified using the config file argument passed through the CLI, i.e. fides -f <config_path> At the path specified by the FIDES__CONFIG_PATH environment variable In the current working directory it will check for a subdir .fides and a file within named fides.toml , i.e. ./.fides/fides.toml","title":"Using a Configuration File"},{"location":"config/#generating-a-config-file","text":"If you'd like to generate a new config file automatically using default values, run fides init . This will create the file at the default location of ./.fides/fides.toml","title":"Generating a Config File"},{"location":"config/#setting-values-via-environment-variables","text":"Fides follows a set pattern for configuration via environment variables. It looks for environment variables that start with FIDES followed by the config subsection name, followed by the key name, all separated with double underscores. In practice this would look like FIDES__<SUBSECTION>__<KEY> As a toml configuration value: 1 2 [database] host = config _ example As an environment variable: 1 EXPORT FIDES__DATABASE__HOST = config_example","title":"Setting Values Via Environment Variables"},{"location":"config/#viewing-your-configuration","text":"You can view the current configuration of your application via either the CLI or API.","title":"Viewing your configuration"},{"location":"config/#cli","text":"To view your application configuration via the CLI, run: 1 fides view config This will show all configuration variables, including sensitive ones. It is printed to the console as valid toml , so this can be copy/pasted as needed.","title":"CLI"},{"location":"config/#api","text":"To view your application configuration in the API, run: 1 GET /api/v1/config For security reasons, sensitive configuration values will not be shown here.","title":"API"},{"location":"config/#special-sections","text":"There are a few \"special\" configuration sections that behave in unique ways compared to the other sections. These sections will be addressed in the following documentation.","title":"Special Sections"},{"location":"config/#celery","text":"Fides uses Celery for asynchronous task management. To simplify deployments and remove the need for two different toml configuration files, it is possible to configure Celery via the Fides configuration file. Any valid configuration key/value pair for Celery can instead be added to the Fides toml configuration file and will automatically be passed through to the Celery deployment. Note that Fides will not validate any of these key/value pairs. See the above configuration file reference for an example of using celery configuration pass-through. For a full list of possible variable overrides, see the Celery configuration documentation . Example Celery Section 1 2 3 4 [celery] event_queue_prefix = \"fides_worker\" task_default_queue = \"fides\" task_always_eager = true","title":"Celery"},{"location":"config/#credentials","text":"The credentials section uses custom keys which can be referenced in specific commands that take the --credentials-id option. For example, a command that uses a credential might look like fides scan dataset db --credentials-id app_postgres . The credential object itself will be validated at the time of use depending on what type of credential is required. For instance if fides scan system okta is used, it will expect the object to contain orgUrl and token key/value pairs. In the case of a typical database like postgres, it will only expect a connection_string. The following is an example of what a credentials section might look like in a given deployment with various applications: Example Credentials Section 1 2 [credentials] app_postgres = { connection_string = \"postgresql+psycopg2://postgres:fides@fides-db:5432/fides\" }","title":"Credentials"},{"location":"config/#configuration-file-reference","text":"This following file is an autogenerated configuration reference file. It shows application defaults and is a valid toml file that can be used for configuration of Fides. fides.toml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 # Fides Configuration File # Additional Documentation at : https://ethyca.github.io/fides/stable/config/ #--------------# #-- ADMIN_UI --# #--------------------------------------------------------------------# [admin_ui] # Configuration settings for the Admin UI. # Toggle whether the Admin UI is served. enabled = true # boolean #------------# #-- CELERY --# #--------------------------------------------------------------------# [celery] # Configuration settings for Celery. Only a small subset can be configured through Fides env vars # The prefix to use for event receiver queue names event_queue_prefix = \"fides_worker\" # string # The name of the default queue if a message has no route or no custom # queue has been specified task_default_queue = \"fides\" # string # If true, tasks are executed locally instead of being sent to the # queue. If False, tasks are sent to the queue. task_always_eager = true # boolean #---------# #-- CLI --# #--------------------------------------------------------------------# [cli] # Configuration settings for the command-line application. # A fully anonymized unique identifier that is automatically generated # by the application. Used for anonymous analytics when opted-in. analytics_id = \"ed8b148eff59133f52d78700b726958c\" # string # When set to True, disables functionality that requires making calls # to a Fides webserver. local_mode = false # boolean # The protocol used by the Fides webserver. server_protocol = \"http\" # string # The hostname of the Fides webserver. server_host = \"localhost\" # string # The port of the Fides webserver server_port = \"8080\" # string # The path of the Fides webserver server_path = \"/\" # string #-------------# #-- CONSENT --# #--------------------------------------------------------------------# [consent] # Configuration settings for Consent. # Toggle whether TCF is enabled. tcf_enabled = false # boolean # Toggle whether Google AC Mode is enabled. ac_enabled = false # boolean # Whether or not vendor purposes can be globally overridden. override_vendor_purposes = false # boolean #--------------# #-- DATABASE --# #--------------------------------------------------------------------# [database] # Configuration settings for the application database. # Automatically runs migrations on webserver startup. If set to # `false`, will require the user to run migrations manually via the CLI # or API. WARNING: Must be set to `true` for first-time startup. automigrate = true # boolean # Number of concurrent database connections Fides will use for API # requests. Note that the pool begins with no connections, but as they # are requested the connections are maintained and reused up to this # limit. api_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for API requests if the pool reaches the limit. These # overflow connections are discarded afterwards and not maintained. api_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. api_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. api_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. api_engine_keepalives_count = 5 # integer # The name of the application database. db = \"default_db\" # string # When set to True, initializes the database with sample data for # testing (Systems, Datasets, Connectors, etc.) Used by 'fides deploy' # to configure the sample project. load_samples = false # boolean # The password with which to login to the application database. password = \"defaultpassword\" # string # The port at which the application database will be accessible. port = \"5432\" # string # The hostname of the application database server. server = \"default-db\" # string # Number of concurrent database connections Fides will use for # executing privacy request tasks, either locally or on each worker. # Note that the pool begins with no connections, but as they are # requested the connections are maintained and reused up to this limit. task_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for executing privacy request tasks, either locally or on # each worker, if the pool reaches the limit. These overflow # connections are discarded afterwards and not maintained. task_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. task_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. task_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. task_engine_keepalives_count = 5 # integer # The database user with which to login to the application database. user = \"defaultuser\" # string # Additional connection parameters used when connecting to the # application database. params = {} # object #---------------# #-- EXECUTION --# #--------------------------------------------------------------------# [execution] # Configuration settings for DSR execution. # If set to True, only use UPDATE requests to mask data. If False, # Fides will use any defined DELETE or GDPR DELETE endpoints to remove # PII, which may extend beyond the specific data categories that # configured in your execution policy. masking_strict = true # boolean # The amount of time to wait for actions which delay privacy requests # (e.g., pre- and post-processing webhooks). privacy_request_delay_timeout = 3600 # integer # Whether privacy requests require explicit approval to execute. require_manual_request_approval = false # boolean # Whether privacy requests require user identity verification. subject_identity_verification_required = false # boolean # The backoff factor for retries, to space out repeated retries. task_retry_backoff = 1 # integer # The number of times a failed request will be retried. task_retry_count = 0 # integer # The delays between retries in seconds. task_retry_delay = 1 # integer # Allows the collection of custom privacy request fields from incoming # privacy requests. allow_custom_privacy_request_field_collection = false # boolean # Allows custom privacy request fields to be used in request execution. allow_custom_privacy_request_fields_in_request_execution = false # boolean # The number of seconds a request task should live. request_task_ttl = 604800 # integer # Seconds between polling for Privacy Requests that should change state state_polling_interval = 30 # integer # Temporary flag to switch to using DSR 3.0 to process your tasks. use_dsr_3_0 = false # boolean #-------------# #-- LOGGING --# #--------------------------------------------------------------------# [logging] # Configuration settings for application logging. # The output location for log files. Accepts any valid file path. If # left unset, log entries are printed to stdout and log files are not # produced. destination = \"\" # string # Force colored logs. Any value set via environment variables is # considered 'True'. colorize = false # boolean # The minimum log entry level to produce. Also accepts TRACE, DEBUG, # WARNING, ERROR, or CRITICAL (case insensitive). level = \"INFO\" # string # The format with which to produce log entries. If left unset, produces # log entries formatted using the internal custom formatter. Also # accepts 'JSON' (case insensitive). serialization = \"\" # string # If True, PII values will display unmasked in log output. This # variable should always be set to 'False' in production systems. log_pii = false # boolean #-------------------# #-- NOTIFICATIONS --# #--------------------------------------------------------------------# [notifications] # Configuration settings for Data Subject and/or Data Processor notifications. # When set to True, enables subject notifications upon privacy request # completion. send_request_completion_notification = false # boolean # When set to True, enables subject notifications upon privacy request # receipt. send_request_receipt_notification = false # boolean # When set to True, enables subject notifications upon privacy request # review. send_request_review_notification = false # boolean # When set to True, enables property specific messaging feature, # otherwise fall back on the messaging template type env flags set # above. enable_property_specific_messaging = false # boolean #-----------# #-- REDIS --# #--------------------------------------------------------------------# [redis] # Configuration settings for Redis. # Character set to use for Redis, defaults to 'utf8'. Not recommended # to change. charset = \"utf8\" # string # The application will use this index in the Redis cache to cache data. db_index = 0 # integer # Whether or not to automatically decode the values fetched from Redis. # Decodes using the `charset` configuration value. decode_responses = true # boolean # The number of seconds for which data will live in Redis before # automatically expiring. default_ttl_seconds = 604800 # integer # Whether the application's Redis cache should be enabled. Only set to # false for certain narrow uses of the application. enabled = true # boolean # The network address for the application Redis cache. host = \"redis\" # string # Sets TTL for cached identity verification code as part of subject # requests. identity_verification_code_ttl_seconds = 600 # integer # The password with which to login to the Redis cache. password = \"testpassword\" # string # The port at which the application cache will be accessible. port = 6379 # integer # Whether the application's connections to the cache should be # encrypted using TLS. ssl = false # boolean # If using TLS encryption, set this to 'required' if you wish to # enforce the Redis cache to provide a certificate. Note that not all # cache providers support this without setting ssl_ca_certs (e.g. AWS # Elasticache). ssl_cert_reqs = \"required\" # string # If using TLS encryption rooted with a custom Certificate Authority, # set this to the path of the CA certificate. ssl_ca_certs = \"\" # string # The user with which to login to the Redis cache. user = \"\" # string #--------------# #-- SECURITY --# #--------------------------------------------------------------------# [security] # Configuration settings for application security. # Length of desired encryption key when using Fides to generate a # random secure string used for AES encryption. aes_encryption_key_length = 16 # integer # Length of desired random byte str for the AES GCM encryption used # throughout Fides. aes_gcm_nonce_length = 12 # integer # The key used to sign Fides API access tokens. app_encryption_key = \"\" # string # Text encoding to use for the application. encoding = \"UTF-8\" # string # The default, `dev`, does not apply authentication to endpoints # typically used by the CLI. The other option, `prod`, requires # authentication for _all_ endpoints that may contain sensitive # information. env = \"prod\" # string # The number of times identity verification will be attempted before # raising an error. identity_verification_attempt_limit = 3 # integer # The value used to identify the Fides application root API client. oauth_root_client_id = \"\" # string # The secret value used to authenticate the Fides application root API # client. oauth_root_client_secret = \"\" # string # The time in minutes for which Fides API tokens will be valid. Default # value is equal to 8 days. oauth_access_token_expire_minutes = 11520 # integer # Sets desired length in bytes of generated client id used for oauth. oauth_client_id_length_bytes = 16 # integer # Sets desired length in bytes of generated client secret used for # oauth. oauth_client_secret_length_bytes = 16 # integer # The number of requests from a single IP address allowed to hit a # public endpoint within the specified time period public_request_rate_limit = \"2000/minute\" # string # The prefix given to keys in the Redis cache used by the rate limiter. rate_limit_prefix = \"fides-\" # string # The number of requests from a single IP address allowed to hit an # endpoint within a rolling 60 second period. request_rate_limit = \"1000/minute\" # string # The list of scopes that are given to the root user. root_user_scopes = [] # array # The list of roles that are given to the root user. root_user_roles = [] # array # If set to True, the user interface will display a download button for # subject requests. subject_request_download_ui_enabled = false # boolean # If set to True, contributor and owner roles will be able to run test # privacy requests. dsr_testing_tools_enabled = false # boolean # The number of seconds that a pre-signed download URL when using S3 # storage will be valid. The default is equal to 5 days. subject_request_download_link_ttl_seconds = 432000 # integer # Either enables the collection of audit log resource data or bypasses # the middleware enable_audit_log_resource_middleware = false # boolean # The timeout in seconds for the transport socket # (``socket.settimeout``) bastion_server_ssh_timeout = 0.1 # number # The timeout in seconds for tunnel connection (open_channel timeout) bastion_server_ssh_tunnel_timeout = 10 # number #----------# #-- USER --# #--------------------------------------------------------------------# [user] # Configuration settings that apply to the current user as opposed to the entire application instance. # When set to true, prevents sending privacy-respecting anonymous # analytics data to Ethyca. analytics_opt_out = true # boolean # An arbitrary string used to encrypt the user data stored in the # database. Encryption is implemented using PGP. encryption_key = \"test_encryption_key\" # string # The username used to log into the Fides webserver. username = \"\" # string # The password used to log into the Fides webserver. password = \"\" # string #-----------------# #-- CREDENTIALS --# #--------------------------------------------------------------------# [credentials] # This is a special section that is used to store arbitrary key/value pairs to be used as credentials. # For more info, please visit: https://ethyca.github.io/fides/stable/config/#credentials","title":"Configuration File Reference"},{"location":"development/code_style/","text":"Code Style General Docstrings Docstrings are required for every function, class, and method. No specific style is required or encouraged, as we expect that most of the relevant information can be gleaned from both the function signature's type-hints as well as descriptive parameter names. The docstring should serve to give additional context/flavour beyond that which can be gained from the code itself. Docstring Example 1 2 3 4 5 6 7 8 9 10 11 12 # Bad def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Execute an evaluation. \"\"\" # Good def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Check the stated constraints of each Privacy Policy's rules against each system's privacy declarations. \"\"\" Variable and parameter naming Variable and parameter names should be as self-describing as possible. Brevity is not a concern here. Here are some common examples for writing good self-documenting code: Single Letter Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 # Incorrect s = 726 # Correct elapsed_time_seconds = 726 # Incorrect for n in nodes : print ( n ) # Correct for node in nodes : print ( node ) Abbreviated Variable Names 1 2 3 4 5 6 7 8 # Incorrect r = requests . get ( url ) # Incorrect resp = reqeusts . get ( url ) # Correct response = requests . get ( url ) Type Ambiguous Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Incorrect food = [ \"apple\" , \"banana\" ] # Incorrect foods = [ \"apple\" , \"banana\" ] # Correct # Use type annotations if the name is somewhat ambiguous foods : List [ str ] = [ \"apple\" , \"banana\" ] # Correct # The type is contained in the name foods_list = [ \"apple\" , \"banana\" ] # Correct # Both of the above styles foods_list : List [ str ] = [ \"apple\" , \"banana\" ] Pre-commit hooks Fides includes a .pre-commit-config.yaml to facilitate running CI checks before pushing up to a PR. The pre-commit package is included in the dev-requirements.txt . Once that is installed, follow these steps to get up and running: pre-commit install - This is a one-time setup step to create the git pre-commit hooks. These pre-commit hooks will now run automatically. However you can also use pre-commit run to run them manually once all of your changes have been staged. NOTE : A Python interpreter must be available from wherever the git commands are being run, as this is required to run the pre-commit package. CI checks CI checks are stored as targets within the Noxfile, and can be run from the top-level fides directory with the following pattern: Pattern 1 nox -s <lowercased_name> Examples 1 2 3 nox -s black nox -s mypy nox -s xenon Additionally, there is a single command that will run all static check tools at once: nox -s static_checks Black formatting Fides' code is formatted using the black style. This style is checked in a CI step, and merges to master are prevented if code does not conform. A number of extensions are available for popular editors that will automatically apply black to your code. Pylint Fides' code is linted using pylint . Linter checks run as part of a CI step and merges to master are prevented if code does not conform. Mypy Fides' code is statically-typed using mypy . Type checking is validated as a CI step, and merges to master are prevented if code does not pass type checks. As a general rule, mypy typing requires all function arguments and return values to be annotated. Xenon Fides' code is checked for its cyclomatic-complexity by Xenon. If a single logical piece of code is deemed too complex, then a CI step will fail, at which point the focus should be on breaking up said complex function/method/class.","title":"Code Style"},{"location":"development/code_style/#code-style","text":"","title":"Code Style"},{"location":"development/code_style/#general","text":"","title":"General"},{"location":"development/code_style/#docstrings","text":"Docstrings are required for every function, class, and method. No specific style is required or encouraged, as we expect that most of the relevant information can be gleaned from both the function signature's type-hints as well as descriptive parameter names. The docstring should serve to give additional context/flavour beyond that which can be gained from the code itself. Docstring Example 1 2 3 4 5 6 7 8 9 10 11 12 # Bad def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Execute an evaluation. \"\"\" # Good def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Check the stated constraints of each Privacy Policy's rules against each system's privacy declarations. \"\"\"","title":"Docstrings"},{"location":"development/code_style/#variable-and-parameter-naming","text":"Variable and parameter names should be as self-describing as possible. Brevity is not a concern here. Here are some common examples for writing good self-documenting code: Single Letter Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 # Incorrect s = 726 # Correct elapsed_time_seconds = 726 # Incorrect for n in nodes : print ( n ) # Correct for node in nodes : print ( node ) Abbreviated Variable Names 1 2 3 4 5 6 7 8 # Incorrect r = requests . get ( url ) # Incorrect resp = reqeusts . get ( url ) # Correct response = requests . get ( url ) Type Ambiguous Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Incorrect food = [ \"apple\" , \"banana\" ] # Incorrect foods = [ \"apple\" , \"banana\" ] # Correct # Use type annotations if the name is somewhat ambiguous foods : List [ str ] = [ \"apple\" , \"banana\" ] # Correct # The type is contained in the name foods_list = [ \"apple\" , \"banana\" ] # Correct # Both of the above styles foods_list : List [ str ] = [ \"apple\" , \"banana\" ]","title":"Variable and parameter naming"},{"location":"development/code_style/#pre-commit-hooks","text":"Fides includes a .pre-commit-config.yaml to facilitate running CI checks before pushing up to a PR. The pre-commit package is included in the dev-requirements.txt . Once that is installed, follow these steps to get up and running: pre-commit install - This is a one-time setup step to create the git pre-commit hooks. These pre-commit hooks will now run automatically. However you can also use pre-commit run to run them manually once all of your changes have been staged. NOTE : A Python interpreter must be available from wherever the git commands are being run, as this is required to run the pre-commit package.","title":"Pre-commit hooks"},{"location":"development/code_style/#ci-checks","text":"CI checks are stored as targets within the Noxfile, and can be run from the top-level fides directory with the following pattern: Pattern 1 nox -s <lowercased_name> Examples 1 2 3 nox -s black nox -s mypy nox -s xenon Additionally, there is a single command that will run all static check tools at once: nox -s static_checks","title":"CI checks"},{"location":"development/code_style/#black-formatting","text":"Fides' code is formatted using the black style. This style is checked in a CI step, and merges to master are prevented if code does not conform. A number of extensions are available for popular editors that will automatically apply black to your code.","title":"Black formatting"},{"location":"development/code_style/#pylint","text":"Fides' code is linted using pylint . Linter checks run as part of a CI step and merges to master are prevented if code does not conform.","title":"Pylint"},{"location":"development/code_style/#mypy","text":"Fides' code is statically-typed using mypy . Type checking is validated as a CI step, and merges to master are prevented if code does not pass type checks. As a general rule, mypy typing requires all function arguments and return values to be annotated.","title":"Mypy"},{"location":"development/code_style/#xenon","text":"Fides' code is checked for its cyclomatic-complexity by Xenon. If a single logical piece of code is deemed too complex, then a CI step will fail, at which point the focus should be on breaking up said complex function/method/class.","title":"Xenon"},{"location":"development/developing_fides/","text":"Developing Fides The primary developer interface for Fides is via a tool called Nox. Nox is a pure-Python replacement for tools like make . You can read more about Nox in the official documentation here . \u26a0\ufe0f Warning If you install nox using pipx , you may run into issues with it not detecting your Python version correctly. Install it using pip instead. Additionally, much of what nox helps abstract is related to Docker. This usually makes it possible to troubleshoot potential nox issues by using various Docker commands directly. If you haven't already, read the Requirements Installation Guide to get up and running with the required tools and optimal configurations. Terminology For the purposes of this documentation, there is some Nox-specific terminology that is used and is helpful to understand before reading the rest of the guide. session - This is the equivalent of a single command, or a target in Make. They can be chained together arbitrarily, and the order of execution will be preserved. For example nox -s isort black posarg - This refers to a Positional Argument . These can be provided to any Nox command by putting -- at the end of a command followed by the argument that you would like to provide. For instance nox -s dev -- shell param - This is a specified value that is provided directly to a session. For instance nox -s \"isort(<param>)\" . Note that due to terminal limitations, the session + param must be wrapped in quotes for proper escaping. Additionally, if a session has multiple params but none are specific, all permutations of that session will be run. Sessions to Know While there are many sessions available in our nox setup, these are the ones that you are most likely to use regularly. This is intended as a brief introduction, as many of these commands will be explained further in specific sections below. Command Description nox This is the default session that runs when no other session is provided. Automatically opens this page. nox -l Provides a list of all available nox sessions. nox -s usage -- <command> Shows the full docstring for a single session. The name of the session is provided as a positional argument. Use this whenever you want to know more about a specific session's usage. nox -s dev Spins up the Fides webserver with all required infrastructure. nox -s shell Opens an interactive shell in a running Fides webserver container. nox -s build Builds and tags docker containers. nox -s clean Completely wipes out all Docker volumes, images, and caches across the entire machine. Note: This should only be used as a last resort! If you find yourself running this command often, there is probably an issue that needs to be addressed. nox -s teardown Spins down all of the Docker containers for the Fides project. Including the -- volumes posarg will also delete the application database data. Getting Started This section will run through the basics of getting everything up and running so that you can start making changes. Docker Given that the majority of commands rely on Docker images, the first step is going to be getting some Docker images built. This is handled by the build session. As an excercise, let's check the docs for the build session via the usage session: 1 nox -s usage -- build The simplest way to build everything is to run nox -s build . This will build all available Docker images used for development and testing. Additionally, to build only a specific image(s), run nox -s usage -- build to see what params have been documented. Running the Webserver Now that all of the potential images we'll need are built, it's time to spin up the webserver: nox -s dev Depending on your computer, this will take anywhere from ~30 seconds to ~2 minutes. The webserver will log all of its activity to that window which is useful for debugging and checking potential server-side errors. Warning When running nox -s dev , if you get an importlib.metadata.PackageNotFoundError: fides , it means that fides was not properly installed. Run nox -s dev -- shell , and then run pip install -e . You can verify Fides is installed with pip list | grep fides Opening a Shell Now that the webserver is up and running, a convenient way to interact with it as well as the Fides CLI is to open a shell directly into the running webserver container. Open a new terminal and run the following: nox -s shell With the shell open, we'll need to authenticate before we can start using the CLI. Run the following to authenticate the shell and get ready to run the CLI: fides user login With that done, we can do things like evaluations: fides evaluate Listing all resources of a type: fides ls system and more. Run fides -h to see the full list of commands offered by the CLI. Checking Your Changes Once you've made some changes, it's time to verify that they are working as expected. If you've made changes to the CLI, you can verify them directly using the shell method described here . If you've made an API change, there are a few different ways to verify your changes. The first and most simple is to go to localhost:8080/docs and verify that the changes you made show up as expected in the documentation. This is most useful when adding a new endpoint or changing a schema. To dig in even deeper, you can use the Authorize button at the top of the API docs page to login (credentials are available in the .fides/fides.toml config file). This will allow you to send requests, view responses, etc. Running Tests For a full walkthrough on testing, head over to the Testing page. Static Checks For the sake of simplicity, all of the typical pre-commit static checks are packaged into a single session: nox -s static_checks This installs and runs the various checks in their own virtual environment for maximum consistency. For more information about code style in Fides, check Code Style . Debugging Fides in VSCode This is a quick guide to show how VSCode can be used to debug Fides running locally in Docker. The general approach is to allow the local fides Docker Compose service to allow remote debugging connections, and to start a remote debugger from a host VSCode workspace. Setup Run Fides with Remote Debugging Enabled In order to accept incoming remote debugging connections, the fides Docker Compose service must be run with slight alterations. To enable this functionality, simply add the remote_debug flag to a nox command. For example: nox -s dev -- remote_debug or nox -s dev -- remote_debug postgres timescale With those commands, the fides Docker Compose service that's running the Fides server locally is able to accept incoming remote debugging connections. Note that, at this point, the remote_debug flag is not enabled for other nox sessions, e.g. fides_env , pytest_ops , etc. Attach a Remote Debugger to the Fides Server Now that the running Fides server can accept incoming remote debugging connections, you can attach a remote debugger from a local VSCode workspace to actively debug the server application. A launch configuration is included in the fides repo to facilitate this step. Open up the fides repo in a VSCode workspace Go to the Run and Debug view From the debugger dropdown list, select the Python debugger: Remote Attach Fides configuration Click the Start Debugging play button The remote debugger should now be attached to the Fides server! To confirm the debugger is attached, at least one RUNNING line item should appear in the CALL STACK window Debug! At this point, VSCode is ready to debug the running Fides server. Try setting breakpoints and hitting them by, e.g., making certain HTTP requests against the Fides server. This guide provides more information on how to use the VSCode Python debugger. Links Some relevant VSCode documentation for reference: https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection https://code.visualstudio.com/docs/python/python-tutorial#_configure-and-run-the-debugger Debugging Fides in IntelliJ IDEA Ultimate This guide will show how to use the IntelliJ debugger with Fides running in Docker. The setup for PyCharm Professional should be very similar. Prerequisites Intellij IDEA Ultimate or PyCharm Professional Docker plugin Python plugin (this is needed for Intellij) Docker Desktop Setup Connect to Docker daemon This step will allow the IDE to connect to Docker Desktop. Go to: Settings/Preferences -> Docker -> + Select Docker for \"your operating system\" See the screenshot below: Configure Python Remote Interpreter Define a Docker-based remote interpreter. Go to: File -> Project Structure... -> Platform Settings -> SDKs -> + Set Server to Docker Set Configuration files to .docker-compose.yml Set Python interpreter path to python After clicking OK the Remote Python Docker Compose should be listed as an SDK. See screenshots below: Run/Debug Configuration Set up a Run/Debug Configuration so that breakpoints can be hit in the f sourcecode. Go to: Run/Debug Configurations -> + -> Python To debug Fides, debug the <path on your machine>/src/fides/main.py script Make sure to select Use specified interpreter set the Remote Python Docker Compose (created in the previous section) Add FIDES__CONFIG_PATH=/fides to Environment variables See screenshot below: Hit a Breakpoint Now the IDE is ready to debug the source code. Click the debug button for main (setup in the previous section) . Try firing a http request to Fides from Postman or Curl and hit a break point. There is a postman collection in this repo: docs/fides/docs/development/postman/Fides.postman_collection.json Screenshot of hit breakpoint below: Links The information is this guide is largely based on these docs https://www.jetbrains.com/help/pycharm/using-docker-as-a-remote-interpreter.html https://www.jetbrains.com/help/idea/configuring-local-python-interpreters.html","title":"Developing Fides"},{"location":"development/developing_fides/#developing-fides","text":"The primary developer interface for Fides is via a tool called Nox. Nox is a pure-Python replacement for tools like make . You can read more about Nox in the official documentation here . \u26a0\ufe0f Warning If you install nox using pipx , you may run into issues with it not detecting your Python version correctly. Install it using pip instead. Additionally, much of what nox helps abstract is related to Docker. This usually makes it possible to troubleshoot potential nox issues by using various Docker commands directly. If you haven't already, read the Requirements Installation Guide to get up and running with the required tools and optimal configurations.","title":"Developing Fides"},{"location":"development/developing_fides/#terminology","text":"For the purposes of this documentation, there is some Nox-specific terminology that is used and is helpful to understand before reading the rest of the guide. session - This is the equivalent of a single command, or a target in Make. They can be chained together arbitrarily, and the order of execution will be preserved. For example nox -s isort black posarg - This refers to a Positional Argument . These can be provided to any Nox command by putting -- at the end of a command followed by the argument that you would like to provide. For instance nox -s dev -- shell param - This is a specified value that is provided directly to a session. For instance nox -s \"isort(<param>)\" . Note that due to terminal limitations, the session + param must be wrapped in quotes for proper escaping. Additionally, if a session has multiple params but none are specific, all permutations of that session will be run.","title":"Terminology"},{"location":"development/developing_fides/#sessions-to-know","text":"While there are many sessions available in our nox setup, these are the ones that you are most likely to use regularly. This is intended as a brief introduction, as many of these commands will be explained further in specific sections below. Command Description nox This is the default session that runs when no other session is provided. Automatically opens this page. nox -l Provides a list of all available nox sessions. nox -s usage -- <command> Shows the full docstring for a single session. The name of the session is provided as a positional argument. Use this whenever you want to know more about a specific session's usage. nox -s dev Spins up the Fides webserver with all required infrastructure. nox -s shell Opens an interactive shell in a running Fides webserver container. nox -s build Builds and tags docker containers. nox -s clean Completely wipes out all Docker volumes, images, and caches across the entire machine. Note: This should only be used as a last resort! If you find yourself running this command often, there is probably an issue that needs to be addressed. nox -s teardown Spins down all of the Docker containers for the Fides project. Including the -- volumes posarg will also delete the application database data.","title":"Sessions to Know"},{"location":"development/developing_fides/#getting-started","text":"This section will run through the basics of getting everything up and running so that you can start making changes.","title":"Getting Started"},{"location":"development/developing_fides/#docker","text":"Given that the majority of commands rely on Docker images, the first step is going to be getting some Docker images built. This is handled by the build session. As an excercise, let's check the docs for the build session via the usage session: 1 nox -s usage -- build The simplest way to build everything is to run nox -s build . This will build all available Docker images used for development and testing. Additionally, to build only a specific image(s), run nox -s usage -- build to see what params have been documented.","title":"Docker"},{"location":"development/developing_fides/#running-the-webserver","text":"Now that all of the potential images we'll need are built, it's time to spin up the webserver: nox -s dev Depending on your computer, this will take anywhere from ~30 seconds to ~2 minutes. The webserver will log all of its activity to that window which is useful for debugging and checking potential server-side errors. Warning When running nox -s dev , if you get an importlib.metadata.PackageNotFoundError: fides , it means that fides was not properly installed. Run nox -s dev -- shell , and then run pip install -e . You can verify Fides is installed with pip list | grep fides","title":"Running the Webserver"},{"location":"development/developing_fides/#opening-a-shell","text":"Now that the webserver is up and running, a convenient way to interact with it as well as the Fides CLI is to open a shell directly into the running webserver container. Open a new terminal and run the following: nox -s shell With the shell open, we'll need to authenticate before we can start using the CLI. Run the following to authenticate the shell and get ready to run the CLI: fides user login With that done, we can do things like evaluations: fides evaluate Listing all resources of a type: fides ls system and more. Run fides -h to see the full list of commands offered by the CLI.","title":"Opening a Shell"},{"location":"development/developing_fides/#checking-your-changes","text":"Once you've made some changes, it's time to verify that they are working as expected. If you've made changes to the CLI, you can verify them directly using the shell method described here . If you've made an API change, there are a few different ways to verify your changes. The first and most simple is to go to localhost:8080/docs and verify that the changes you made show up as expected in the documentation. This is most useful when adding a new endpoint or changing a schema. To dig in even deeper, you can use the Authorize button at the top of the API docs page to login (credentials are available in the .fides/fides.toml config file). This will allow you to send requests, view responses, etc.","title":"Checking Your Changes"},{"location":"development/developing_fides/#running-tests","text":"For a full walkthrough on testing, head over to the Testing page.","title":"Running Tests"},{"location":"development/developing_fides/#static-checks","text":"For the sake of simplicity, all of the typical pre-commit static checks are packaged into a single session: nox -s static_checks This installs and runs the various checks in their own virtual environment for maximum consistency. For more information about code style in Fides, check Code Style .","title":"Static Checks"},{"location":"development/developing_fides/#debugging-fides-in-vscode","text":"This is a quick guide to show how VSCode can be used to debug Fides running locally in Docker. The general approach is to allow the local fides Docker Compose service to allow remote debugging connections, and to start a remote debugger from a host VSCode workspace.","title":"Debugging Fides in VSCode"},{"location":"development/developing_fides/#setup","text":"","title":"Setup"},{"location":"development/developing_fides/#run-fides-with-remote-debugging-enabled","text":"In order to accept incoming remote debugging connections, the fides Docker Compose service must be run with slight alterations. To enable this functionality, simply add the remote_debug flag to a nox command. For example: nox -s dev -- remote_debug or nox -s dev -- remote_debug postgres timescale With those commands, the fides Docker Compose service that's running the Fides server locally is able to accept incoming remote debugging connections. Note that, at this point, the remote_debug flag is not enabled for other nox sessions, e.g. fides_env , pytest_ops , etc.","title":"Run Fides with Remote Debugging Enabled"},{"location":"development/developing_fides/#attach-a-remote-debugger-to-the-fides-server","text":"Now that the running Fides server can accept incoming remote debugging connections, you can attach a remote debugger from a local VSCode workspace to actively debug the server application. A launch configuration is included in the fides repo to facilitate this step. Open up the fides repo in a VSCode workspace Go to the Run and Debug view From the debugger dropdown list, select the Python debugger: Remote Attach Fides configuration Click the Start Debugging play button The remote debugger should now be attached to the Fides server! To confirm the debugger is attached, at least one RUNNING line item should appear in the CALL STACK window","title":"Attach a Remote Debugger to the Fides Server"},{"location":"development/developing_fides/#debug","text":"At this point, VSCode is ready to debug the running Fides server. Try setting breakpoints and hitting them by, e.g., making certain HTTP requests against the Fides server. This guide provides more information on how to use the VSCode Python debugger.","title":"Debug!"},{"location":"development/developing_fides/#links","text":"Some relevant VSCode documentation for reference: https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection https://code.visualstudio.com/docs/python/python-tutorial#_configure-and-run-the-debugger","title":"Links"},{"location":"development/developing_fides/#debugging-fides-in-intellij-idea-ultimate","text":"This guide will show how to use the IntelliJ debugger with Fides running in Docker. The setup for PyCharm Professional should be very similar.","title":"Debugging Fides in IntelliJ IDEA Ultimate"},{"location":"development/developing_fides/#prerequisites","text":"Intellij IDEA Ultimate or PyCharm Professional Docker plugin Python plugin (this is needed for Intellij) Docker Desktop","title":"Prerequisites"},{"location":"development/developing_fides/#setup_1","text":"","title":"Setup"},{"location":"development/developing_fides/#connect-to-docker-daemon","text":"This step will allow the IDE to connect to Docker Desktop. Go to: Settings/Preferences -> Docker -> + Select Docker for \"your operating system\" See the screenshot below:","title":"Connect to Docker daemon"},{"location":"development/developing_fides/#configure-python-remote-interpreter","text":"Define a Docker-based remote interpreter. Go to: File -> Project Structure... -> Platform Settings -> SDKs -> + Set Server to Docker Set Configuration files to .docker-compose.yml Set Python interpreter path to python After clicking OK the Remote Python Docker Compose should be listed as an SDK. See screenshots below:","title":"Configure Python Remote Interpreter"},{"location":"development/developing_fides/#rundebug-configuration","text":"Set up a Run/Debug Configuration so that breakpoints can be hit in the f sourcecode. Go to: Run/Debug Configurations -> + -> Python To debug Fides, debug the <path on your machine>/src/fides/main.py script Make sure to select Use specified interpreter set the Remote Python Docker Compose (created in the previous section) Add FIDES__CONFIG_PATH=/fides to Environment variables See screenshot below:","title":"Run/Debug Configuration"},{"location":"development/developing_fides/#hit-a-breakpoint","text":"Now the IDE is ready to debug the source code. Click the debug button for main (setup in the previous section) . Try firing a http request to Fides from Postman or Curl and hit a break point. There is a postman collection in this repo: docs/fides/docs/development/postman/Fides.postman_collection.json Screenshot of hit breakpoint below:","title":"Hit a Breakpoint"},{"location":"development/developing_fides/#links_1","text":"The information is this guide is largely based on these docs https://www.jetbrains.com/help/pycharm/using-docker-as-a-remote-interpreter.html https://www.jetbrains.com/help/idea/configuring-local-python-interpreters.html","title":"Links"},{"location":"development/development_tips/","text":"Development Tips This page is dedicated to providing further context and information around specific implementation details such as code organization, running migrations and more. If you're looking for a general getting started guide, please see the Overview and Development Guide . API Endpoints API URLs We define API URLs for specific API versions as constants within fides.common.api.v1.urn_registry (where v1 can be substituted for that particular API version), then import those URLs into their specific API views. Since we are on the first version, there is no clear precedent set for overriding URLs between versions yet. The most likely change is that we'll override the APIRouter class instantiation with a different base path (ie. /api/v2 instead of /api/v1 ). For example: 1 2 PRIVACY_REQUEST = \"/privacy-request\" PRIVACY_REQUEST_DETAIL = \"/privacy-request/{privacy_request_id}\" would both resolve as /api/v1/privacy-request and /api/v1/privacy-request/{privacy_request_id} respectively. Database and Models The ORM -- SQLAlchemy SQLAlchemy is an Object Relational Mapper, allowing us to avoid writing direct database queries within our codebase, and access the database via Python code instead. The ORM provides an additional configuration layer allowing user-defined Python classes to be mapped to database tables and other constructs, as well as an object persistence mechanism known as the Session . Some common uses cases are listed below, for a more comprehensive guide see: https://docs.sqlalchemy.org/en/14/tutorial/index.html Adding models Database tables are defined with model classes. Model files should live in src/fides/api/models/ . Individual model classes must inherit from our custom base class at fides.api.db.base_class.Base to ensure uniformity within the database. Multiple models per file are encouraged so long as they fit the same logical delineation within the project. An example model declaration is added below. For a comprehensive guide see: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping You should also import your model in src/fides/api/db/base.py so it is visible for alembic. 1 2 3 4 5 6 7 class Book ( Base ): __tablename__ = 'book' id = Column ( Integer , primary_key = True ) name = Column ( String , index = True ) page_count = Column ( Integer , nullable = True ) author_id = Column ( Integer , ForeignKey ( \"author.id\" ), nullable = False ) When models are added to the project, we must then add them to the database in a recordable and repeatable fashion using migrations. Using the database via models Once you've added database tables via project models, you're ready to read, write, and update them via Python code. Some examples of common use cases here are listed below. Official documentation is here: https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query . Import our application's database session: from fides.api.db.session import get_db_session Instantiate the database interaction object: 1 2 SessionLocal = get_db_session ( config ) db = SessionLocal () Create a new row in a table: 1 2 3 4 5 6 7 8 9 db_obj = User ( email = \"admin@fides.app\" , full_name = \"Fides Admin\" , is_superuser = True , is_active = True , ) db . add ( db_obj ) db . commit () db . refresh ( db_obj ) Fetch all objects in a table: users = db.query(User).all() Fetch all objects in a table that meet some criteria: active_users = db.query(User).filter(User.is_active == True) Get a specific row in a table: user = db.query(User).get(User.email == \"admin@fides.app\") Update a specific row in a table: 1 2 3 4 user . email = \"updated@fides.app\" db . add ( user ) db . commit () db . refresh () Connecting to the database When you run nox -s dev , the database will spin up in a Docker container with port 5432 exposed on localhost. You can connect to it using the credentials found in .fides.toml , e.g. Hostname: localhost Port: 5432 Username: see database.user in .fides.toml Password: see database.password in .fides.toml Alembic migrations Some common Alembic commands are listed below. For a comprehensive guide see: https://alembic.sqlalchemy.org/en/latest/tutorial.html . The commands will need to be run inside a shell on your Docker containers, which can be opened with nox -s dev -- shell . In the /src/fides/api/alembic directory: Migrate your database to the latest state: alembic upgrade head Merge heads (for when you have conflicting heads from a merge/rebase): alembic merge heads Get revision id of previous migration: alembic current Automatically generate a new migration: alembic revision --autogenerate -m \"<a message describing your changes>\" Create a new migration file to manually fill out: alembic revision -m \"<a message describing your changes>\" Migrate your database to a specific state alembic upgrade <revision-id> or alembic downgrade <revision-id> , (or if you want to be smart alembic upgrade <revision-id> || alembic downgrade <revision-id> is handy when you don't know whether the target revision is an upgrade or downgrade) NB. You can find the revision-id inside each migration file in alembic/versions/ on line 3 next to Revision ID: ... When working on a PR with a migration, ensure that down_revision in the generated migration file correctly references the previous migration before submitting/merging the PR. Exception Handling Our preference for exception handling is by overriding the nearest sensible error, for example: 1 2 3 4 5 6 class SomeException ( ValueError ): \"a docstring\" def some_method (): raise SomeException ( \"a message\" ) General debugging -- pdb The project uses pdb for debugging as a dev-requirement . You can set breakpoints with pdb in much the same way you'd set them using debugger in JavaScript. Insert import pdb; pdb.set_trace() into the line where you want the breakpoint to set, then run your Python code. Docker As a last resort you may need to tear everything down in Docker and rebuild. The following commands will achieve that, but be warned that rebuild times can be long! 1 nox -s clean Warning If you find yourself feeling the need to run this command regularly, open an issue or slack a member of the dev team as it is not expected that this will need to be run regularly. Performance and Benchmarking The following are a few options we have for monitoring and benchmarking application performance: docker stats - Running this command will show you the CPU and Memory usage of your containers. This is very handy for quickly checking the memory footprint of an image while running. drill - This is a CLI tool used for load-testing applications. It requires Rust and OpenSSL. This is used in CI to continually benchmark performance. nox -s performance_tests - This is a convenient combination of the prior two tools that is used in CI but also possible to use locally. profile-request - When in dev_mode , Adding profile-request: true to any request header will tell the server to profile the request and send back a text response containing the profile data, instead of returning the typical JSON response. This allows arbitrary profiling of any endpoint or feature.","title":"Development Tips"},{"location":"development/development_tips/#development-tips","text":"This page is dedicated to providing further context and information around specific implementation details such as code organization, running migrations and more. If you're looking for a general getting started guide, please see the Overview and Development Guide .","title":"Development Tips"},{"location":"development/development_tips/#api-endpoints","text":"","title":"API Endpoints"},{"location":"development/development_tips/#api-urls","text":"We define API URLs for specific API versions as constants within fides.common.api.v1.urn_registry (where v1 can be substituted for that particular API version), then import those URLs into their specific API views. Since we are on the first version, there is no clear precedent set for overriding URLs between versions yet. The most likely change is that we'll override the APIRouter class instantiation with a different base path (ie. /api/v2 instead of /api/v1 ). For example: 1 2 PRIVACY_REQUEST = \"/privacy-request\" PRIVACY_REQUEST_DETAIL = \"/privacy-request/{privacy_request_id}\" would both resolve as /api/v1/privacy-request and /api/v1/privacy-request/{privacy_request_id} respectively.","title":"API URLs"},{"location":"development/development_tips/#database-and-models","text":"","title":"Database and Models"},{"location":"development/development_tips/#the-orm-sqlalchemy","text":"SQLAlchemy is an Object Relational Mapper, allowing us to avoid writing direct database queries within our codebase, and access the database via Python code instead. The ORM provides an additional configuration layer allowing user-defined Python classes to be mapped to database tables and other constructs, as well as an object persistence mechanism known as the Session . Some common uses cases are listed below, for a more comprehensive guide see: https://docs.sqlalchemy.org/en/14/tutorial/index.html","title":"The ORM -- SQLAlchemy"},{"location":"development/development_tips/#adding-models","text":"Database tables are defined with model classes. Model files should live in src/fides/api/models/ . Individual model classes must inherit from our custom base class at fides.api.db.base_class.Base to ensure uniformity within the database. Multiple models per file are encouraged so long as they fit the same logical delineation within the project. An example model declaration is added below. For a comprehensive guide see: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping You should also import your model in src/fides/api/db/base.py so it is visible for alembic. 1 2 3 4 5 6 7 class Book ( Base ): __tablename__ = 'book' id = Column ( Integer , primary_key = True ) name = Column ( String , index = True ) page_count = Column ( Integer , nullable = True ) author_id = Column ( Integer , ForeignKey ( \"author.id\" ), nullable = False ) When models are added to the project, we must then add them to the database in a recordable and repeatable fashion using migrations.","title":"Adding models"},{"location":"development/development_tips/#using-the-database-via-models","text":"Once you've added database tables via project models, you're ready to read, write, and update them via Python code. Some examples of common use cases here are listed below. Official documentation is here: https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query . Import our application's database session: from fides.api.db.session import get_db_session Instantiate the database interaction object: 1 2 SessionLocal = get_db_session ( config ) db = SessionLocal () Create a new row in a table: 1 2 3 4 5 6 7 8 9 db_obj = User ( email = \"admin@fides.app\" , full_name = \"Fides Admin\" , is_superuser = True , is_active = True , ) db . add ( db_obj ) db . commit () db . refresh ( db_obj ) Fetch all objects in a table: users = db.query(User).all() Fetch all objects in a table that meet some criteria: active_users = db.query(User).filter(User.is_active == True) Get a specific row in a table: user = db.query(User).get(User.email == \"admin@fides.app\") Update a specific row in a table: 1 2 3 4 user . email = \"updated@fides.app\" db . add ( user ) db . commit () db . refresh ()","title":"Using the database via models"},{"location":"development/development_tips/#connecting-to-the-database","text":"When you run nox -s dev , the database will spin up in a Docker container with port 5432 exposed on localhost. You can connect to it using the credentials found in .fides.toml , e.g. Hostname: localhost Port: 5432 Username: see database.user in .fides.toml Password: see database.password in .fides.toml","title":"Connecting to the database"},{"location":"development/development_tips/#alembic-migrations","text":"Some common Alembic commands are listed below. For a comprehensive guide see: https://alembic.sqlalchemy.org/en/latest/tutorial.html . The commands will need to be run inside a shell on your Docker containers, which can be opened with nox -s dev -- shell . In the /src/fides/api/alembic directory: Migrate your database to the latest state: alembic upgrade head Merge heads (for when you have conflicting heads from a merge/rebase): alembic merge heads Get revision id of previous migration: alembic current Automatically generate a new migration: alembic revision --autogenerate -m \"<a message describing your changes>\" Create a new migration file to manually fill out: alembic revision -m \"<a message describing your changes>\" Migrate your database to a specific state alembic upgrade <revision-id> or alembic downgrade <revision-id> , (or if you want to be smart alembic upgrade <revision-id> || alembic downgrade <revision-id> is handy when you don't know whether the target revision is an upgrade or downgrade) NB. You can find the revision-id inside each migration file in alembic/versions/ on line 3 next to Revision ID: ... When working on a PR with a migration, ensure that down_revision in the generated migration file correctly references the previous migration before submitting/merging the PR.","title":"Alembic migrations"},{"location":"development/development_tips/#exception-handling","text":"Our preference for exception handling is by overriding the nearest sensible error, for example: 1 2 3 4 5 6 class SomeException ( ValueError ): \"a docstring\" def some_method (): raise SomeException ( \"a message\" )","title":"Exception Handling"},{"location":"development/development_tips/#general-debugging-pdb","text":"The project uses pdb for debugging as a dev-requirement . You can set breakpoints with pdb in much the same way you'd set them using debugger in JavaScript. Insert import pdb; pdb.set_trace() into the line where you want the breakpoint to set, then run your Python code.","title":"General debugging -- pdb"},{"location":"development/development_tips/#docker","text":"As a last resort you may need to tear everything down in Docker and rebuild. The following commands will achieve that, but be warned that rebuild times can be long! 1 nox -s clean Warning If you find yourself feeling the need to run this command regularly, open an issue or slack a member of the dev team as it is not expected that this will need to be run regularly.","title":"Docker"},{"location":"development/development_tips/#performance-and-benchmarking","text":"The following are a few options we have for monitoring and benchmarking application performance: docker stats - Running this command will show you the CPU and Memory usage of your containers. This is very handy for quickly checking the memory footprint of an image while running. drill - This is a CLI tool used for load-testing applications. It requires Rust and OpenSSL. This is used in CI to continually benchmark performance. nox -s performance_tests - This is a convenient combination of the prior two tools that is used in CI but also possible to use locally. profile-request - When in dev_mode , Adding profile-request: true to any request header will tell the server to profile the request and send back a text response containing the profile data, instead of returning the typical JSON response. This allows arbitrary profiling of any endpoint or feature.","title":"Performance and Benchmarking"},{"location":"development/documentation/","text":"Documentation Primary documentation for Fides now lives at https://docs.ethyca.com , however autogenerated documentation as well as developer documentation is still maintained and hosted within the Fides project repo . Previewing Docs Locally Documentation (including both developer documentation as well as API references) are built and deployed with every merge to Fides' main branch. nox -s docs_serve You'll see a status update as the docs build, and then an announcement that they are available at localhost:8080/fides . The docs will hot-reload as changes are made, so there is no need to rerun the command whenever a change is made.","title":"Documentation"},{"location":"development/documentation/#documentation","text":"Primary documentation for Fides now lives at https://docs.ethyca.com , however autogenerated documentation as well as developer documentation is still maintained and hosted within the Fides project repo .","title":"Documentation"},{"location":"development/documentation/#previewing-docs-locally","text":"Documentation (including both developer documentation as well as API references) are built and deployed with every merge to Fides' main branch. nox -s docs_serve You'll see a status update as the docs build, and then an announcement that they are available at localhost:8080/fides . The docs will hot-reload as changes are made, so there is no need to rerun the command whenever a change is made.","title":"Previewing Docs Locally"},{"location":"development/fideslog/","text":"Analytics Fides includes an implementation of fideslog to provide Ethyca with an understanding of user interactions with fides tooling. All collected analytics are anonymized, and only used in either product roadmap determination, or as insight into product adoption. Information collected by fideslog is received via HTTPs request, stored in a secure database, and never shared with third parties unless required by law. More information on use, implementation, and configuration can be found in the fideslog repository . Collected Data Fideslog collects information on instances of Fides by recording internal events. Using Fides may result in sending any or all of the following analytics data to Ethyca: Parameter Description docker If fides is run in a docker container. event The type of analytics event - currently, either a server start or endpoint call . event_created The time of the event. endpoint The endpoint accessed. status_code The status result of the request. error Error information, if any. Disabling Fideslog To opt out of analytics, set either the following fides environment variable or .toml configuration variable to True . Variable Default Use analytics_opt_out False Include in your fides.toml file. FIDES__USER__ANALYTICS_OPT_OUT False Include in your environment variables.","title":"User Analytics"},{"location":"development/fideslog/#analytics","text":"Fides includes an implementation of fideslog to provide Ethyca with an understanding of user interactions with fides tooling. All collected analytics are anonymized, and only used in either product roadmap determination, or as insight into product adoption. Information collected by fideslog is received via HTTPs request, stored in a secure database, and never shared with third parties unless required by law. More information on use, implementation, and configuration can be found in the fideslog repository .","title":"Analytics"},{"location":"development/fideslog/#collected-data","text":"Fideslog collects information on instances of Fides by recording internal events. Using Fides may result in sending any or all of the following analytics data to Ethyca: Parameter Description docker If fides is run in a docker container. event The type of analytics event - currently, either a server start or endpoint call . event_created The time of the event. endpoint The endpoint accessed. status_code The status result of the request. error Error information, if any.","title":"Collected Data"},{"location":"development/fideslog/#disabling-fideslog","text":"To opt out of analytics, set either the following fides environment variable or .toml configuration variable to True . Variable Default Use analytics_opt_out False Include in your fides.toml file. FIDES__USER__ANALYTICS_OPT_OUT False Include in your environment variables.","title":"Disabling Fideslog"},{"location":"development/overview/","text":"Development Overview Thank you for your interest in contributing to Fides! This section of our documentation is designed to help you become familiar with how we work, the standards we apply, and how to ensure your contribution is successful. If you're stuck, don't be shy about asking for help on GitHub . Getting Started The first step is to clone the Fides repo for development if you haven't already: 1 git clone https://github.com/ethyca/fides Once that's complete, there are a few different tools to install for get everything up and running. Requirements The primary requirements for contributing to Fides are Docker and Python . The download links as well as minimum required versions are provided below NOTE: Installing these requirements via Brew or other package managers is highly discouraged. Please use the provided links for a more stable experience. Docker Desktop (version 20.10.11 or later) - Docker Desktop Download Page Python (version 3.9 through 3.10) - To simplify the installation experience and create a more stable Python installation that can be managed indepently, we recommend installing Python via Anaconda. The installer for Anaconda can be found here . Warning Mac Users : Apple's ARM silicon (M-series chips, i.e. M1, M2, M2 Max, etc.) have a few extra requirements to get Fides running Additional Requirements for Mac Users (ARM-based) Install FreeTDS and OpenSSL 1 brew install freetds openssl Add the following to your run commands (i.e. .zshrc ), updating any path/versions to match yours 1 2 export LDFLAGS = \"-L/opt/homebrew/Cellar/freetds/1.3.18/lib -L/opt/homebrew/Cellar/openssl@1.1/1.1.1u/lib\" export CFLAGS = \"-I/opt/homebrew/Cellar/freetds/1.3.18/include\" Optional Requirements for Mac Users (ARM-based) Explicitly set resource allocations in Docker Desktop CPUs: 4 Memory:8GB Disk Limit: 200GB Now that those are installed, the final step is to install the Python dev requirements for the Fides project. We recommend doing this in a virtual environment. 1 pip install -r dev-requirements.txt Write your code We have no doubt you can write amazing code! However, we want to help you ensure your code follows the style and patterns of Fides and has the highest chance possible to be accepted. Many projects describe code style and documentation as a suggestion; in Fides it's a CI-checked requirement. To learn how to develop new features or fix bugs, see the developing Fides page. To learn how to style your code, see the style guide . To learn how to document your code, see the docs guide . To learn how to test your code, see the tests guide . To learn what format your PR should follow, make sure to follow the pull request guidelines . Submit your code In order to submit code to Fides, please: Fork the Fides repository Create a new branch on your fork Open a Pull Request once your work is ready for review Once automated tests have passed, a maintainer will review your PR and provide feedback on any changes it requires to be approved. Once approved, your PR will be merged into Fides and included in a future release. Congratulations You're a Fides contributor - welcome to the team! \ud83c\udf89","title":"Overview"},{"location":"development/overview/#development-overview","text":"Thank you for your interest in contributing to Fides! This section of our documentation is designed to help you become familiar with how we work, the standards we apply, and how to ensure your contribution is successful. If you're stuck, don't be shy about asking for help on GitHub .","title":"Development Overview"},{"location":"development/overview/#getting-started","text":"The first step is to clone the Fides repo for development if you haven't already: 1 git clone https://github.com/ethyca/fides Once that's complete, there are a few different tools to install for get everything up and running.","title":"Getting Started"},{"location":"development/overview/#requirements","text":"The primary requirements for contributing to Fides are Docker and Python . The download links as well as minimum required versions are provided below NOTE: Installing these requirements via Brew or other package managers is highly discouraged. Please use the provided links for a more stable experience. Docker Desktop (version 20.10.11 or later) - Docker Desktop Download Page Python (version 3.9 through 3.10) - To simplify the installation experience and create a more stable Python installation that can be managed indepently, we recommend installing Python via Anaconda. The installer for Anaconda can be found here . Warning Mac Users : Apple's ARM silicon (M-series chips, i.e. M1, M2, M2 Max, etc.) have a few extra requirements to get Fides running","title":"Requirements"},{"location":"development/overview/#additional-requirements-for-mac-users-arm-based","text":"Install FreeTDS and OpenSSL 1 brew install freetds openssl Add the following to your run commands (i.e. .zshrc ), updating any path/versions to match yours 1 2 export LDFLAGS = \"-L/opt/homebrew/Cellar/freetds/1.3.18/lib -L/opt/homebrew/Cellar/openssl@1.1/1.1.1u/lib\" export CFLAGS = \"-I/opt/homebrew/Cellar/freetds/1.3.18/include\"","title":"Additional Requirements for Mac Users (ARM-based)"},{"location":"development/overview/#optional-requirements-for-mac-users-arm-based","text":"Explicitly set resource allocations in Docker Desktop CPUs: 4 Memory:8GB Disk Limit: 200GB Now that those are installed, the final step is to install the Python dev requirements for the Fides project. We recommend doing this in a virtual environment. 1 pip install -r dev-requirements.txt","title":"Optional Requirements for Mac Users (ARM-based)"},{"location":"development/overview/#write-your-code","text":"We have no doubt you can write amazing code! However, we want to help you ensure your code follows the style and patterns of Fides and has the highest chance possible to be accepted. Many projects describe code style and documentation as a suggestion; in Fides it's a CI-checked requirement. To learn how to develop new features or fix bugs, see the developing Fides page. To learn how to style your code, see the style guide . To learn how to document your code, see the docs guide . To learn how to test your code, see the tests guide . To learn what format your PR should follow, make sure to follow the pull request guidelines .","title":"Write your code"},{"location":"development/overview/#submit-your-code","text":"In order to submit code to Fides, please: Fork the Fides repository Create a new branch on your fork Open a Pull Request once your work is ready for review Once automated tests have passed, a maintainer will review your PR and provide feedback on any changes it requires to be approved. Once approved, your PR will be merged into Fides and included in a future release.","title":"Submit your code"},{"location":"development/overview/#congratulations","text":"You're a Fides contributor - welcome to the team! \ud83c\udf89","title":"Congratulations"},{"location":"development/pull_requests/","text":"Pull Requests Pull requests are the primary unit of work within the Fides project. All code changes are expected to be submitted via a PR with the following requirements: Completely fill out the provided pull request template. PRs should be in a draft state until they are ready for a final review + merge. A non-draft PR signals to the community that the author believes the PR is ready to ship! If you need early feedback on your PR, feel free to ask for it directly while your PR is in a draft state. Make sure that all checks are passing, and all boxes have been checked before taking the PR out of a draft state. PR reviews require other people to spend their time, so please be courteous and double check your work before passing it to a reviewer. If you're unsure about a potential feature implementation or there is anything else that needs discussing, feel free to ask for an early review/feedback in the comments of the draft PR. PRs should be focused, reflecting a single logical change or feature. Generally, it is better to have multiple smaller PRs than one big one. This reduces the merge risk and shortens review time.","title":"Pull Requests"},{"location":"development/pull_requests/#pull-requests","text":"Pull requests are the primary unit of work within the Fides project. All code changes are expected to be submitted via a PR with the following requirements: Completely fill out the provided pull request template. PRs should be in a draft state until they are ready for a final review + merge. A non-draft PR signals to the community that the author believes the PR is ready to ship! If you need early feedback on your PR, feel free to ask for it directly while your PR is in a draft state. Make sure that all checks are passing, and all boxes have been checked before taking the PR out of a draft state. PR reviews require other people to spend their time, so please be courteous and double check your work before passing it to a reviewer. If you're unsure about a potential feature implementation or there is anything else that needs discussing, feel free to ask for an early review/feedback in the comments of the draft PR. PRs should be focused, reflecting a single logical change or feature. Generally, it is better to have multiple smaller PRs than one big one. This reduces the merge risk and shortens review time.","title":"Pull Requests"},{"location":"development/releases/","text":"Releases Versioning Fides uses semantic versioning. Due to the rapid development of the project, some minor versions may also contain minor breaking changes. The best practice is to always pin versions, and carefully test before bumping to a new version. Patch versions will never cause breaking changes, and are only used to hotfix critical bugs. Release schedule Fides does not follow a set release schedule, and instead ships versions based on the addition of features and functionality. Each release, with the exception of hotfixes, contains at least one substantial new feature. Branching Fides uses continuous delivery with a single main branch. All code changes are merged into this branch. When it comes times to prepare for a new release, a release branch is created for stability and thoroughly tested. When releasing, a new tag is created on the release branch and the release process proceeds automatically. In the case of patches, a branch is created from the relevant tag. Commits are then cherry-picked into this branch, and a new patch version tag is created. Release Steps We use GitHub\u2019s release feature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use a CHANGELOG.md to mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows: Major and Minor Open a PR that is titled the version of the release (i.e. 1.6.0 ) Rename the Unreleased section of CHANGELOG.md to the new version number and put a date next to it Update the compare links for both the new version and for the new Unreleased section Once approved, merge the PR Create a new release, ensuring that the last PR to get merged is the aforementioned CHANGELOG.md update PR Add the new version as the tag (i.e. 1.6.0 ) Make the title the version with a v in front of it (i.e. v1.6.0 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Patch It may be necessary for a patch release to contain only select commits to the main branch since the last major or minor release. To create a release with only the desired changes, follow the steps below: Checkout the most recent release's tag To fetch the most recent tag's name, run: 1 2 3 4 # fides on main git describe --abbrev = 0 --tags #=> 1.2.3 To checkout the most recent tag, run: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #fides on main git checkout 1 .2.3 #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Tip This can be combined into a single command: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # fides on main git checkout $( git describe --abbrev = 0 --tags ) #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Create a new branch from the HEAD commit of the most recent release's tag, called release-v<tag> 1 2 3 4 # fides on tags/1.2.3 git checkout -b release-v1.2.4 #=> Switched to a new branch 'release-v1.2.4' If the changes to be included in the patch release are contained in one or more unmerged pull requests, change the base branch of the pull request(s) to the release branch created in the previous step Once approved, merge the pull request(s) into the release branch Create a new branch off of the release branch by running: 1 2 3 4 # fides on release-v1.2.4 git checkout -b prepare-release-v1.2.4 #=> Switched to a new branch 'prepare-release-v1.2.4' Optional: Incorporate any additional specific changes required for the patch release by running: 1 2 # fides on prepare-release-v1.2.4 git cherry-pick <commit>... Copy the Unreleased section of CHANGELOG.md and paste above the release being patched Rename Unreleased to the new version number and put a date next to it Cut and paste the documented changes that are now included in the patch release to the correct section Commit these changes Open a pull request to incorporate any cherry-picked commits and the CHANGELOG.md changes into the release branch Set the base branch of this pull request to the release branch Once approved, merge the pull request into the release branch Create a new release from the release branch Add the new version as the tag (i.e. 1.2.4 ) Title the release with the version number, prefixed with a v (i.e. v1.2.4 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Merge the new release tag into main Warning Pushing commits (including merge commits) to the main branch requires admin-level repository permissions. Checkout the main branch, and update the local repository: 1 2 3 4 git checkout main #=> Switched to branch 'main'... git pull Merge the new release tag into main : 1 git merge tags/1.2.4 Handle any merge conflicts, and push to the remote main branch Release Checklist The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check. This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step. Additionally, there is a robust Release Process page available in Confluence ( internal only ). Pre-Release Steps General From the release branch, confirm the following: [ ] Quickstart works: nox -s quickstart (verify you can complete the interactive prompts from the command-line) [ ] Test environment works: nox -s \"fides_env(test)\" (verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver) [ ] Have Roger run a QATouch automation run Next, run the following checks via the test environment: API [ ] Verify that the generated API docs are correct @ http://localhost:8080/docs CLI Run these from within the test environment shell: [ ] git reset --hard - Note: This is required for the pull command to work [ ] fides user login [ ] fides push src/fides/data/sample_project/sample_resources/ [ ] fides pull src/fides/data/sample_project/sample_resources/ [ ] fides evaluate src/fides/data/sample_project/sample_resources/ [ ] fides generate dataset db --credentials-id app_postgres test.yml - Note: Because the filesystem isn't mounted, the new file will only show up within the container [ ] fides scan dataset db --credentials-id app_postgres Privacy Center [ ] Every navigation button works [ ] DSR submission succeeds [ ] Consent request submission succeeds Admin UI [ ] Every navigation button works [ ] DSR approval succeeds [ ] DSR execution succeeds User Permissions [ ] Verify user creation [ ] Verify a Viewer can view all systems [ ] Verify a Data Steward can edit systems they are assigned Documentation [ ] Verify that the CHANGELOG is formatted correctly and clean up verbiage where needed [ ] Verify that the CHANGELOG is representative of the actual changes :warning: Note that any updates that need to be made to the CHANGELOG should not be commited directly to the release branch. Instead, they should be committed on a branch off of main and then PR'd and merged into main , before being cherry-picked over to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and main . Publishing the release When publishing the release, be sure to include the following sections in the release description: [ ] ## Release Pull Request section that includes a link back to the release PR (i.e., this one!) for tracking purposes [ ] ## QA Touch Test Run section that includes a link to the QATouch test run (QA team should provide this) Post-Release Steps [ ] Verify the ethyca-fides release is published to PyPi: https://pypi.org/project/ethyca-fides/#history [ ] Verify the fides release is published to DockerHub: https://hub.docker.com/r/ethyca/fides [ ] Verify the fides-privacy-center release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-privacy-center [ ] Verify the fides-sample-app release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-sample-app [ ] Smoke test the PyPi & DockerHub releases: [ ] Create a fresh venv with python3 -m venv 2_12_0_venv [ ] Activate the venv source 2_12_0_venv/bin/activate [ ] pip install ethyca-fides [ ] fides deploy up [ ] Announce the release!","title":"Releases"},{"location":"development/releases/#releases","text":"","title":"Releases"},{"location":"development/releases/#versioning","text":"Fides uses semantic versioning. Due to the rapid development of the project, some minor versions may also contain minor breaking changes. The best practice is to always pin versions, and carefully test before bumping to a new version. Patch versions will never cause breaking changes, and are only used to hotfix critical bugs.","title":"Versioning"},{"location":"development/releases/#release-schedule","text":"Fides does not follow a set release schedule, and instead ships versions based on the addition of features and functionality. Each release, with the exception of hotfixes, contains at least one substantial new feature.","title":"Release schedule"},{"location":"development/releases/#branching","text":"Fides uses continuous delivery with a single main branch. All code changes are merged into this branch. When it comes times to prepare for a new release, a release branch is created for stability and thoroughly tested. When releasing, a new tag is created on the release branch and the release process proceeds automatically. In the case of patches, a branch is created from the relevant tag. Commits are then cherry-picked into this branch, and a new patch version tag is created.","title":"Branching"},{"location":"development/releases/#release-steps","text":"We use GitHub\u2019s release feature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use a CHANGELOG.md to mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows:","title":"Release Steps"},{"location":"development/releases/#major-and-minor","text":"Open a PR that is titled the version of the release (i.e. 1.6.0 ) Rename the Unreleased section of CHANGELOG.md to the new version number and put a date next to it Update the compare links for both the new version and for the new Unreleased section Once approved, merge the PR Create a new release, ensuring that the last PR to get merged is the aforementioned CHANGELOG.md update PR Add the new version as the tag (i.e. 1.6.0 ) Make the title the version with a v in front of it (i.e. v1.6.0 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release","title":"Major and Minor"},{"location":"development/releases/#patch","text":"It may be necessary for a patch release to contain only select commits to the main branch since the last major or minor release. To create a release with only the desired changes, follow the steps below: Checkout the most recent release's tag To fetch the most recent tag's name, run: 1 2 3 4 # fides on main git describe --abbrev = 0 --tags #=> 1.2.3 To checkout the most recent tag, run: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #fides on main git checkout 1 .2.3 #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Tip This can be combined into a single command: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # fides on main git checkout $( git describe --abbrev = 0 --tags ) #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Create a new branch from the HEAD commit of the most recent release's tag, called release-v<tag> 1 2 3 4 # fides on tags/1.2.3 git checkout -b release-v1.2.4 #=> Switched to a new branch 'release-v1.2.4' If the changes to be included in the patch release are contained in one or more unmerged pull requests, change the base branch of the pull request(s) to the release branch created in the previous step Once approved, merge the pull request(s) into the release branch Create a new branch off of the release branch by running: 1 2 3 4 # fides on release-v1.2.4 git checkout -b prepare-release-v1.2.4 #=> Switched to a new branch 'prepare-release-v1.2.4' Optional: Incorporate any additional specific changes required for the patch release by running: 1 2 # fides on prepare-release-v1.2.4 git cherry-pick <commit>... Copy the Unreleased section of CHANGELOG.md and paste above the release being patched Rename Unreleased to the new version number and put a date next to it Cut and paste the documented changes that are now included in the patch release to the correct section Commit these changes Open a pull request to incorporate any cherry-picked commits and the CHANGELOG.md changes into the release branch Set the base branch of this pull request to the release branch Once approved, merge the pull request into the release branch Create a new release from the release branch Add the new version as the tag (i.e. 1.2.4 ) Title the release with the version number, prefixed with a v (i.e. v1.2.4 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Merge the new release tag into main Warning Pushing commits (including merge commits) to the main branch requires admin-level repository permissions. Checkout the main branch, and update the local repository: 1 2 3 4 git checkout main #=> Switched to branch 'main'... git pull Merge the new release tag into main : 1 git merge tags/1.2.4 Handle any merge conflicts, and push to the remote main branch","title":"Patch"},{"location":"development/releases/#release-checklist","text":"The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check. This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step. Additionally, there is a robust Release Process page available in Confluence ( internal only ).","title":"Release Checklist"},{"location":"development/releases/#pre-release-steps","text":"","title":"Pre-Release Steps"},{"location":"development/releases/#general","text":"From the release branch, confirm the following: [ ] Quickstart works: nox -s quickstart (verify you can complete the interactive prompts from the command-line) [ ] Test environment works: nox -s \"fides_env(test)\" (verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver) [ ] Have Roger run a QATouch automation run Next, run the following checks via the test environment:","title":"General"},{"location":"development/releases/#api","text":"[ ] Verify that the generated API docs are correct @ http://localhost:8080/docs","title":"API"},{"location":"development/releases/#cli","text":"Run these from within the test environment shell: [ ] git reset --hard - Note: This is required for the pull command to work [ ] fides user login [ ] fides push src/fides/data/sample_project/sample_resources/ [ ] fides pull src/fides/data/sample_project/sample_resources/ [ ] fides evaluate src/fides/data/sample_project/sample_resources/ [ ] fides generate dataset db --credentials-id app_postgres test.yml - Note: Because the filesystem isn't mounted, the new file will only show up within the container [ ] fides scan dataset db --credentials-id app_postgres","title":"CLI"},{"location":"development/releases/#privacy-center","text":"[ ] Every navigation button works [ ] DSR submission succeeds [ ] Consent request submission succeeds","title":"Privacy Center"},{"location":"development/releases/#admin-ui","text":"[ ] Every navigation button works [ ] DSR approval succeeds [ ] DSR execution succeeds","title":"Admin UI"},{"location":"development/releases/#user-permissions","text":"[ ] Verify user creation [ ] Verify a Viewer can view all systems [ ] Verify a Data Steward can edit systems they are assigned","title":"User Permissions"},{"location":"development/releases/#documentation","text":"[ ] Verify that the CHANGELOG is formatted correctly and clean up verbiage where needed [ ] Verify that the CHANGELOG is representative of the actual changes :warning: Note that any updates that need to be made to the CHANGELOG should not be commited directly to the release branch. Instead, they should be committed on a branch off of main and then PR'd and merged into main , before being cherry-picked over to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and main .","title":"Documentation"},{"location":"development/releases/#publishing-the-release","text":"When publishing the release, be sure to include the following sections in the release description: [ ] ## Release Pull Request section that includes a link back to the release PR (i.e., this one!) for tracking purposes [ ] ## QA Touch Test Run section that includes a link to the QATouch test run (QA team should provide this)","title":"Publishing the release"},{"location":"development/releases/#post-release-steps","text":"[ ] Verify the ethyca-fides release is published to PyPi: https://pypi.org/project/ethyca-fides/#history [ ] Verify the fides release is published to DockerHub: https://hub.docker.com/r/ethyca/fides [ ] Verify the fides-privacy-center release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-privacy-center [ ] Verify the fides-sample-app release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-sample-app [ ] Smoke test the PyPi & DockerHub releases: [ ] Create a fresh venv with python3 -m venv 2_12_0_venv [ ] Activate the venv source 2_12_0_venv/bin/activate [ ] pip install ethyca-fides [ ] fides deploy up [ ] Announce the release!","title":"Post-Release Steps"},{"location":"development/testing/","text":"Testing Fides loves tests! There are a few important reasons to write tests: Make sure your code works Tests ensure that your code does the thing you intend it to do. If you have a function that adds two numbers, you'll want to test that it does, in fact, return their sum. If behavior depends on a configuration setting, ensure that changing that setting changes the behavior. In short, if you wrote a line of code, you should test that line works as expected. Make sure your code doesn't not work It may seem silly, but another important reason to write tests is to ensure that your code behaves as expected even when it's broken . This is especially important for a project like Fides, which is focused on helping engineers when something unexpected happens to their code. For example, you could write tests about what you expect to happen if your function is called with incorrect (or no) arguments, or to ensure that any errors are properly trapped and handled. Tests are documentation Ultimately, your tests are the best documentation for your code. Another developer should be able to look at your tests and understand what your code does, how to invoke it, and what edge cases it contains. Therefore, try to write short, self-explanatory tests with descriptive titles. Help future developers As Fides grows, your code will be reused in more and more places, by developers who may not be familiar with the details of your implementation. Therefore, your tests are an opportunity to ensure that your code is used correctly in the future. For example, if your code needs to be used in a certain way, or expects a certain configuration, or is always expected to return a certain output, or has any other details that might impact its ability to be used in the framework, write a test for it! At minimum, you'll help a future developer understand that you consciously chose to design your code a certain way. Writing tests Fides' tests are stored in the tests directory. Tests should have descriptive names that make it clear what you're testing. If necessary, add a docstring or comment to explain why you're testing this specific thing. 1 2 3 4 5 6 7 # Good test name def test_dry_evaluate_system_fail ( server_url , resources_dict ): ... # Bad test name def test_dry_evaluate (): ... Fides has a few pytest fixtures available for testing; see conftest.py for details. Integration tests vs. mocked tests Generally, tests that include mocking are discouraged. Mocking can create a false sense of security and obfuscate possible errors in the code that only present themselves when integration tested. Running tests Given the relative complexity of the setup around Fides and reliance on Docker, test commands should usually be run in a shell or via Nox sessions. The following subsections describe how to execute both. Running Tests in a Shell As described in Developing Fides , we'll be running these tests from within a shell. As a reminder, spinning up Fides and opening a shell requires the following commands: nox -s dev Once the webserver is running from the previous command, open a new terminal and run nox -s shell You're now ready to start testing! Invoking Pytest Fides uses pytest for unit testing. Let's collect all of the available tests to verify pytest is working as expected: 1 2 # Collects all available tests without running anything pytest --collect-only Running specific tests To run a subset of tests, provide a filename or directory; to match a specific test name, use the -k flag: 1 2 # Run all tests in the tests/ctl/ directory that contain the word \"api\" in their name pytest tests/ctl/ -k api The --sw flag will exit pytest the first time it encounters an error; subsequent runs with the same flag will skip any tests that succeeded and run the failed test first. For more information on available Pytest invocation options, see the documentation here . Excluding tests Some tests also test integration with external services like Snowflake which require both internet access and authentication credentials. It is possible to skip these tests by excluding tests with the external mark. 1 2 # Run all tests except for external ones pytest -m \"not external\" This is far from the only mark used in the test suite however. To see a full list, they are all documented in the [tool.pytest] section of the pyproject.toml . Running Test Suites via Nox To run tests in a more robust and repeatable way, Nox also has extensive commands for running tests packaged with various marks and infrastructure. However, it is important to note that these commands are not designed for rapid iteration and TDD in mind, but instead for maximum reproducability. To run tests in a more TDD-style, see the section Running Tests in a Shell . Additionally, these are the exact same Nox sessions that are run in CI. Thus if you are seeing CI failures and are trying to reproduce or remediate them, it is recommended to run those failing tests locally via these Nox sessions as the results will generally always be the same. Building the Test Image The Nox test sessions assume that all of the required images have already been built. To build the Fides image used for testing, run the following command: 1 nox -s \"build(test)\" Once that is complete, you're ready to start running test sessions. Test Sessions The following table describes each pytest-related session: Session (with Param) Mark(s) Test Path Requires Credentials? Description pytest(ctl-unit) unit tests/ctl No Simplest set of ctl tests Should generally avoid the webserver but not guaranteed. pytest(ctl-integration) integration tests/ctl No Tests that are known to require the webserver. pytest(ctl-not-external) not external tests/ctl No Tests unit/integration but without touching external resources. pytest(ctl-external) external tests/ctl Yes Tests that require external resources such as Snowflake or BigQuery. pytest(ops-unit) not integration and not integration_external and not integration_saas tests/ops No As there is no \"unit\" tag within the ops tests, it is instead achieved via numerous \"not\" marks. pytest(ops-integration) N/A N/A No This is a special test case, as the handling of test running is done by run_infrastructure.py . More information and logic can be found there. pytest(ops-external-datastores) integration_external tests/ops Yes Runs tests that connect to external datastores such as Snowflake. pytest(ops-saas) integration_saas tests/ops Yes Runs tests related to the connectors code. Spins up additional local resources and connects to outside resources. pytest(lib) N/A tests/lib No Test lib module functionality. pytest(nox) N/A tests/nox No Tests functionality related to the nox session. Note For additional information, you can view the source file test_setup_nox.py that contains all of the code that runs these tests. Testing Environment Quickstart Use nox -s \"fides_env(test)\" to launch the test environment Read the terminal output for details Customize Fides ENV variables by editing .env Overview To facilitate thorough manual testing of the application, there is a comprehensive testing environment that can be set up via a single nox command: nox -s \"fides_env(test)\" . This test environment includes: Fides Server Fides Admin UI Fides Postgres Database & Redis Cache Sample \"Cookie House\" Application Test Postgres Database Test Redis Database Sample Resources Sample Connectors etc. This test environment is exactly the same environment that users can launch themselves using fides deploy up , and you can find all the configuration and settings in src/fides/data/sample_project . Configuration There are two ways to configure the fides server and CLI: Editing the ENV file in the project root: .env Editing the TOML file in the sample project files: src/fides/data/sample_project/fides.toml The .env file is safest to add secrets and local customizations, since it is .gitignore 'd and will not be accidentally committed to version control. The fides.toml file should be used for configurations that should be present for all users testing out the application. Advanced Usage The environment will work \"out of the box\", but can also be configured to enable other features like S3 storage, email notifications, etc. To configure these, you'll need to edit the .env file and provide some secrets - see example.env for what is supported. Automated Cypress E2E Tests The test environment is also used to run automated end-to-end (E2E) tests via Cypress. Use nox -s e2e_test to run this locally.","title":"Testing"},{"location":"development/testing/#testing","text":"Fides loves tests! There are a few important reasons to write tests: Make sure your code works Tests ensure that your code does the thing you intend it to do. If you have a function that adds two numbers, you'll want to test that it does, in fact, return their sum. If behavior depends on a configuration setting, ensure that changing that setting changes the behavior. In short, if you wrote a line of code, you should test that line works as expected. Make sure your code doesn't not work It may seem silly, but another important reason to write tests is to ensure that your code behaves as expected even when it's broken . This is especially important for a project like Fides, which is focused on helping engineers when something unexpected happens to their code. For example, you could write tests about what you expect to happen if your function is called with incorrect (or no) arguments, or to ensure that any errors are properly trapped and handled. Tests are documentation Ultimately, your tests are the best documentation for your code. Another developer should be able to look at your tests and understand what your code does, how to invoke it, and what edge cases it contains. Therefore, try to write short, self-explanatory tests with descriptive titles. Help future developers As Fides grows, your code will be reused in more and more places, by developers who may not be familiar with the details of your implementation. Therefore, your tests are an opportunity to ensure that your code is used correctly in the future. For example, if your code needs to be used in a certain way, or expects a certain configuration, or is always expected to return a certain output, or has any other details that might impact its ability to be used in the framework, write a test for it! At minimum, you'll help a future developer understand that you consciously chose to design your code a certain way.","title":"Testing"},{"location":"development/testing/#writing-tests","text":"Fides' tests are stored in the tests directory. Tests should have descriptive names that make it clear what you're testing. If necessary, add a docstring or comment to explain why you're testing this specific thing. 1 2 3 4 5 6 7 # Good test name def test_dry_evaluate_system_fail ( server_url , resources_dict ): ... # Bad test name def test_dry_evaluate (): ... Fides has a few pytest fixtures available for testing; see conftest.py for details.","title":"Writing tests"},{"location":"development/testing/#integration-tests-vs-mocked-tests","text":"Generally, tests that include mocking are discouraged. Mocking can create a false sense of security and obfuscate possible errors in the code that only present themselves when integration tested.","title":"Integration tests vs. mocked tests"},{"location":"development/testing/#running-tests","text":"Given the relative complexity of the setup around Fides and reliance on Docker, test commands should usually be run in a shell or via Nox sessions. The following subsections describe how to execute both.","title":"Running tests"},{"location":"development/testing/#running-tests-in-a-shell","text":"As described in Developing Fides , we'll be running these tests from within a shell. As a reminder, spinning up Fides and opening a shell requires the following commands: nox -s dev Once the webserver is running from the previous command, open a new terminal and run nox -s shell You're now ready to start testing!","title":"Running Tests in a Shell"},{"location":"development/testing/#invoking-pytest","text":"Fides uses pytest for unit testing. Let's collect all of the available tests to verify pytest is working as expected: 1 2 # Collects all available tests without running anything pytest --collect-only","title":"Invoking Pytest"},{"location":"development/testing/#running-specific-tests","text":"To run a subset of tests, provide a filename or directory; to match a specific test name, use the -k flag: 1 2 # Run all tests in the tests/ctl/ directory that contain the word \"api\" in their name pytest tests/ctl/ -k api The --sw flag will exit pytest the first time it encounters an error; subsequent runs with the same flag will skip any tests that succeeded and run the failed test first. For more information on available Pytest invocation options, see the documentation here .","title":"Running specific tests"},{"location":"development/testing/#excluding-tests","text":"Some tests also test integration with external services like Snowflake which require both internet access and authentication credentials. It is possible to skip these tests by excluding tests with the external mark. 1 2 # Run all tests except for external ones pytest -m \"not external\" This is far from the only mark used in the test suite however. To see a full list, they are all documented in the [tool.pytest] section of the pyproject.toml .","title":"Excluding tests"},{"location":"development/testing/#running-test-suites-via-nox","text":"To run tests in a more robust and repeatable way, Nox also has extensive commands for running tests packaged with various marks and infrastructure. However, it is important to note that these commands are not designed for rapid iteration and TDD in mind, but instead for maximum reproducability. To run tests in a more TDD-style, see the section Running Tests in a Shell . Additionally, these are the exact same Nox sessions that are run in CI. Thus if you are seeing CI failures and are trying to reproduce or remediate them, it is recommended to run those failing tests locally via these Nox sessions as the results will generally always be the same.","title":"Running Test Suites via Nox"},{"location":"development/testing/#building-the-test-image","text":"The Nox test sessions assume that all of the required images have already been built. To build the Fides image used for testing, run the following command: 1 nox -s \"build(test)\" Once that is complete, you're ready to start running test sessions.","title":"Building the Test Image"},{"location":"development/testing/#test-sessions","text":"The following table describes each pytest-related session: Session (with Param) Mark(s) Test Path Requires Credentials? Description pytest(ctl-unit) unit tests/ctl No Simplest set of ctl tests Should generally avoid the webserver but not guaranteed. pytest(ctl-integration) integration tests/ctl No Tests that are known to require the webserver. pytest(ctl-not-external) not external tests/ctl No Tests unit/integration but without touching external resources. pytest(ctl-external) external tests/ctl Yes Tests that require external resources such as Snowflake or BigQuery. pytest(ops-unit) not integration and not integration_external and not integration_saas tests/ops No As there is no \"unit\" tag within the ops tests, it is instead achieved via numerous \"not\" marks. pytest(ops-integration) N/A N/A No This is a special test case, as the handling of test running is done by run_infrastructure.py . More information and logic can be found there. pytest(ops-external-datastores) integration_external tests/ops Yes Runs tests that connect to external datastores such as Snowflake. pytest(ops-saas) integration_saas tests/ops Yes Runs tests related to the connectors code. Spins up additional local resources and connects to outside resources. pytest(lib) N/A tests/lib No Test lib module functionality. pytest(nox) N/A tests/nox No Tests functionality related to the nox session. Note For additional information, you can view the source file test_setup_nox.py that contains all of the code that runs these tests.","title":"Test Sessions"},{"location":"development/testing/#testing-environment","text":"","title":"Testing Environment"},{"location":"development/testing/#quickstart","text":"Use nox -s \"fides_env(test)\" to launch the test environment Read the terminal output for details Customize Fides ENV variables by editing .env","title":"Quickstart"},{"location":"development/testing/#overview","text":"To facilitate thorough manual testing of the application, there is a comprehensive testing environment that can be set up via a single nox command: nox -s \"fides_env(test)\" . This test environment includes: Fides Server Fides Admin UI Fides Postgres Database & Redis Cache Sample \"Cookie House\" Application Test Postgres Database Test Redis Database Sample Resources Sample Connectors etc. This test environment is exactly the same environment that users can launch themselves using fides deploy up , and you can find all the configuration and settings in src/fides/data/sample_project .","title":"Overview"},{"location":"development/testing/#configuration","text":"There are two ways to configure the fides server and CLI: Editing the ENV file in the project root: .env Editing the TOML file in the sample project files: src/fides/data/sample_project/fides.toml The .env file is safest to add secrets and local customizations, since it is .gitignore 'd and will not be accidentally committed to version control. The fides.toml file should be used for configurations that should be present for all users testing out the application.","title":"Configuration"},{"location":"development/testing/#advanced-usage","text":"The environment will work \"out of the box\", but can also be configured to enable other features like S3 storage, email notifications, etc. To configure these, you'll need to edit the .env file and provide some secrets - see example.env for what is supported.","title":"Advanced Usage"},{"location":"development/testing/#automated-cypress-e2e-tests","text":"The test environment is also used to run automated end-to-end (E2E) tests via Cypress. Use nox -s e2e_test to run this locally.","title":"Automated Cypress E2E Tests"},{"location":"development/update_erd_diagram/","text":"Updating database diagram If you make updates to the Fides application database, you should update the DB Architecture diagram in the documentation. Connect DBeaver to our app DB container DBeaver > Database > New Database Connection > PostgreSQL Add configuration details Right-click on postgres connection > Create > Other Select ER Diagram, Click Next Drill down to Postgres > app > Schemas > public and click the checkbox. Add a name to your ER Diagram Click Finish Drag and drop tables so they are less messy. File > Save As (app_database.png) Replace img/app_database.png with the new file","title":"Updating the Database Diagram"},{"location":"development/update_erd_diagram/#updating-database-diagram","text":"If you make updates to the Fides application database, you should update the DB Architecture diagram in the documentation. Connect DBeaver to our app DB container DBeaver > Database > New Database Connection > PostgreSQL Add configuration details Right-click on postgres connection > Create > Other Select ER Diagram, Click Next Drill down to Postgres > app > Schemas > public and click the checkbox. Add a name to your ER Diagram Click Finish Drag and drop tables so they are less messy. File > Save As (app_database.png) Replace img/app_database.png with the new file","title":"Updating database diagram"},{"location":"development/postman/using_postman/","text":"Using the Fides postman collection A minimal Postman collection is included to assist in setting up your privacy request configurations, and in executing example access and erasure requests against mock external databases. Loading the collection Get Postman Postman > File > Import Upload the Fides collection found in docs/fides/docs/postman/Fides.postman_collection.json Click on the imported fidesops collection in the left pane, and then find Variables to edit the fidesops collection variables. Some variables are populated for you, and some will be added in this guide's next steps. Add your oauth_root_client_id and oauth_root_client_secret under CURRENT VALUE . fidesadmin and fidesadminsecret are default configurations for testing, found in your fides.toml . Add the appropriate values for your instance if they differ. Important: Click Save ! Bring up local servers and mock databases Run nox -s dev -- <datastore> in your terminal. This brings up the Fides server and the list of datastores specified, i.e. nox -s dev -- postgres mongodb . These mock datastores are pre-populated with test data to represent your datastores. The following list of requests is kept in the Minimum API calls to create an Access Privacy Request folder. Some of the returned data will need to be saved as additional variables for use in other steps. Saving Authentication variables Click on the Get Root Client Token request, and click Send to send a POST request to Fides to create a root token. Copy the access_token returned in the response body, and paste it as the Current Value of root_client_token in Fides' variables. Important: Click Save ! Similarly, click on Create Client , and click Send to send a POST request to Fides to create a new client. Copy the client_id and client_secret and paste into Current Value slots in Fides variables and click \"Save\". Finally, click on the Get Client Token request, and click Send to send another POST request to Fides. This will create a token for the client made in the previous step. If you click on Body , you can see that the client_id and client_secret have been added as form data for you. Save the returned token under client_token in the Fides variables. The client_token will be automatically passed into the rest of your requests as the Bearer Token. Building out remaining privacy request configuration Run through the remaining requests in the Minimum API calls to create an Access Privacy Request folder. Because variables are automatically being populated for you, you should be able to click on each request, clicking Send for each one. Inspect the Body of each request to see what is sent to Fides: Specify where your data is going: SEND Create/Update Storage - Local Storage Config - Sets up a local folder for uploading your privacy request results (local testing only) Configure what data you care about, and what to do with it: SEND Create/Update Policies - Creates a Policy to handle Privacy Requests SEND Create/Update Access Rule - Defines an access Rule on the previous Policy, which specifies results will be uploaded to the configured local storage SEND Create/Update Rule Targets - Specify a RuleTarget that says to will return data that has been marked as having a user data category Create ConnectionConfigs, and add connection secrets for the postgres_example and mongodb_example mock databases: SEND Create/Update Connection Configs: Postgres SEND Create/Update Connection Configs: Mongo SEND Update Connection Secrets: Postgres SEND Update Connection Secrets: Mongo Add annotations of the Postgres and Mongo datastores: SEND Create/Update Postgres Dataset SEND Create/Update Dataset Mongo API calls to additional supported datastores (MsSQL, MySQL) are in separate folders within the collection. Run a privacy request You have now completed the basic configuration required to create an Access Request. SEND Create Access Privacy Requests If \"succeeded\", note the \"id\" that is returned. Succeeded means the privacy request has been created and is pending, not that its execution is complete. Check your local fides_uploads folder, configured earlier, to see access request results. This is run asynchronously, so it may take a few moments to complete. This particular request should have retrieved data from both the postgres_example and mongodb_example databases with the user data_category Next steps Check out other requests in the collection! The Calls to create an Erasure Request folder walks you through configuring a separate erasure policy, and executing an erasure request. Note that these erasure requests will mask data in your connected datastores ( postgres_example and mongo_example here. If you connect your own live databases, data may be deleted. Happy experimenting!","title":"Using Postman"},{"location":"development/postman/using_postman/#using-the-fides-postman-collection","text":"A minimal Postman collection is included to assist in setting up your privacy request configurations, and in executing example access and erasure requests against mock external databases.","title":"Using the Fides postman collection"},{"location":"development/postman/using_postman/#loading-the-collection","text":"Get Postman Postman > File > Import Upload the Fides collection found in docs/fides/docs/postman/Fides.postman_collection.json Click on the imported fidesops collection in the left pane, and then find Variables to edit the fidesops collection variables. Some variables are populated for you, and some will be added in this guide's next steps. Add your oauth_root_client_id and oauth_root_client_secret under CURRENT VALUE . fidesadmin and fidesadminsecret are default configurations for testing, found in your fides.toml . Add the appropriate values for your instance if they differ. Important: Click Save !","title":"Loading the collection"},{"location":"development/postman/using_postman/#bring-up-local-servers-and-mock-databases","text":"Run nox -s dev -- <datastore> in your terminal. This brings up the Fides server and the list of datastores specified, i.e. nox -s dev -- postgres mongodb . These mock datastores are pre-populated with test data to represent your datastores. The following list of requests is kept in the Minimum API calls to create an Access Privacy Request folder. Some of the returned data will need to be saved as additional variables for use in other steps.","title":"Bring up local servers and mock databases"},{"location":"development/postman/using_postman/#saving-authentication-variables","text":"Click on the Get Root Client Token request, and click Send to send a POST request to Fides to create a root token. Copy the access_token returned in the response body, and paste it as the Current Value of root_client_token in Fides' variables. Important: Click Save ! Similarly, click on Create Client , and click Send to send a POST request to Fides to create a new client. Copy the client_id and client_secret and paste into Current Value slots in Fides variables and click \"Save\". Finally, click on the Get Client Token request, and click Send to send another POST request to Fides. This will create a token for the client made in the previous step. If you click on Body , you can see that the client_id and client_secret have been added as form data for you. Save the returned token under client_token in the Fides variables. The client_token will be automatically passed into the rest of your requests as the Bearer Token.","title":"Saving Authentication variables"},{"location":"development/postman/using_postman/#building-out-remaining-privacy-request-configuration","text":"Run through the remaining requests in the Minimum API calls to create an Access Privacy Request folder. Because variables are automatically being populated for you, you should be able to click on each request, clicking Send for each one. Inspect the Body of each request to see what is sent to Fides: Specify where your data is going: SEND Create/Update Storage - Local Storage Config - Sets up a local folder for uploading your privacy request results (local testing only) Configure what data you care about, and what to do with it: SEND Create/Update Policies - Creates a Policy to handle Privacy Requests SEND Create/Update Access Rule - Defines an access Rule on the previous Policy, which specifies results will be uploaded to the configured local storage SEND Create/Update Rule Targets - Specify a RuleTarget that says to will return data that has been marked as having a user data category Create ConnectionConfigs, and add connection secrets for the postgres_example and mongodb_example mock databases: SEND Create/Update Connection Configs: Postgres SEND Create/Update Connection Configs: Mongo SEND Update Connection Secrets: Postgres SEND Update Connection Secrets: Mongo Add annotations of the Postgres and Mongo datastores: SEND Create/Update Postgres Dataset SEND Create/Update Dataset Mongo API calls to additional supported datastores (MsSQL, MySQL) are in separate folders within the collection.","title":"Building out remaining privacy request configuration"},{"location":"development/postman/using_postman/#run-a-privacy-request","text":"You have now completed the basic configuration required to create an Access Request. SEND Create Access Privacy Requests If \"succeeded\", note the \"id\" that is returned. Succeeded means the privacy request has been created and is pending, not that its execution is complete. Check your local fides_uploads folder, configured earlier, to see access request results. This is run asynchronously, so it may take a few moments to complete. This particular request should have retrieved data from both the postgres_example and mongodb_example databases with the user data_category","title":"Run a privacy request"},{"location":"development/postman/using_postman/#next-steps","text":"Check out other requests in the collection! The Calls to create an Erasure Request folder walks you through configuring a separate erasure policy, and executing an erasure request. Note that these erasure requests will mask data in your connected datastores ( postgres_example and mongo_example here. If you connect your own live databases, data may be deleted. Happy experimenting!","title":"Next steps"},{"location":"development/ui/admin_ui/","text":"Admin UI Accessing the Control Panel From the root fides directory, run the following: 1 2 3 4 cd clients npm install cd admin-ui turbo run dev This will navigate you to the admin-ui directory, and start the development environment. Visit http://localhost:3000/ in your browser, and provide your user credentials to log in. Backend deployment Fides automatically serves a version of the UI when running nox -s dev . To deploy a full version of the UI from a backend, run the following from the root fidesops directory: 1 2 3 4 cd clients npm install cd admin-ui turbo run prod-export This will build and place the Admin UI files into a location accessible by backend fidesops deployments. To test the UI, run nox -s dev from the root directory, and visit http://0.0.0.0:8080/index.html .","title":"Admin UI"},{"location":"development/ui/admin_ui/#admin-ui","text":"","title":"Admin UI"},{"location":"development/ui/admin_ui/#accessing-the-control-panel","text":"From the root fides directory, run the following: 1 2 3 4 cd clients npm install cd admin-ui turbo run dev This will navigate you to the admin-ui directory, and start the development environment. Visit http://localhost:3000/ in your browser, and provide your user credentials to log in.","title":"Accessing the Control Panel"},{"location":"development/ui/admin_ui/#backend-deployment","text":"Fides automatically serves a version of the UI when running nox -s dev . To deploy a full version of the UI from a backend, run the following from the root fidesops directory: 1 2 3 4 cd clients npm install cd admin-ui turbo run prod-export This will build and place the Admin UI files into a location accessible by backend fidesops deployments. To test the UI, run nox -s dev from the root directory, and visit http://0.0.0.0:8080/index.html .","title":"Backend deployment"},{"location":"development/ui/overview/","text":"UI Development Overview The /clients directory houses all front-end packages and shared code amongst clients, and also includes e2e tests. Prerequisites To run and develop the Fides UI components locally, you'll need to do the following: Clone the Fides repository Install Node.js Globally install Turbo In the clients folder, run npm install . This will install the dev dependency turbo . This will also install the appropriate dependencies in clients and in each client within clients folder. You may need to first remove all node_modules in each of the clients (admin-ui, privacy-center, etc) Dependencies within this directory are managed by Turborepo. Our root package.json file defines 3 workspaces (or packages) that are part of the Turbo ecosystem: admin-ui privacy-center fides-js Running Locally 1 turbo run dev Running this in the root clients folder will result in every workspace being run. Running this command within admin-ui will result in only admin-ui being run. Available commands that exist for every workspace are defined in the root turbo.json file, while commands unique to a specific workspace are defined in the turbo.json file within the workspace. It's important to use the turbo command because, as you see in the turbo.json files, we've defined some dependencies and caching details on some turbo commands. Adding packages To install packages in any package in clients , run the following from clients : 1 npm install <package> --workspace = <workspace> Example: 1 npm install react --workspace = admin-ui See https://turbo.build/repo/docs/handbook/package-installation#addingremovingupgrading-packages for more details","title":"Overview"},{"location":"development/ui/overview/#ui-development-overview","text":"The /clients directory houses all front-end packages and shared code amongst clients, and also includes e2e tests.","title":"UI Development Overview"},{"location":"development/ui/overview/#prerequisites","text":"To run and develop the Fides UI components locally, you'll need to do the following: Clone the Fides repository Install Node.js Globally install Turbo In the clients folder, run npm install . This will install the dev dependency turbo . This will also install the appropriate dependencies in clients and in each client within clients folder. You may need to first remove all node_modules in each of the clients (admin-ui, privacy-center, etc) Dependencies within this directory are managed by Turborepo. Our root package.json file defines 3 workspaces (or packages) that are part of the Turbo ecosystem: admin-ui privacy-center fides-js","title":"Prerequisites"},{"location":"development/ui/overview/#running-locally","text":"1 turbo run dev Running this in the root clients folder will result in every workspace being run. Running this command within admin-ui will result in only admin-ui being run. Available commands that exist for every workspace are defined in the root turbo.json file, while commands unique to a specific workspace are defined in the turbo.json file within the workspace. It's important to use the turbo command because, as you see in the turbo.json files, we've defined some dependencies and caching details on some turbo commands.","title":"Running Locally"},{"location":"development/ui/overview/#adding-packages","text":"To install packages in any package in clients , run the following from clients : 1 npm install <package> --workspace = <workspace> Example: 1 npm install react --workspace = admin-ui See https://turbo.build/repo/docs/handbook/package-installation#addingremovingupgrading-packages for more details","title":"Adding packages"},{"location":"development/ui/privacy_center/","text":"Privacy Center A web application built in Next.js to collect privacy requests from users: access, erasure, consent, and more! Development To serve this application locally, first install your local dependencies at the root client directory level: In /clients : 1 npm install Then, run: 1 2 cd privacy-center turbo run dev This will automatically build and run the project. Building To build this application directly, run: 1 turbo run build As a Next application, it will output build artifacts to the .next directory. API The Privacy Center is a full-stack webserver but generally makes all it's API calls to the connected Fides server. However, it does host a small API of it's own that enables some basic \"edge\" functions like hosting a customized bundle of the fides.js script. To view the OpenAPI documentation, run the application locally and visit the /docs page for details: http://localhost:3000/docs Testing To run the interactive test interface, run: 1 turbo run test For a fully-loaded development & test setup of both the Privacy Center, run the following commands in two separate terminals: 1 2 cd privacy-center && turbo run dev cd privacy-center && turbo run cy:open There are two ways to test Fides consent components: Navigate to http://localhost:3000/fides-js-components-demo.html . This page comes pre-packaged with some default configurations to get up and running quickly with the consent components, and is also the page used by cypress e2e tests. To test other configurations, edit the fidesConfig object passed into Fides.init() in privacy-center/public/fides-js-components-demo.html . Navigate to http://localhost:3000/fides-js-demo.html . This page, unlike the above, calls the /api/fides-js Privacy Center endpoint. This endpoint loads config from the privacy center's legacy config.json , so it's closer to how a customer would actually use the fides-js package. In addition, we inject only the minimal config into fides-js . The overlay is not enabled by default on this page. Deployment To deploy this site, typically you should use the published ethyca/fides-privacy-center Docker image which is production-built Next.js image. See https://docs.ethyca.com for more! Configuration You may configure the appearance of this web application at build time by modifying the config.json file inside the config directory. You're able to control: The header of the document The descriptive text of the document Which actions are present, and each action's: Personally Identifying Information a user must submit Title Description Icon Policy key Whether consent management is enabled Consent options: Personally Identifying Information a user must submit Title Description Icon Which consent management options are present, and each option's: The Fides Data Use that the user may consent to Descriptive information for the type of consent The default consent state (opt in/out): This can be a single boolean which will apply when the user has not modified their consent. Or this can be an object with consent values that depend on the user's consent context, such as whether they are using Global Privacy Control. See fides-js for details. The cookie keys that will be available to fides.js , which can be used to access a user's consent choices outside of the Privacy Center. Whether the user's consent choice should be propagated to any configured third party services (executable). Note that currently, only one option may be marked executable at a time. You can also add any CSS you'd like to the page by adding it to the config.css file inside the config directory. Additionally, if you're handy with React and are feeling a little brave you can customize the entire application by modifying the TypeScript source code in pages/index.tsx and components/RequestModal.tsx . Configuring CSS In order to modify the way your application appears visually, you can add custom css to the config/config.css file. For example, to change the application's font to Courier: 1 2 3 * { font-family : Courier !important ; } Additionally, because this application uses CSS variables, you can modify those CSS variables directly, rather than adding custom CSS. The only caveat to this is that we need to do so in a way that overrides the CSS variables' original values so that we can avoid the complexity of modifying the JavaScript file that holds the base values. Our recommendation is that you do so by using selector specificity, as in the following example: 1 2 3 4 5 6 7 : root : root { /* Changes the text color to red */ --chakra-colors-gray-600 : #f00 ; /* Changes the background color to blue */ --chakra-colors-gray-50 : #00f ; } Not exactly the most appealing color scheme \u2013 but note that wherever those variables are used, they have been replaced. This allows you to modify the theme of the application consistently and with a single source of truth, adhering to modern CSS best practices.","title":"Privacy Center"},{"location":"development/ui/privacy_center/#privacy-center","text":"A web application built in Next.js to collect privacy requests from users: access, erasure, consent, and more!","title":"Privacy Center"},{"location":"development/ui/privacy_center/#development","text":"To serve this application locally, first install your local dependencies at the root client directory level: In /clients : 1 npm install Then, run: 1 2 cd privacy-center turbo run dev This will automatically build and run the project.","title":"Development"},{"location":"development/ui/privacy_center/#building","text":"To build this application directly, run: 1 turbo run build As a Next application, it will output build artifacts to the .next directory.","title":"Building"},{"location":"development/ui/privacy_center/#api","text":"The Privacy Center is a full-stack webserver but generally makes all it's API calls to the connected Fides server. However, it does host a small API of it's own that enables some basic \"edge\" functions like hosting a customized bundle of the fides.js script. To view the OpenAPI documentation, run the application locally and visit the /docs page for details: http://localhost:3000/docs","title":"API"},{"location":"development/ui/privacy_center/#testing","text":"To run the interactive test interface, run: 1 turbo run test For a fully-loaded development & test setup of both the Privacy Center, run the following commands in two separate terminals: 1 2 cd privacy-center && turbo run dev cd privacy-center && turbo run cy:open There are two ways to test Fides consent components: Navigate to http://localhost:3000/fides-js-components-demo.html . This page comes pre-packaged with some default configurations to get up and running quickly with the consent components, and is also the page used by cypress e2e tests. To test other configurations, edit the fidesConfig object passed into Fides.init() in privacy-center/public/fides-js-components-demo.html . Navigate to http://localhost:3000/fides-js-demo.html . This page, unlike the above, calls the /api/fides-js Privacy Center endpoint. This endpoint loads config from the privacy center's legacy config.json , so it's closer to how a customer would actually use the fides-js package. In addition, we inject only the minimal config into fides-js . The overlay is not enabled by default on this page.","title":"Testing"},{"location":"development/ui/privacy_center/#deployment","text":"To deploy this site, typically you should use the published ethyca/fides-privacy-center Docker image which is production-built Next.js image. See https://docs.ethyca.com for more!","title":"Deployment"},{"location":"development/ui/privacy_center/#configuration","text":"You may configure the appearance of this web application at build time by modifying the config.json file inside the config directory. You're able to control: The header of the document The descriptive text of the document Which actions are present, and each action's: Personally Identifying Information a user must submit Title Description Icon Policy key Whether consent management is enabled Consent options: Personally Identifying Information a user must submit Title Description Icon Which consent management options are present, and each option's: The Fides Data Use that the user may consent to Descriptive information for the type of consent The default consent state (opt in/out): This can be a single boolean which will apply when the user has not modified their consent. Or this can be an object with consent values that depend on the user's consent context, such as whether they are using Global Privacy Control. See fides-js for details. The cookie keys that will be available to fides.js , which can be used to access a user's consent choices outside of the Privacy Center. Whether the user's consent choice should be propagated to any configured third party services (executable). Note that currently, only one option may be marked executable at a time. You can also add any CSS you'd like to the page by adding it to the config.css file inside the config directory. Additionally, if you're handy with React and are feeling a little brave you can customize the entire application by modifying the TypeScript source code in pages/index.tsx and components/RequestModal.tsx .","title":"Configuration"},{"location":"development/ui/privacy_center/#configuring-css","text":"In order to modify the way your application appears visually, you can add custom css to the config/config.css file. For example, to change the application's font to Courier: 1 2 3 * { font-family : Courier !important ; } Additionally, because this application uses CSS variables, you can modify those CSS variables directly, rather than adding custom CSS. The only caveat to this is that we need to do so in a way that overrides the CSS variables' original values so that we can avoid the complexity of modifying the JavaScript file that holds the base values. Our recommendation is that you do so by using selector specificity, as in the following example: 1 2 3 4 5 6 7 : root : root { /* Changes the text color to red */ --chakra-colors-gray-600 : #f00 ; /* Changes the background color to blue */ --chakra-colors-gray-50 : #00f ; } Not exactly the most appealing color scheme \u2013 but note that wherever those variables are used, they have been replaced. This allows you to modify the theme of the application consistently and with a single source of truth, adhering to modern CSS best practices.","title":"Configuring CSS"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"The Fides Ecosystem Fides (pronounced /fee-dhez/ , from Latin: Fid\u0113s) is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in your runtime environment, and the enforcement of privacy regulations in your code. The Fides developer tools allow engineers and legal teams to label system privacy characteristics, orchestrate programmatic rights fulfillment, and audit stored personal identifiable information (PII) throughout application systems and infrastructure. This includes support for major privacy regulations (e.g. GDPR , CCPA and LGPD ), and standards like ISO 19944 by default. Key Features End-to-End Data Subject Request Automation Privacy-as-Code Compliance-minded Data Mapping Comprehensive Privacy Standard Support For more information, please visit our official docs site over at https://docs.ethyca.com","title":"What is Fides?"},{"location":"#the-fides-ecosystem","text":"Fides (pronounced /fee-dhez/ , from Latin: Fid\u0113s) is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in your runtime environment, and the enforcement of privacy regulations in your code. The Fides developer tools allow engineers and legal teams to label system privacy characteristics, orchestrate programmatic rights fulfillment, and audit stored personal identifiable information (PII) throughout application systems and infrastructure. This includes support for major privacy regulations (e.g. GDPR , CCPA and LGPD ), and standards like ISO 19944 by default.","title":"The Fides Ecosystem"},{"location":"#key-features","text":"End-to-End Data Subject Request Automation Privacy-as-Code Compliance-minded Data Mapping Comprehensive Privacy Standard Support For more information, please visit our official docs site over at https://docs.ethyca.com","title":"Key Features"},{"location":"ethyca/","text":"About Ethyca The mission of Ethyca is to make Internet-scale technology respectful and ethical. We're a venture-backed privacy technology team headquartered in New York, but working as a distributed team across the US to solve what we believe is the most important problem in technology today: the human right to privacy in vastly complex data-driven systems. What is Fides? Fides is a universally understandable, open-source language that can be used to describe privacy within tech infrastructure. Our existing tools use this language to power a low friction set of developer tools that integrate with your existing CI pipelines, making privacy a feature of your tech stack. With Fides, we hope everyone can build better tools for privacy in the next decade and beyond. What we Believe Data privacy is a human right that should be a native feature of any respectful technology. Today building great privacy as a feature in software is friction-filled and complicated. We're building open-source privacy tools for the developer community because we believe the only way to achieve a respectful internet is to make privacy an easy-to-implement layer of any tech stack. The Future We've been working on this problem since 2018 and have a clear view of our next five years. We're excited about the roadmap of features we'll add to Fides in order to make it the comprehensive tool for addressing the major challenges of privacy in both the code management and runtime environments. We'd love you to contribute to Fides, and you can do this directly as part of the open-source community. If you're interested in solving some of the toughest and most important problems facing internet scale data-driven software, join us now and get paid to work on this problem too! Your Participation Fides' success is predicated on your participation -- Privacy as Code can only become a reality if we ensure it's easy to understand, implement, and held as an interoperable standard for wide adoption. Your feedback, contributions, and improvements are encouraged as we build community with the sole objective of creating respectful software for everyone on the internet.","title":"About Ethyca"},{"location":"ethyca/#about-ethyca","text":"The mission of Ethyca is to make Internet-scale technology respectful and ethical. We're a venture-backed privacy technology team headquartered in New York, but working as a distributed team across the US to solve what we believe is the most important problem in technology today: the human right to privacy in vastly complex data-driven systems.","title":"About Ethyca"},{"location":"ethyca/#what-is-fides","text":"Fides is a universally understandable, open-source language that can be used to describe privacy within tech infrastructure. Our existing tools use this language to power a low friction set of developer tools that integrate with your existing CI pipelines, making privacy a feature of your tech stack. With Fides, we hope everyone can build better tools for privacy in the next decade and beyond.","title":"What is Fides?"},{"location":"ethyca/#what-we-believe","text":"Data privacy is a human right that should be a native feature of any respectful technology. Today building great privacy as a feature in software is friction-filled and complicated. We're building open-source privacy tools for the developer community because we believe the only way to achieve a respectful internet is to make privacy an easy-to-implement layer of any tech stack.","title":"What we Believe"},{"location":"ethyca/#the-future","text":"We've been working on this problem since 2018 and have a clear view of our next five years. We're excited about the roadmap of features we'll add to Fides in order to make it the comprehensive tool for addressing the major challenges of privacy in both the code management and runtime environments. We'd love you to contribute to Fides, and you can do this directly as part of the open-source community. If you're interested in solving some of the toughest and most important problems facing internet scale data-driven software, join us now and get paid to work on this problem too!","title":"The Future"},{"location":"ethyca/#your-participation","text":"Fides' success is predicated on your participation -- Privacy as Code can only become a reality if we ensure it's easy to understand, implement, and held as an interoperable standard for wide adoption. Your feedback, contributions, and improvements are encouraged as we build community with the sole objective of creating respectful software for everyone on the internet.","title":"Your Participation"},{"location":"license/","text":"License 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License. \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\" \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets \"[]\" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \"printed page\" as the copyright notice for easier identification within third-party archives. Copyright 2021- Ethyca, Inc. Licensed under the Apache License, Version 2.0 (the \"License\"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.","title":"License"},{"location":"license/#license","text":"1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. \"License\" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. \"Licensor\" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. \"Legal Entity\" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, \"control\" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. \"You\" (or \"Your\") shall mean an individual or Legal Entity exercising permissions granted by this License. \"Source\" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. \"Object\" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. \"Work\" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). \"Derivative Works\" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. \"Contribution\" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, \"submitted\" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as \"Not a Contribution.\" \"Contributor\" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a \"NOTICE\" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets \"[]\" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same \"printed page\" as the copyright notice for easier identification within third-party archives. Copyright 2021- Ethyca, Inc. Licensed under the Apache License, Version 2.0 (the \"License\"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.","title":"License"},{"location":"api/","text":"API Reference You can view the live, interactive Swagger API docs for Fides by visiting /docs on a running instance. This is a great way to experiment with the APIs using Swagger's built-in \"Try it out\" functionality. Below, we've embedded the latest release's API documentation as a living reference. These work largely the same, but since this documentation site isn't connected to a live instance, the \"Try it out\" and \"Authorize\" buttons won't work, sorry! All API routes will automatically matched with and without a trailing slash / . So /api/v1/config and /api/v1/config/ are both valid API calls. const ui = SwaggerUIBundle({ url: 'openapi.json', dom_id: '#swagger-ui', }) /*If there is an anchor tag, reload it after the page loads to scroll to * that section, since the Swagger UI takes some time to render. */ if (location.hash) { setTimeout(function() { location.href = location.href }, 200); }","title":"API"},{"location":"api/#api-reference","text":"You can view the live, interactive Swagger API docs for Fides by visiting /docs on a running instance. This is a great way to experiment with the APIs using Swagger's built-in \"Try it out\" functionality. Below, we've embedded the latest release's API documentation as a living reference. These work largely the same, but since this documentation site isn't connected to a live instance, the \"Try it out\" and \"Authorize\" buttons won't work, sorry! All API routes will automatically matched with and without a trailing slash / . So /api/v1/config and /api/v1/config/ are both valid API calls. const ui = SwaggerUIBundle({ url: 'openapi.json', dom_id: '#swagger-ui', }) /*If there is an anchor tag, reload it after the page loads to scroll to * that section, since the Swagger UI takes some time to render. */ if (location.hash) { setTimeout(function() { location.href = location.href }, 200); }","title":"API Reference"},{"location":"cli/","text":"CLI These are autogenerated CLI docs that reflect the latest PyPI release. fides 1 2 3 4 5 __Command-line tool for the Fides privacy engineering platform.__ --- _Note: The common MANIFESTS_DIR argument _always_ defaults to \".fides/\" if not specified._ Usage: 1 fides [OPTIONS] COMMAND [ARGS]... Options: 1 2 3 4 5 6 --version Show the version and exit. -f, --config-path TEXT Path to a Fides config file. _Defaults to `.fides/fides.toml`._ --local Run in `local_mode`. Where possible, this will force commands to run without the need for a server. --help Show this message and exit. fides annotate 1 Interactively annotate Fides resources. Usage: 1 fides annotate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides annotate dataset 1 Interactively annotate a dataset file in-place. Usage: 1 fides annotate dataset [OPTIONS] INPUT_FILENAME Options: 1 2 3 4 -a, --all-members Annotate all parts of the dataset including schemas and tables. -v, --validate Validate annotation inputs. --help Show this message and exit. fides db 1 Run actions against the application database. Usage: 1 fides db [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides db init 1 2 3 4 5 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. **WARNING**: Deprecated, use `upgrade` instead. Usage: 1 fides db init [OPTIONS] Options: 1 --help Show this message and exit. fides db reset 1 Reset the database back to its initial state. Usage: 1 fides db reset [OPTIONS] Options: 1 2 -y, --yes Automatically responds `yes` to any prompts. --help Show this message and exit. fides db upgrade 1 2 3 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. Usage: 1 fides db upgrade [OPTIONS] Options: 1 --help Show this message and exit. fides delete 1 Delete an object from the server. Usage: 1 2 fides delete [OPTIONS] {data_category|data_subject|data_use|dataset|organizati on|policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit. fides deploy 1 Deploy a sample project locally to try out Fides. Usage: 1 fides deploy [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides deploy down 1 Stops the sample project and removes all volumes. Usage: 1 fides deploy down [OPTIONS] Options: 1 --help Show this message and exit. fides deploy up 1 Starts a sample project via docker compose. Usage: 1 fides deploy up [OPTIONS] Options: 1 2 3 4 5 6 7 8 --no-pull Use a local image instead of trying to pull from DockerHub. --no-init Disable the initialization of the Fides CLI, to run in headless mode. --env-file PATH Use a custom ENV file for the Fides container to override settings. --image TEXT Use a custom image for the Fides container instead of the default ('ethyca/fides'). --help Show this message and exit. fides evaluate 1 Evaluate System-level Privacy Declarations against Organization-level Policy Rules. Usage: 1 fides evaluate [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 -k, --fides-key TEXT The fides_key of a specific policy to evaluate. -m, --message TEXT Describe the context of this evaluation. -a, --audit Validate that the objects in this evaluation produce a valid data map. --dry Do not upload objects or results to the Fides webserver. --help Show this message and exit. fides generate 1 Programmatically generate Fides objects. Usage: 1 fides generate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset 1 Generate Fides datasets. Usage: 1 fides generate dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset aws 1 Generate Fides datasets from specific Amazon Web Services. Usage: 1 fides generate dataset aws [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset aws dynamodb 1 Generates a dataset object from DynamoDB using the AWS boto3 connection config. Usage: 1 fides generate dataset aws dynamodb [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --single-dataset BOOLEAN --include-null Include null attributes. --help Show this message and exit. fides generate dataset db 1 Generate a Fides dataset by walking a database and recording every schema/table/field. Usage: 1 fides generate dataset db [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. --include-null Include null attributes. --help Show this message and exit. fides generate dataset gcp 1 Generate Fides datasets from Google Cloud Platform. Usage: 1 fides generate dataset gcp [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate dataset gcp bigquery 1 Generate a dataset object from BigQuery using a SQLAlchemy connection string. Usage: 1 fides generate dataset gcp bigquery [OPTIONS] DATASET_NAME OUTPUT_FILENAME Options: 1 2 3 4 --credentials-id TEXT Use credentials keys defined within Fides config. --keyfile-path TEXT --include-null Include null attributes. --help Show this message and exit. fides generate system 1 Generate Fides systems. Usage: 1 fides generate system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides generate system aws 1 2 Connect to an aws account and generate a system manifest file that consists of every tracked resource. Usage: 1 fides generate system aws [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit. fides generate system okta 1 2 Generates systems from your Okta applications. Connects via an Okta admin account. Usage: 1 fides generate system okta [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit. fides get 1 View an object from the server. Usage: 1 2 fides get [OPTIONS] {data_category|data_subject|data_use|dataset|organization| policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit. fides init 1 2 Initializes a Fides instance by creating the default directory and configuration file if not present. Usage: 1 fides init [OPTIONS] [FIDES_DIR] Options: 1 2 --opt-in Automatically opt-in to anonymous usage analytics. --help Show this message and exit. fides ls 1 View all objects of a single type from the server. Usage: 1 2 fides ls [OPTIONS] {data_category|data_subject|data_use|dataset|organization|p olicy|system|evaluation} Options: 1 2 -v, --verbose Displays the entire object list as YAML. --help Show this message and exit. fides parse 1 Parse all Fides objects located in the supplied directory. Usage: 1 fides parse [OPTIONS] [MANIFESTS_DIR] Options: 1 2 -v, --verbose Enable verbose output. --help Show this message and exit. fides pull 1 Update local resource files based on the state of the objects on the server. Usage: 1 fides pull [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides pull all 1 Retrieve all resources from the server and update the local manifest files. Usage: 1 fides pull all [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 -a, --all-resources TEXT Pulls all locally missing resources from the server into this file. --help Show this message and exit. fides pull data_category 1 Retrieve a specific data_category from the server and update the local manifest files. Usage: 1 fides pull data_category [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull data_subject 1 Retrieve a specific data_subject from the server and update the local manifest files. Usage: 1 fides pull data_subject [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull data_use 1 Retrieve a specific data_use from the server and update the local manifest files. Usage: 1 fides pull data_use [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull dataset 1 Retrieve a specific dataset from the server and update the local manifest files. Usage: 1 fides pull dataset [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides pull system 1 Retrieve a specific system from the server and update the local manifest files. Usage: 1 fides pull system [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit. fides push 1 Parse local manifest files and upload them to the server. Usage: 1 fides push [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 --dry Do not upload results to the Fides webserver. --diff Print any diffs between the local & server objects --help Show this message and exit. fides scan 1 Scan and report on discrepancies between Fides resource files and real infrastructure. Usage: 1 fides scan [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan dataset 1 Scan and report on Fides Dataset resources. Usage: 1 fides scan dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan dataset db 1 2 3 4 Scan a database directly using a SQLAlchemy-style connection string. _If there are fields within the database that aren't listed and categorized within one of the datasets, this counts as lacking coverage._ Usage: 1 fides scan dataset db [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides scan system 1 Scan and report on Fides System resources. Usage: 1 fides scan system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides scan system aws 1 2 3 Scan an AWS account and compare objects with annotated Fides Systems. _Scannable resources: [Redshift, RDS, DynamoDb, S3]_ Usage: 1 fides scan system aws [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides scan system okta 1 Scan an Okta account and compare applications with annotated Fides Systems. Usage: 1 fides scan system okta [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit. fides status 1 Check Fides server availability. Usage: 1 fides status [OPTIONS] Options: 1 --help Show this message and exit. fides user 1 Click command group for interacting with user-related functionality. Usage: 1 fides user [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides user create 1 Use the credentials file to create a new user. Gives full permissions to the new user. Usage: 1 fides user create [OPTIONS] USERNAME PASSWORD EMAIL_ADDRESS Options: 1 2 3 -f, --first-name TEXT -l, --last-name TEXT --help Show this message and exit. fides user login 1 2 Authenticate with the webserver and generate a user access token. Then store those credentials in a credentials file. Usage: 1 fides user login [OPTIONS] Options: 1 2 3 4 5 -u, --username TEXT If not provided, will be pulled from the config file or prompted for. -p, --password TEXT If not provided, will be pulled from the config file or prompted for. --help Show this message and exit. fides user permissions 1 List the directly-assigned scopes and roles available to the current user. Usage: 1 fides user permissions [OPTIONS] Options: 1 --help Show this message and exit. fides view 1 View various resources types. Usage: 1 fides view [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit. fides view config 1 2 3 Prints the configuration values being used for this command-line instance. _Note: To see the configuration values being used by the webserver, `GET` the `/api/v1/config` endpoint._ Usage: 1 fides view config [OPTIONS] [SECTION] Options: 1 2 --exclude-unset Only print configuration values explicitly set by the user. --help Show this message and exit. fides view credentials 1 Prints the credentials file. Usage: 1 fides view credentials [OPTIONS] Options: 1 --help Show this message and exit. fides webserver 1 2 3 Start the Fides webserver. _Requires Redis and Postgres to be configured and running_ Usage: 1 fides webserver [OPTIONS] Options: 1 2 -p, --port INTEGER --help Show this message and exit. fides worker 1 Start a Celery worker for the Fides webserver. Usage: 1 fides worker [OPTIONS] Options: 1 --help Show this message and exit.","title":"CLI"},{"location":"cli/#cli","text":"These are autogenerated CLI docs that reflect the latest PyPI release.","title":"CLI"},{"location":"cli/#fides","text":"1 2 3 4 5 __Command-line tool for the Fides privacy engineering platform.__ --- _Note: The common MANIFESTS_DIR argument _always_ defaults to \".fides/\" if not specified._ Usage: 1 fides [OPTIONS] COMMAND [ARGS]... Options: 1 2 3 4 5 6 --version Show the version and exit. -f, --config-path TEXT Path to a Fides config file. _Defaults to `.fides/fides.toml`._ --local Run in `local_mode`. Where possible, this will force commands to run without the need for a server. --help Show this message and exit.","title":"fides"},{"location":"cli/#fides-annotate","text":"1 Interactively annotate Fides resources. Usage: 1 fides annotate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"annotate"},{"location":"cli/#fides-annotate-dataset","text":"1 Interactively annotate a dataset file in-place. Usage: 1 fides annotate dataset [OPTIONS] INPUT_FILENAME Options: 1 2 3 4 -a, --all-members Annotate all parts of the dataset including schemas and tables. -v, --validate Validate annotation inputs. --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-db","text":"1 Run actions against the application database. Usage: 1 fides db [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"db"},{"location":"cli/#fides-db-init","text":"1 2 3 4 5 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. **WARNING**: Deprecated, use `upgrade` instead. Usage: 1 fides db init [OPTIONS] Options: 1 --help Show this message and exit.","title":"init"},{"location":"cli/#fides-db-reset","text":"1 Reset the database back to its initial state. Usage: 1 fides db reset [OPTIONS] Options: 1 2 -y, --yes Automatically responds `yes` to any prompts. --help Show this message and exit.","title":"reset"},{"location":"cli/#fides-db-upgrade","text":"1 2 3 Runs all upgrade migrations for the Fides database. Will also automatically initialize a fresh database. Usage: 1 fides db upgrade [OPTIONS] Options: 1 --help Show this message and exit.","title":"upgrade"},{"location":"cli/#fides-delete","text":"1 Delete an object from the server. Usage: 1 2 fides delete [OPTIONS] {data_category|data_subject|data_use|dataset|organizati on|policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit.","title":"delete"},{"location":"cli/#fides-deploy","text":"1 Deploy a sample project locally to try out Fides. Usage: 1 fides deploy [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"deploy"},{"location":"cli/#fides-deploy-down","text":"1 Stops the sample project and removes all volumes. Usage: 1 fides deploy down [OPTIONS] Options: 1 --help Show this message and exit.","title":"down"},{"location":"cli/#fides-deploy-up","text":"1 Starts a sample project via docker compose. Usage: 1 fides deploy up [OPTIONS] Options: 1 2 3 4 5 6 7 8 --no-pull Use a local image instead of trying to pull from DockerHub. --no-init Disable the initialization of the Fides CLI, to run in headless mode. --env-file PATH Use a custom ENV file for the Fides container to override settings. --image TEXT Use a custom image for the Fides container instead of the default ('ethyca/fides'). --help Show this message and exit.","title":"up"},{"location":"cli/#fides-evaluate","text":"1 Evaluate System-level Privacy Declarations against Organization-level Policy Rules. Usage: 1 fides evaluate [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 -k, --fides-key TEXT The fides_key of a specific policy to evaluate. -m, --message TEXT Describe the context of this evaluation. -a, --audit Validate that the objects in this evaluation produce a valid data map. --dry Do not upload objects or results to the Fides webserver. --help Show this message and exit.","title":"evaluate"},{"location":"cli/#fides-generate","text":"1 Programmatically generate Fides objects. Usage: 1 fides generate [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"generate"},{"location":"cli/#fides-generate-dataset","text":"1 Generate Fides datasets. Usage: 1 fides generate dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-generate-dataset-aws","text":"1 Generate Fides datasets from specific Amazon Web Services. Usage: 1 fides generate dataset aws [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-generate-dataset-aws-dynamodb","text":"1 Generates a dataset object from DynamoDB using the AWS boto3 connection config. Usage: 1 fides generate dataset aws dynamodb [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --single-dataset BOOLEAN --include-null Include null attributes. --help Show this message and exit.","title":"dynamodb"},{"location":"cli/#fides-generate-dataset-db","text":"1 Generate a Fides dataset by walking a database and recording every schema/table/field. Usage: 1 fides generate dataset db [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. --include-null Include null attributes. --help Show this message and exit.","title":"db"},{"location":"cli/#fides-generate-dataset-gcp","text":"1 Generate Fides datasets from Google Cloud Platform. Usage: 1 fides generate dataset gcp [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"gcp"},{"location":"cli/#fides-generate-dataset-gcp-bigquery","text":"1 Generate a dataset object from BigQuery using a SQLAlchemy connection string. Usage: 1 fides generate dataset gcp bigquery [OPTIONS] DATASET_NAME OUTPUT_FILENAME Options: 1 2 3 4 --credentials-id TEXT Use credentials keys defined within Fides config. --keyfile-path TEXT --include-null Include null attributes. --help Show this message and exit.","title":"bigquery"},{"location":"cli/#fides-generate-system","text":"1 Generate Fides systems. Usage: 1 fides generate system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-generate-system-aws","text":"1 2 Connect to an aws account and generate a system manifest file that consists of every tracked resource. Usage: 1 fides generate system aws [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-generate-system-okta","text":"1 2 Generates systems from your Okta applications. Connects via an Okta admin account. Usage: 1 fides generate system okta [OPTIONS] OUTPUT_FILENAME Options: 1 2 3 4 5 6 7 8 9 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ --include-null Include null attributes. -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] --help Show this message and exit.","title":"okta"},{"location":"cli/#fides-get","text":"1 View an object from the server. Usage: 1 2 fides get [OPTIONS] {data_category|data_subject|data_use|dataset|organization| policy|system|evaluation} FIDES_KEY Options: 1 --help Show this message and exit.","title":"get"},{"location":"cli/#fides-init","text":"1 2 Initializes a Fides instance by creating the default directory and configuration file if not present. Usage: 1 fides init [OPTIONS] [FIDES_DIR] Options: 1 2 --opt-in Automatically opt-in to anonymous usage analytics. --help Show this message and exit.","title":"init"},{"location":"cli/#fides-ls","text":"1 View all objects of a single type from the server. Usage: 1 2 fides ls [OPTIONS] {data_category|data_subject|data_use|dataset|organization|p olicy|system|evaluation} Options: 1 2 -v, --verbose Displays the entire object list as YAML. --help Show this message and exit.","title":"ls"},{"location":"cli/#fides-parse","text":"1 Parse all Fides objects located in the supplied directory. Usage: 1 fides parse [OPTIONS] [MANIFESTS_DIR] Options: 1 2 -v, --verbose Enable verbose output. --help Show this message and exit.","title":"parse"},{"location":"cli/#fides-pull","text":"1 Update local resource files based on the state of the objects on the server. Usage: 1 fides pull [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"pull"},{"location":"cli/#fides-pull-all","text":"1 Retrieve all resources from the server and update the local manifest files. Usage: 1 fides pull all [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 -a, --all-resources TEXT Pulls all locally missing resources from the server into this file. --help Show this message and exit.","title":"all"},{"location":"cli/#fides-pull-data_category","text":"1 Retrieve a specific data_category from the server and update the local manifest files. Usage: 1 fides pull data_category [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_category"},{"location":"cli/#fides-pull-data_subject","text":"1 Retrieve a specific data_subject from the server and update the local manifest files. Usage: 1 fides pull data_subject [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_subject"},{"location":"cli/#fides-pull-data_use","text":"1 Retrieve a specific data_use from the server and update the local manifest files. Usage: 1 fides pull data_use [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"data_use"},{"location":"cli/#fides-pull-dataset","text":"1 Retrieve a specific dataset from the server and update the local manifest files. Usage: 1 fides pull dataset [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-pull-system","text":"1 Retrieve a specific system from the server and update the local manifest files. Usage: 1 fides pull system [OPTIONS] FIDES_KEY [MANIFESTS_DIR] Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-push","text":"1 Parse local manifest files and upload them to the server. Usage: 1 fides push [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 --dry Do not upload results to the Fides webserver. --diff Print any diffs between the local & server objects --help Show this message and exit.","title":"push"},{"location":"cli/#fides-scan","text":"1 Scan and report on discrepancies between Fides resource files and real infrastructure. Usage: 1 fides scan [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"scan"},{"location":"cli/#fides-scan-dataset","text":"1 Scan and report on Fides Dataset resources. Usage: 1 fides scan dataset [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"dataset"},{"location":"cli/#fides-scan-dataset-db","text":"1 2 3 4 Scan a database directly using a SQLAlchemy-style connection string. _If there are fields within the database that aren't listed and categorized within one of the datasets, this counts as lacking coverage._ Usage: 1 fides scan dataset db [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 --credentials-id TEXT Use credentials keys defined within Fides config. --connection-string TEXT Use the connection string option to connect to a database. -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"db"},{"location":"cli/#fides-scan-system","text":"1 Scan and report on Fides System resources. Usage: 1 fides scan system [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"system"},{"location":"cli/#fides-scan-system-aws","text":"1 2 3 Scan an AWS account and compare objects with annotated Fides Systems. _Scannable resources: [Redshift, RDS, DynamoDb, S3]_ Usage: 1 fides scan system aws [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --credentials-id TEXT Use credentials keys defined within Fides config. --access_key_id TEXT Connect to AWS using an `Access Key ID`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --secret_access_key TEXT Connect to AWS using an `Access Key`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ --session_token TEXT Connect to AWS using a temporary `Access Key`. _Requires options `--access_key_id`, `--secret_access_key`, `--session_token`, & `--region`._ --region TEXT Connect to AWS using a specific `Region`. _Requires options `--access_key_id`, `--secret_access_key` & `--region`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"aws"},{"location":"cli/#fides-scan-system-okta","text":"1 Scan an Okta account and compare applications with annotated Fides Systems. Usage: 1 fides scan system okta [OPTIONS] [MANIFESTS_DIR] Options: 1 2 3 4 5 6 7 8 9 10 11 12 13 --credentials-id TEXT Use credentials keys defined within Fides config. --org-url TEXT Connect to Okta using an 'Org URL'. _Requires options `--org-url` & `--token`._ --token TEXT Connect to Okta using a token. _Requires options `--org-url` and `--token`._ -k, --org-key TEXT The `organization_fides_key` of the `Organization` you want to specify. [default: default_organization] -c, --coverage-threshold INTEGER RANGE Set the coverage percentage for a passing scan. [0<=x<=100] --help Show this message and exit.","title":"okta"},{"location":"cli/#fides-status","text":"1 Check Fides server availability. Usage: 1 fides status [OPTIONS] Options: 1 --help Show this message and exit.","title":"status"},{"location":"cli/#fides-user","text":"1 Click command group for interacting with user-related functionality. Usage: 1 fides user [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"user"},{"location":"cli/#fides-user-create","text":"1 Use the credentials file to create a new user. Gives full permissions to the new user. Usage: 1 fides user create [OPTIONS] USERNAME PASSWORD EMAIL_ADDRESS Options: 1 2 3 -f, --first-name TEXT -l, --last-name TEXT --help Show this message and exit.","title":"create"},{"location":"cli/#fides-user-login","text":"1 2 Authenticate with the webserver and generate a user access token. Then store those credentials in a credentials file. Usage: 1 fides user login [OPTIONS] Options: 1 2 3 4 5 -u, --username TEXT If not provided, will be pulled from the config file or prompted for. -p, --password TEXT If not provided, will be pulled from the config file or prompted for. --help Show this message and exit.","title":"login"},{"location":"cli/#fides-user-permissions","text":"1 List the directly-assigned scopes and roles available to the current user. Usage: 1 fides user permissions [OPTIONS] Options: 1 --help Show this message and exit.","title":"permissions"},{"location":"cli/#fides-view","text":"1 View various resources types. Usage: 1 fides view [OPTIONS] COMMAND [ARGS]... Options: 1 --help Show this message and exit.","title":"view"},{"location":"cli/#fides-view-config","text":"1 2 3 Prints the configuration values being used for this command-line instance. _Note: To see the configuration values being used by the webserver, `GET` the `/api/v1/config` endpoint._ Usage: 1 fides view config [OPTIONS] [SECTION] Options: 1 2 --exclude-unset Only print configuration values explicitly set by the user. --help Show this message and exit.","title":"config"},{"location":"cli/#fides-view-credentials","text":"1 Prints the credentials file. Usage: 1 fides view credentials [OPTIONS] Options: 1 --help Show this message and exit.","title":"credentials"},{"location":"cli/#fides-webserver","text":"1 2 3 Start the Fides webserver. _Requires Redis and Postgres to be configured and running_ Usage: 1 fides webserver [OPTIONS] Options: 1 2 -p, --port INTEGER --help Show this message and exit.","title":"webserver"},{"location":"cli/#fides-worker","text":"1 Start a Celery worker for the Fides webserver. Usage: 1 fides worker [OPTIONS] Options: 1 --help Show this message and exit.","title":"worker"},{"location":"community/code_of_conduct/","text":"Fides Code of Conduct Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Our Standards Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct that could reasonably be considered inappropriate in a professional setting Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. Scope This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Fides core team at fides@ethyca.com . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. Attribution This Code of Conduct is adapted from the Contributor Covenant , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq","title":"Code of Conduct"},{"location":"community/code_of_conduct/#fides-code-of-conduct","text":"","title":"Fides Code of Conduct"},{"location":"community/code_of_conduct/#our-pledge","text":"In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.","title":"Our Pledge"},{"location":"community/code_of_conduct/#our-standards","text":"Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct that could reasonably be considered inappropriate in a professional setting","title":"Our Standards"},{"location":"community/code_of_conduct/#our-responsibilities","text":"Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.","title":"Our Responsibilities"},{"location":"community/code_of_conduct/#scope","text":"This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.","title":"Scope"},{"location":"community/code_of_conduct/#enforcement","text":"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Fides core team at fides@ethyca.com . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.","title":"Enforcement"},{"location":"community/code_of_conduct/#attribution","text":"This Code of Conduct is adapted from the Contributor Covenant , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq","title":"Attribution"},{"location":"community/hints_tips/","text":"Community The Fides project welcomes issues, contributions and discussion from all users, regardless of background or experience level. In order to create a positive and welcoming environment, all interactions are governed by the Fides Code of Conduct . Guidelines Whether it's giving us feedback, raising a question, or showing your Fides-related work, we are looking forward to hearing from you. The Fides community is vibrant because of the quality of its members and the discussions they bring. To keep the workspace inviting and helpful for everyone, there are a few guidelines that we ask all members to follow. Rule 1: Assume Positive Intent Being nice is the most important pillar of the Fides community. We are considerate to each other's effort and time. It's also easy to misinterpret people through Slack, so we make an extra effort to chat in a positive tone. We assume that you are here to learn and exchange ideas, and we ask that you contribute to making a welcoming community. If someone is helping you, be mindful of the effort they are putting in. While we are always happy to help users, we can not help users with step-by-step debugging. Use your professional judgment in discerning whether requests are unreasonable. The Fides team always tries to listen to the community. Please be understanding if your issue or feature request is not deemed an immediate priority. Rule 2: Use threads for larger messages Because of the size of our community and frequency of posts, it's easy for large messages to drown out smaller messages. Using threads helps people see more messages on their screen. Larger code blocks should be posted in threads. Rule 3: Avoid posting sensitive information Community members sometimes need to post code snippets as they ask for help. Be sure to remove sensitive information from posts to the public channels. If your Fides account information is needed to help you, we will ask you to direct message such information. Be cautious of anyone asking for information through direct messages. Rule 4: Write high quality questions The Fides community is here to support you. That said, it is significantly easier to answer well-researched and clearly-written questions. Even adding potentially relevant links to a post helps tremendously. Informative Slack threads are archived by our resident bot Marvin. Having well-written threads helps future users encountering the same problem. Oftentimes your question may have been answered somewhere else; some good resources to start looking before asking a question: Fides Documentation GitHub Issues StackOverflow Rule 5: Don't abuse tagging users Requests for help will be seen by the Fides team, and will be directed to the appropriate person. Tagging individual users is highly discouraged unless it is in the context of a conversation thread. Rule 6: Avoid using DMs to ask for help Fides employees should not be sent questions in DMs unless we specifically ask you to send us private information. There are times when it makes sense to directly message another community member experiencing a similar issue, or working with similar technologies. Just be aware that some people may not want to be messaged. It also helps other people if you post your question publicly. Similar to above, informative Slack threads are archived. Having conversations in public channels drives better quality discussions that can be referenced in the future. Rule 7: Don't advertise material unrelated to Fides Our community is in the channel to learn more about Fides. Showing us Fides-related stuff that you're working on is highly encouraged. Advertising products and events unrelated to Fides will be removed.","title":"Community Hints and Tips"},{"location":"community/hints_tips/#community","text":"The Fides project welcomes issues, contributions and discussion from all users, regardless of background or experience level. In order to create a positive and welcoming environment, all interactions are governed by the Fides Code of Conduct .","title":"Community"},{"location":"community/hints_tips/#guidelines","text":"Whether it's giving us feedback, raising a question, or showing your Fides-related work, we are looking forward to hearing from you. The Fides community is vibrant because of the quality of its members and the discussions they bring. To keep the workspace inviting and helpful for everyone, there are a few guidelines that we ask all members to follow.","title":"Guidelines"},{"location":"community/hints_tips/#rule-1-assume-positive-intent","text":"Being nice is the most important pillar of the Fides community. We are considerate to each other's effort and time. It's also easy to misinterpret people through Slack, so we make an extra effort to chat in a positive tone. We assume that you are here to learn and exchange ideas, and we ask that you contribute to making a welcoming community. If someone is helping you, be mindful of the effort they are putting in. While we are always happy to help users, we can not help users with step-by-step debugging. Use your professional judgment in discerning whether requests are unreasonable. The Fides team always tries to listen to the community. Please be understanding if your issue or feature request is not deemed an immediate priority.","title":"Rule 1: Assume Positive Intent"},{"location":"community/hints_tips/#rule-2-use-threads-for-larger-messages","text":"Because of the size of our community and frequency of posts, it's easy for large messages to drown out smaller messages. Using threads helps people see more messages on their screen. Larger code blocks should be posted in threads.","title":"Rule 2: Use threads for larger messages"},{"location":"community/hints_tips/#rule-3-avoid-posting-sensitive-information","text":"Community members sometimes need to post code snippets as they ask for help. Be sure to remove sensitive information from posts to the public channels. If your Fides account information is needed to help you, we will ask you to direct message such information. Be cautious of anyone asking for information through direct messages.","title":"Rule 3: Avoid posting sensitive information"},{"location":"community/hints_tips/#rule-4-write-high-quality-questions","text":"The Fides community is here to support you. That said, it is significantly easier to answer well-researched and clearly-written questions. Even adding potentially relevant links to a post helps tremendously. Informative Slack threads are archived by our resident bot Marvin. Having well-written threads helps future users encountering the same problem. Oftentimes your question may have been answered somewhere else; some good resources to start looking before asking a question: Fides Documentation GitHub Issues StackOverflow","title":"Rule 4: Write high quality questions"},{"location":"community/hints_tips/#rule-5-dont-abuse-tagging-users","text":"Requests for help will be seen by the Fides team, and will be directed to the appropriate person. Tagging individual users is highly discouraged unless it is in the context of a conversation thread.","title":"Rule 5: Don't abuse tagging users"},{"location":"community/hints_tips/#rule-6-avoid-using-dms-to-ask-for-help","text":"Fides employees should not be sent questions in DMs unless we specifically ask you to send us private information. There are times when it makes sense to directly message another community member experiencing a similar issue, or working with similar technologies. Just be aware that some people may not want to be messaged. It also helps other people if you post your question publicly. Similar to above, informative Slack threads are archived. Having conversations in public channels drives better quality discussions that can be referenced in the future.","title":"Rule 6: Avoid using DMs to ask for help"},{"location":"community/hints_tips/#rule-7-dont-advertise-material-unrelated-to-fides","text":"Our community is in the channel to learn more about Fides. Showing us Fides-related stuff that you're working on is highly encouraged. Advertising products and events unrelated to Fides will be removed.","title":"Rule 7: Don't advertise material unrelated to Fides"},{"location":"community/overview/","text":"Join the Fides Community We believe the only way to solve privacy is as a community of likeminded developers that care to solve these problems for the rest of the world. To make it easier to connect and share ideas, we've created a set of community channels which we'd love to hear from you on: Start Contributing \u2003 Chat on Slack \u2003 Chat on Discord","title":"Github, Slack, and Discord"},{"location":"community/overview/#join-the-fides-community","text":"We believe the only way to solve privacy is as a community of likeminded developers that care to solve these problems for the rest of the world. To make it easier to connect and share ideas, we've created a set of community channels which we'd love to hear from you on: Start Contributing \u2003 Chat on Slack \u2003 Chat on Discord","title":"Join the Fides Community"},{"location":"config/","text":"Configuration Setting Configuration Values Fides can be configured in two different ways: either via a toml file or via environment variables. Both methods can be used simultaneously, with environment variables taking precedence over the toml file values. Using a Configuration File Fides will use the first config file it can read from the following locations. Listed in order of precedence they are: At the path specified using the config file argument passed through the CLI, i.e. fides -f <config_path> At the path specified by the FIDES__CONFIG_PATH environment variable In the current working directory it will check for a subdir .fides and a file within named fides.toml , i.e. ./.fides/fides.toml Generating a Config File If you'd like to generate a new config file automatically using default values, run fides init . This will create the file at the default location of ./.fides/fides.toml Setting Values Via Environment Variables Fides follows a set pattern for configuration via environment variables. It looks for environment variables that start with FIDES followed by the config subsection name, followed by the key name, all separated with double underscores. In practice this would look like FIDES__<SUBSECTION>__<KEY> As a toml configuration value: 1 2 [database] host = config _ example As an environment variable: 1 EXPORT FIDES__DATABASE__HOST = config_example Viewing your configuration You can view the current configuration of your application via either the CLI or API. CLI To view your application configuration via the CLI, run: 1 fides view config This will show all configuration variables, including sensitive ones. It is printed to the console as valid toml , so this can be copy/pasted as needed. API To view your application configuration in the API, run: 1 GET /api/v1/config For security reasons, sensitive configuration values will not be shown here. Special Sections There are a few \"special\" configuration sections that behave in unique ways compared to the other sections. These sections will be addressed in the following documentation. Celery Fides uses Celery for asynchronous task management. To simplify deployments and remove the need for two different toml configuration files, it is possible to configure Celery via the Fides configuration file. Any valid configuration key/value pair for Celery can instead be added to the Fides toml configuration file and will automatically be passed through to the Celery deployment. Note that Fides will not validate any of these key/value pairs. See the above configuration file reference for an example of using celery configuration pass-through. For a full list of possible variable overrides, see the Celery configuration documentation . Example Celery Section 1 2 3 4 [celery] event_queue_prefix = \"fides_worker\" task_default_queue = \"fides\" task_always_eager = true Credentials The credentials section uses custom keys which can be referenced in specific commands that take the --credentials-id option. For example, a command that uses a credential might look like fides scan dataset db --credentials-id app_postgres . The credential object itself will be validated at the time of use depending on what type of credential is required. For instance if fides scan system okta is used, it will expect the object to contain orgUrl and token key/value pairs. In the case of a typical database like postgres, it will only expect a connection_string. The following is an example of what a credentials section might look like in a given deployment with various applications: Example Credentials Section 1 2 [credentials] app_postgres = { connection_string = \"postgresql+psycopg2://postgres:fides@fides-db:5432/fides\" } Configuration File Reference This following file is an autogenerated configuration reference file. It shows application defaults and is a valid toml file that can be used for configuration of Fides. fides.toml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 # Fides Configuration File # Additional Documentation at : https://ethyca.github.io/fides/stable/config/ #--------------# #-- ADMIN_UI --# #--------------------------------------------------------------------# [admin_ui] # Configuration settings for the Admin UI. # Toggle whether the Admin UI is served. enabled = true # boolean #------------# #-- CELERY --# #--------------------------------------------------------------------# [celery] # Configuration settings for Celery. Only a small subset can be configured through Fides env vars # The prefix to use for event receiver queue names event_queue_prefix = \"fides_worker\" # string # The name of the default queue if a message has no route or no custom # queue has been specified task_default_queue = \"fides\" # string # If true, tasks are executed locally instead of being sent to the # queue. If False, tasks are sent to the queue. task_always_eager = true # boolean #---------# #-- CLI --# #--------------------------------------------------------------------# [cli] # Configuration settings for the command-line application. # A fully anonymized unique identifier that is automatically generated # by the application. Used for anonymous analytics when opted-in. analytics_id = \"dc3e438ddaaf3cd7c251c877ce7b9e77\" # string # When set to True, disables functionality that requires making calls # to a Fides webserver. local_mode = false # boolean # The protocol used by the Fides webserver. server_protocol = \"http\" # string # The hostname of the Fides webserver. server_host = \"localhost\" # string # The port of the Fides webserver server_port = \"8080\" # string # The path of the Fides webserver server_path = \"/\" # string #-------------# #-- CONSENT --# #--------------------------------------------------------------------# [consent] # Configuration settings for Consent. # Toggle whether TCF is enabled. tcf_enabled = false # boolean # Toggle whether Google AC Mode is enabled. ac_enabled = false # boolean # Whether or not vendor purposes can be globally overridden. override_vendor_purposes = false # boolean #--------------# #-- DATABASE --# #--------------------------------------------------------------------# [database] # Configuration settings for the application database. # Automatically runs migrations on webserver startup. If set to # `false`, will require the user to run migrations manually via the CLI # or API. WARNING: Must be set to `true` for first-time startup. automigrate = true # boolean # Number of concurrent database connections Fides will use for API # requests. Note that the pool begins with no connections, but as they # are requested the connections are maintained and reused up to this # limit. api_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for API requests if the pool reaches the limit. These # overflow connections are discarded afterwards and not maintained. api_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. api_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. api_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. api_engine_keepalives_count = 5 # integer # The name of the application database. db = \"default_db\" # string # When set to True, initializes the database with sample data for # testing (Systems, Datasets, Connectors, etc.) Used by 'fides deploy' # to configure the sample project. load_samples = false # boolean # The password with which to login to the application database. password = \"defaultpassword\" # string # The port at which the application database will be accessible. port = \"5432\" # string # The hostname of the application database server. server = \"default-db\" # string # Number of concurrent database connections Fides will use for # executing privacy request tasks, either locally or on each worker. # Note that the pool begins with no connections, but as they are # requested the connections are maintained and reused up to this limit. task_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for executing privacy request tasks, either locally or on # each worker, if the pool reaches the limit. These overflow # connections are discarded afterwards and not maintained. task_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. task_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. task_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. task_engine_keepalives_count = 5 # integer # The database user with which to login to the application database. user = \"defaultuser\" # string # Additional connection parameters used when connecting to the # application database. params = {} # object #---------------# #-- EXECUTION --# #--------------------------------------------------------------------# [execution] # Configuration settings for DSR execution. # If set to True, only use UPDATE requests to mask data. If False, # Fides will use any defined DELETE or GDPR DELETE endpoints to remove # PII, which may extend beyond the specific data categories that # configured in your execution policy. masking_strict = true # boolean # The amount of time to wait for actions which delay privacy requests # (e.g., pre- and post-processing webhooks). privacy_request_delay_timeout = 3600 # integer # Whether privacy requests require explicit approval to execute. require_manual_request_approval = false # boolean # Whether privacy requests require user identity verification. subject_identity_verification_required = false # boolean # The backoff factor for retries, to space out repeated retries. task_retry_backoff = 1 # integer # The number of times a failed request will be retried. task_retry_count = 0 # integer # The delays between retries in seconds. task_retry_delay = 1 # integer # Allows the collection of custom privacy request fields from incoming # privacy requests. allow_custom_privacy_request_field_collection = false # boolean # Allows custom privacy request fields to be used in request execution. allow_custom_privacy_request_fields_in_request_execution = false # boolean # The number of seconds a request task should live. request_task_ttl = 604800 # integer # Seconds between polling for Privacy Requests that should change state state_polling_interval = 30 # integer # Temporary flag to switch to using DSR 3.0 to process your tasks. use_dsr_3_0 = false # boolean #-------------# #-- LOGGING --# #--------------------------------------------------------------------# [logging] # Configuration settings for application logging. # The output location for log files. Accepts any valid file path. If # left unset, log entries are printed to stdout and log files are not # produced. destination = \"\" # string # Force colored logs. Any value set via environment variables is # considered 'True'. colorize = false # boolean # The minimum log entry level to produce. Also accepts TRACE, DEBUG, # WARNING, ERROR, or CRITICAL (case insensitive). level = \"INFO\" # string # The format with which to produce log entries. If left unset, produces # log entries formatted using the internal custom formatter. Also # accepts 'JSON' (case insensitive). serialization = \"\" # string # If True, PII values will display unmasked in log output. This # variable should always be set to 'False' in production systems. log_pii = false # boolean #-------------------# #-- NOTIFICATIONS --# #--------------------------------------------------------------------# [notifications] # Configuration settings for Data Subject and/or Data Processor notifications. # When set to True, enables subject notifications upon privacy request # completion. send_request_completion_notification = false # boolean # When set to True, enables subject notifications upon privacy request # receipt. send_request_receipt_notification = false # boolean # When set to True, enables subject notifications upon privacy request # review. send_request_review_notification = false # boolean # When set to True, enables property specific messaging feature, # otherwise fall back on the messaging template type env flags set # above. enable_property_specific_messaging = false # boolean #-----------# #-- REDIS --# #--------------------------------------------------------------------# [redis] # Configuration settings for Redis. # Character set to use for Redis, defaults to 'utf8'. Not recommended # to change. charset = \"utf8\" # string # The application will use this index in the Redis cache to cache data. db_index = 0 # integer # Whether or not to automatically decode the values fetched from Redis. # Decodes using the `charset` configuration value. decode_responses = true # boolean # The number of seconds for which data will live in Redis before # automatically expiring. default_ttl_seconds = 604800 # integer # Whether the application's Redis cache should be enabled. Only set to # false for certain narrow uses of the application. enabled = true # boolean # The network address for the application Redis cache. host = \"redis\" # string # Sets TTL for cached identity verification code as part of subject # requests. identity_verification_code_ttl_seconds = 600 # integer # The password with which to login to the Redis cache. password = \"testpassword\" # string # The port at which the application cache will be accessible. port = 6379 # integer # Whether the application's connections to the cache should be # encrypted using TLS. ssl = false # boolean # If using TLS encryption, set this to 'required' if you wish to # enforce the Redis cache to provide a certificate. Note that not all # cache providers support this without setting ssl_ca_certs (e.g. AWS # Elasticache). ssl_cert_reqs = \"required\" # string # If using TLS encryption rooted with a custom Certificate Authority, # set this to the path of the CA certificate. ssl_ca_certs = \"\" # string # The user with which to login to the Redis cache. user = \"\" # string #--------------# #-- SECURITY --# #--------------------------------------------------------------------# [security] # Configuration settings for application security. # Length of desired encryption key when using Fides to generate a # random secure string used for AES encryption. aes_encryption_key_length = 16 # integer # Length of desired random byte str for the AES GCM encryption used # throughout Fides. aes_gcm_nonce_length = 12 # integer # The key used to sign Fides API access tokens. app_encryption_key = \"\" # string # Text encoding to use for the application. encoding = \"UTF-8\" # string # The default, `dev`, does not apply authentication to endpoints # typically used by the CLI. The other option, `prod`, requires # authentication for _all_ endpoints that may contain sensitive # information. env = \"prod\" # string # The number of times identity verification will be attempted before # raising an error. identity_verification_attempt_limit = 3 # integer # The value used to identify the Fides application root API client. oauth_root_client_id = \"\" # string # The secret value used to authenticate the Fides application root API # client. oauth_root_client_secret = \"\" # string # The time in minutes for which Fides API tokens will be valid. Default # value is equal to 8 days. oauth_access_token_expire_minutes = 11520 # integer # Sets desired length in bytes of generated client id used for oauth. oauth_client_id_length_bytes = 16 # integer # Sets desired length in bytes of generated client secret used for # oauth. oauth_client_secret_length_bytes = 16 # integer # The number of requests from a single IP address allowed to hit a # public endpoint within the specified time period public_request_rate_limit = \"2000/minute\" # string # The prefix given to keys in the Redis cache used by the rate limiter. rate_limit_prefix = \"fides-\" # string # The number of requests from a single IP address allowed to hit an # endpoint within a rolling 60 second period. request_rate_limit = \"1000/minute\" # string # The list of scopes that are given to the root user. root_user_scopes = [] # array # The list of roles that are given to the root user. root_user_roles = [] # array # If set to True, the user interface will display a download button for # subject requests. subject_request_download_ui_enabled = false # boolean # If set to True, contributor and owner roles will be able to run test # privacy requests. dsr_testing_tools_enabled = false # boolean # The number of seconds that a pre-signed download URL when using S3 # storage will be valid. The default is equal to 5 days. subject_request_download_link_ttl_seconds = 432000 # integer # Either enables the collection of audit log resource data or bypasses # the middleware enable_audit_log_resource_middleware = false # boolean # The timeout in seconds for the transport socket # (``socket.settimeout``) bastion_server_ssh_timeout = 0.1 # number # The timeout in seconds for tunnel connection (open_channel timeout) bastion_server_ssh_tunnel_timeout = 10 # number #----------# #-- USER --# #--------------------------------------------------------------------# [user] # Configuration settings that apply to the current user as opposed to the entire application instance. # When set to true, prevents sending privacy-respecting anonymous # analytics data to Ethyca. analytics_opt_out = true # boolean # An arbitrary string used to encrypt the user data stored in the # database. Encryption is implemented using PGP. encryption_key = \"test_encryption_key\" # string # The username used to log into the Fides webserver. username = \"\" # string # The password used to log into the Fides webserver. password = \"\" # string #-----------------# #-- CREDENTIALS --# #--------------------------------------------------------------------# [credentials] # This is a special section that is used to store arbitrary key/value pairs to be used as credentials. # For more info, please visit: https://ethyca.github.io/fides/stable/config/#credentials","title":"Configuration"},{"location":"config/#configuration","text":"","title":"Configuration"},{"location":"config/#setting-configuration-values","text":"Fides can be configured in two different ways: either via a toml file or via environment variables. Both methods can be used simultaneously, with environment variables taking precedence over the toml file values.","title":"Setting Configuration Values"},{"location":"config/#using-a-configuration-file","text":"Fides will use the first config file it can read from the following locations. Listed in order of precedence they are: At the path specified using the config file argument passed through the CLI, i.e. fides -f <config_path> At the path specified by the FIDES__CONFIG_PATH environment variable In the current working directory it will check for a subdir .fides and a file within named fides.toml , i.e. ./.fides/fides.toml","title":"Using a Configuration File"},{"location":"config/#generating-a-config-file","text":"If you'd like to generate a new config file automatically using default values, run fides init . This will create the file at the default location of ./.fides/fides.toml","title":"Generating a Config File"},{"location":"config/#setting-values-via-environment-variables","text":"Fides follows a set pattern for configuration via environment variables. It looks for environment variables that start with FIDES followed by the config subsection name, followed by the key name, all separated with double underscores. In practice this would look like FIDES__<SUBSECTION>__<KEY> As a toml configuration value: 1 2 [database] host = config _ example As an environment variable: 1 EXPORT FIDES__DATABASE__HOST = config_example","title":"Setting Values Via Environment Variables"},{"location":"config/#viewing-your-configuration","text":"You can view the current configuration of your application via either the CLI or API.","title":"Viewing your configuration"},{"location":"config/#cli","text":"To view your application configuration via the CLI, run: 1 fides view config This will show all configuration variables, including sensitive ones. It is printed to the console as valid toml , so this can be copy/pasted as needed.","title":"CLI"},{"location":"config/#api","text":"To view your application configuration in the API, run: 1 GET /api/v1/config For security reasons, sensitive configuration values will not be shown here.","title":"API"},{"location":"config/#special-sections","text":"There are a few \"special\" configuration sections that behave in unique ways compared to the other sections. These sections will be addressed in the following documentation.","title":"Special Sections"},{"location":"config/#celery","text":"Fides uses Celery for asynchronous task management. To simplify deployments and remove the need for two different toml configuration files, it is possible to configure Celery via the Fides configuration file. Any valid configuration key/value pair for Celery can instead be added to the Fides toml configuration file and will automatically be passed through to the Celery deployment. Note that Fides will not validate any of these key/value pairs. See the above configuration file reference for an example of using celery configuration pass-through. For a full list of possible variable overrides, see the Celery configuration documentation . Example Celery Section 1 2 3 4 [celery] event_queue_prefix = \"fides_worker\" task_default_queue = \"fides\" task_always_eager = true","title":"Celery"},{"location":"config/#credentials","text":"The credentials section uses custom keys which can be referenced in specific commands that take the --credentials-id option. For example, a command that uses a credential might look like fides scan dataset db --credentials-id app_postgres . The credential object itself will be validated at the time of use depending on what type of credential is required. For instance if fides scan system okta is used, it will expect the object to contain orgUrl and token key/value pairs. In the case of a typical database like postgres, it will only expect a connection_string. The following is an example of what a credentials section might look like in a given deployment with various applications: Example Credentials Section 1 2 [credentials] app_postgres = { connection_string = \"postgresql+psycopg2://postgres:fides@fides-db:5432/fides\" }","title":"Credentials"},{"location":"config/#configuration-file-reference","text":"This following file is an autogenerated configuration reference file. It shows application defaults and is a valid toml file that can be used for configuration of Fides. fides.toml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 # Fides Configuration File # Additional Documentation at : https://ethyca.github.io/fides/stable/config/ #--------------# #-- ADMIN_UI --# #--------------------------------------------------------------------# [admin_ui] # Configuration settings for the Admin UI. # Toggle whether the Admin UI is served. enabled = true # boolean #------------# #-- CELERY --# #--------------------------------------------------------------------# [celery] # Configuration settings for Celery. Only a small subset can be configured through Fides env vars # The prefix to use for event receiver queue names event_queue_prefix = \"fides_worker\" # string # The name of the default queue if a message has no route or no custom # queue has been specified task_default_queue = \"fides\" # string # If true, tasks are executed locally instead of being sent to the # queue. If False, tasks are sent to the queue. task_always_eager = true # boolean #---------# #-- CLI --# #--------------------------------------------------------------------# [cli] # Configuration settings for the command-line application. # A fully anonymized unique identifier that is automatically generated # by the application. Used for anonymous analytics when opted-in. analytics_id = \"dc3e438ddaaf3cd7c251c877ce7b9e77\" # string # When set to True, disables functionality that requires making calls # to a Fides webserver. local_mode = false # boolean # The protocol used by the Fides webserver. server_protocol = \"http\" # string # The hostname of the Fides webserver. server_host = \"localhost\" # string # The port of the Fides webserver server_port = \"8080\" # string # The path of the Fides webserver server_path = \"/\" # string #-------------# #-- CONSENT --# #--------------------------------------------------------------------# [consent] # Configuration settings for Consent. # Toggle whether TCF is enabled. tcf_enabled = false # boolean # Toggle whether Google AC Mode is enabled. ac_enabled = false # boolean # Whether or not vendor purposes can be globally overridden. override_vendor_purposes = false # boolean #--------------# #-- DATABASE --# #--------------------------------------------------------------------# [database] # Configuration settings for the application database. # Automatically runs migrations on webserver startup. If set to # `false`, will require the user to run migrations manually via the CLI # or API. WARNING: Must be set to `true` for first-time startup. automigrate = true # boolean # Number of concurrent database connections Fides will use for API # requests. Note that the pool begins with no connections, but as they # are requested the connections are maintained and reused up to this # limit. api_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for API requests if the pool reaches the limit. These # overflow connections are discarded afterwards and not maintained. api_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. api_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. api_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. api_engine_keepalives_count = 5 # integer # The name of the application database. db = \"default_db\" # string # When set to True, initializes the database with sample data for # testing (Systems, Datasets, Connectors, etc.) Used by 'fides deploy' # to configure the sample project. load_samples = false # boolean # The password with which to login to the application database. password = \"defaultpassword\" # string # The port at which the application database will be accessible. port = \"5432\" # string # The hostname of the application database server. server = \"default-db\" # string # Number of concurrent database connections Fides will use for # executing privacy request tasks, either locally or on each worker. # Note that the pool begins with no connections, but as they are # requested the connections are maintained and reused up to this limit. task_engine_pool_size = 50 # integer # Number of additional 'overflow' concurrent database connections Fides # will use for executing privacy request tasks, either locally or on # each worker, if the pool reaches the limit. These overflow # connections are discarded afterwards and not maintained. task_engine_max_overflow = 50 # integer # Number of seconds of inactivity before the client sends a TCP # keepalive packet to verify the database connection is still alive. task_engine_keepalives_idle = 30 # integer # Number of seconds between TCP keepalive retries if the initial # keepalive packet receives no response. These are client-side retries. task_engine_keepalives_interval = 10 # integer # Maximum number of TCP keepalive retries before the client considers # the connection dead and closes it. task_engine_keepalives_count = 5 # integer # The database user with which to login to the application database. user = \"defaultuser\" # string # Additional connection parameters used when connecting to the # application database. params = {} # object #---------------# #-- EXECUTION --# #--------------------------------------------------------------------# [execution] # Configuration settings for DSR execution. # If set to True, only use UPDATE requests to mask data. If False, # Fides will use any defined DELETE or GDPR DELETE endpoints to remove # PII, which may extend beyond the specific data categories that # configured in your execution policy. masking_strict = true # boolean # The amount of time to wait for actions which delay privacy requests # (e.g., pre- and post-processing webhooks). privacy_request_delay_timeout = 3600 # integer # Whether privacy requests require explicit approval to execute. require_manual_request_approval = false # boolean # Whether privacy requests require user identity verification. subject_identity_verification_required = false # boolean # The backoff factor for retries, to space out repeated retries. task_retry_backoff = 1 # integer # The number of times a failed request will be retried. task_retry_count = 0 # integer # The delays between retries in seconds. task_retry_delay = 1 # integer # Allows the collection of custom privacy request fields from incoming # privacy requests. allow_custom_privacy_request_field_collection = false # boolean # Allows custom privacy request fields to be used in request execution. allow_custom_privacy_request_fields_in_request_execution = false # boolean # The number of seconds a request task should live. request_task_ttl = 604800 # integer # Seconds between polling for Privacy Requests that should change state state_polling_interval = 30 # integer # Temporary flag to switch to using DSR 3.0 to process your tasks. use_dsr_3_0 = false # boolean #-------------# #-- LOGGING --# #--------------------------------------------------------------------# [logging] # Configuration settings for application logging. # The output location for log files. Accepts any valid file path. If # left unset, log entries are printed to stdout and log files are not # produced. destination = \"\" # string # Force colored logs. Any value set via environment variables is # considered 'True'. colorize = false # boolean # The minimum log entry level to produce. Also accepts TRACE, DEBUG, # WARNING, ERROR, or CRITICAL (case insensitive). level = \"INFO\" # string # The format with which to produce log entries. If left unset, produces # log entries formatted using the internal custom formatter. Also # accepts 'JSON' (case insensitive). serialization = \"\" # string # If True, PII values will display unmasked in log output. This # variable should always be set to 'False' in production systems. log_pii = false # boolean #-------------------# #-- NOTIFICATIONS --# #--------------------------------------------------------------------# [notifications] # Configuration settings for Data Subject and/or Data Processor notifications. # When set to True, enables subject notifications upon privacy request # completion. send_request_completion_notification = false # boolean # When set to True, enables subject notifications upon privacy request # receipt. send_request_receipt_notification = false # boolean # When set to True, enables subject notifications upon privacy request # review. send_request_review_notification = false # boolean # When set to True, enables property specific messaging feature, # otherwise fall back on the messaging template type env flags set # above. enable_property_specific_messaging = false # boolean #-----------# #-- REDIS --# #--------------------------------------------------------------------# [redis] # Configuration settings for Redis. # Character set to use for Redis, defaults to 'utf8'. Not recommended # to change. charset = \"utf8\" # string # The application will use this index in the Redis cache to cache data. db_index = 0 # integer # Whether or not to automatically decode the values fetched from Redis. # Decodes using the `charset` configuration value. decode_responses = true # boolean # The number of seconds for which data will live in Redis before # automatically expiring. default_ttl_seconds = 604800 # integer # Whether the application's Redis cache should be enabled. Only set to # false for certain narrow uses of the application. enabled = true # boolean # The network address for the application Redis cache. host = \"redis\" # string # Sets TTL for cached identity verification code as part of subject # requests. identity_verification_code_ttl_seconds = 600 # integer # The password with which to login to the Redis cache. password = \"testpassword\" # string # The port at which the application cache will be accessible. port = 6379 # integer # Whether the application's connections to the cache should be # encrypted using TLS. ssl = false # boolean # If using TLS encryption, set this to 'required' if you wish to # enforce the Redis cache to provide a certificate. Note that not all # cache providers support this without setting ssl_ca_certs (e.g. AWS # Elasticache). ssl_cert_reqs = \"required\" # string # If using TLS encryption rooted with a custom Certificate Authority, # set this to the path of the CA certificate. ssl_ca_certs = \"\" # string # The user with which to login to the Redis cache. user = \"\" # string #--------------# #-- SECURITY --# #--------------------------------------------------------------------# [security] # Configuration settings for application security. # Length of desired encryption key when using Fides to generate a # random secure string used for AES encryption. aes_encryption_key_length = 16 # integer # Length of desired random byte str for the AES GCM encryption used # throughout Fides. aes_gcm_nonce_length = 12 # integer # The key used to sign Fides API access tokens. app_encryption_key = \"\" # string # Text encoding to use for the application. encoding = \"UTF-8\" # string # The default, `dev`, does not apply authentication to endpoints # typically used by the CLI. The other option, `prod`, requires # authentication for _all_ endpoints that may contain sensitive # information. env = \"prod\" # string # The number of times identity verification will be attempted before # raising an error. identity_verification_attempt_limit = 3 # integer # The value used to identify the Fides application root API client. oauth_root_client_id = \"\" # string # The secret value used to authenticate the Fides application root API # client. oauth_root_client_secret = \"\" # string # The time in minutes for which Fides API tokens will be valid. Default # value is equal to 8 days. oauth_access_token_expire_minutes = 11520 # integer # Sets desired length in bytes of generated client id used for oauth. oauth_client_id_length_bytes = 16 # integer # Sets desired length in bytes of generated client secret used for # oauth. oauth_client_secret_length_bytes = 16 # integer # The number of requests from a single IP address allowed to hit a # public endpoint within the specified time period public_request_rate_limit = \"2000/minute\" # string # The prefix given to keys in the Redis cache used by the rate limiter. rate_limit_prefix = \"fides-\" # string # The number of requests from a single IP address allowed to hit an # endpoint within a rolling 60 second period. request_rate_limit = \"1000/minute\" # string # The list of scopes that are given to the root user. root_user_scopes = [] # array # The list of roles that are given to the root user. root_user_roles = [] # array # If set to True, the user interface will display a download button for # subject requests. subject_request_download_ui_enabled = false # boolean # If set to True, contributor and owner roles will be able to run test # privacy requests. dsr_testing_tools_enabled = false # boolean # The number of seconds that a pre-signed download URL when using S3 # storage will be valid. The default is equal to 5 days. subject_request_download_link_ttl_seconds = 432000 # integer # Either enables the collection of audit log resource data or bypasses # the middleware enable_audit_log_resource_middleware = false # boolean # The timeout in seconds for the transport socket # (``socket.settimeout``) bastion_server_ssh_timeout = 0.1 # number # The timeout in seconds for tunnel connection (open_channel timeout) bastion_server_ssh_tunnel_timeout = 10 # number #----------# #-- USER --# #--------------------------------------------------------------------# [user] # Configuration settings that apply to the current user as opposed to the entire application instance. # When set to true, prevents sending privacy-respecting anonymous # analytics data to Ethyca. analytics_opt_out = true # boolean # An arbitrary string used to encrypt the user data stored in the # database. Encryption is implemented using PGP. encryption_key = \"test_encryption_key\" # string # The username used to log into the Fides webserver. username = \"\" # string # The password used to log into the Fides webserver. password = \"\" # string #-----------------# #-- CREDENTIALS --# #--------------------------------------------------------------------# [credentials] # This is a special section that is used to store arbitrary key/value pairs to be used as credentials. # For more info, please visit: https://ethyca.github.io/fides/stable/config/#credentials","title":"Configuration File Reference"},{"location":"development/code_style/","text":"Code Style General Docstrings Docstrings are required for every function, class, and method. No specific style is required or encouraged, as we expect that most of the relevant information can be gleaned from both the function signature's type-hints as well as descriptive parameter names. The docstring should serve to give additional context/flavour beyond that which can be gained from the code itself. Docstring Example 1 2 3 4 5 6 7 8 9 10 11 12 # Bad def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Execute an evaluation. \"\"\" # Good def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Check the stated constraints of each Privacy Policy's rules against each system's privacy declarations. \"\"\" Variable and parameter naming Variable and parameter names should be as self-describing as possible. Brevity is not a concern here. Here are some common examples for writing good self-documenting code: Single Letter Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 # Incorrect s = 726 # Correct elapsed_time_seconds = 726 # Incorrect for n in nodes : print ( n ) # Correct for node in nodes : print ( node ) Abbreviated Variable Names 1 2 3 4 5 6 7 8 # Incorrect r = requests . get ( url ) # Incorrect resp = reqeusts . get ( url ) # Correct response = requests . get ( url ) Type Ambiguous Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Incorrect food = [ \"apple\" , \"banana\" ] # Incorrect foods = [ \"apple\" , \"banana\" ] # Correct # Use type annotations if the name is somewhat ambiguous foods : List [ str ] = [ \"apple\" , \"banana\" ] # Correct # The type is contained in the name foods_list = [ \"apple\" , \"banana\" ] # Correct # Both of the above styles foods_list : List [ str ] = [ \"apple\" , \"banana\" ] Pre-commit hooks Fides includes a .pre-commit-config.yaml to facilitate running CI checks before pushing up to a PR. The pre-commit package is included in the dev-requirements.txt . Once that is installed, follow these steps to get up and running: pre-commit install - This is a one-time setup step to create the git pre-commit hooks. These pre-commit hooks will now run automatically. However you can also use pre-commit run to run them manually once all of your changes have been staged. NOTE : A Python interpreter must be available from wherever the git commands are being run, as this is required to run the pre-commit package. CI checks CI checks are stored as targets within the Noxfile, and can be run from the top-level fides directory with the following pattern: Pattern 1 nox -s <lowercased_name> Examples 1 2 3 nox -s black nox -s mypy nox -s xenon Additionally, there is a single command that will run all static check tools at once: nox -s static_checks Black formatting Fides' code is formatted using the black style. This style is checked in a CI step, and merges to master are prevented if code does not conform. A number of extensions are available for popular editors that will automatically apply black to your code. Pylint Fides' code is linted using pylint . Linter checks run as part of a CI step and merges to master are prevented if code does not conform. Mypy Fides' code is statically-typed using mypy . Type checking is validated as a CI step, and merges to master are prevented if code does not pass type checks. As a general rule, mypy typing requires all function arguments and return values to be annotated. Xenon Fides' code is checked for its cyclomatic-complexity by Xenon. If a single logical piece of code is deemed too complex, then a CI step will fail, at which point the focus should be on breaking up said complex function/method/class.","title":"Code Style"},{"location":"development/code_style/#code-style","text":"","title":"Code Style"},{"location":"development/code_style/#general","text":"","title":"General"},{"location":"development/code_style/#docstrings","text":"Docstrings are required for every function, class, and method. No specific style is required or encouraged, as we expect that most of the relevant information can be gleaned from both the function signature's type-hints as well as descriptive parameter names. The docstring should serve to give additional context/flavour beyond that which can be gained from the code itself. Docstring Example 1 2 3 4 5 6 7 8 9 10 11 12 # Bad def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Execute an evaluation. \"\"\" # Good def execute_evaluation ( taxonomy : Taxonomy ) -> Evaluation : \"\"\" Check the stated constraints of each Privacy Policy's rules against each system's privacy declarations. \"\"\"","title":"Docstrings"},{"location":"development/code_style/#variable-and-parameter-naming","text":"Variable and parameter names should be as self-describing as possible. Brevity is not a concern here. Here are some common examples for writing good self-documenting code: Single Letter Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 # Incorrect s = 726 # Correct elapsed_time_seconds = 726 # Incorrect for n in nodes : print ( n ) # Correct for node in nodes : print ( node ) Abbreviated Variable Names 1 2 3 4 5 6 7 8 # Incorrect r = requests . get ( url ) # Incorrect resp = reqeusts . get ( url ) # Correct response = requests . get ( url ) Type Ambiguous Variable Names 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # Incorrect food = [ \"apple\" , \"banana\" ] # Incorrect foods = [ \"apple\" , \"banana\" ] # Correct # Use type annotations if the name is somewhat ambiguous foods : List [ str ] = [ \"apple\" , \"banana\" ] # Correct # The type is contained in the name foods_list = [ \"apple\" , \"banana\" ] # Correct # Both of the above styles foods_list : List [ str ] = [ \"apple\" , \"banana\" ]","title":"Variable and parameter naming"},{"location":"development/code_style/#pre-commit-hooks","text":"Fides includes a .pre-commit-config.yaml to facilitate running CI checks before pushing up to a PR. The pre-commit package is included in the dev-requirements.txt . Once that is installed, follow these steps to get up and running: pre-commit install - This is a one-time setup step to create the git pre-commit hooks. These pre-commit hooks will now run automatically. However you can also use pre-commit run to run them manually once all of your changes have been staged. NOTE : A Python interpreter must be available from wherever the git commands are being run, as this is required to run the pre-commit package.","title":"Pre-commit hooks"},{"location":"development/code_style/#ci-checks","text":"CI checks are stored as targets within the Noxfile, and can be run from the top-level fides directory with the following pattern: Pattern 1 nox -s <lowercased_name> Examples 1 2 3 nox -s black nox -s mypy nox -s xenon Additionally, there is a single command that will run all static check tools at once: nox -s static_checks","title":"CI checks"},{"location":"development/code_style/#black-formatting","text":"Fides' code is formatted using the black style. This style is checked in a CI step, and merges to master are prevented if code does not conform. A number of extensions are available for popular editors that will automatically apply black to your code.","title":"Black formatting"},{"location":"development/code_style/#pylint","text":"Fides' code is linted using pylint . Linter checks run as part of a CI step and merges to master are prevented if code does not conform.","title":"Pylint"},{"location":"development/code_style/#mypy","text":"Fides' code is statically-typed using mypy . Type checking is validated as a CI step, and merges to master are prevented if code does not pass type checks. As a general rule, mypy typing requires all function arguments and return values to be annotated.","title":"Mypy"},{"location":"development/code_style/#xenon","text":"Fides' code is checked for its cyclomatic-complexity by Xenon. If a single logical piece of code is deemed too complex, then a CI step will fail, at which point the focus should be on breaking up said complex function/method/class.","title":"Xenon"},{"location":"development/developing_fides/","text":"Developing Fides The primary developer interface for Fides is via a tool called Nox. Nox is a pure-Python replacement for tools like make . You can read more about Nox in the official documentation here . \u26a0\ufe0f Warning If you install nox using pipx , you may run into issues with it not detecting your Python version correctly. Install it using pip instead. Additionally, much of what nox helps abstract is related to Docker. This usually makes it possible to troubleshoot potential nox issues by using various Docker commands directly. If you haven't already, read the Requirements Installation Guide to get up and running with the required tools and optimal configurations. Terminology For the purposes of this documentation, there is some Nox-specific terminology that is used and is helpful to understand before reading the rest of the guide. session - This is the equivalent of a single command, or a target in Make. They can be chained together arbitrarily, and the order of execution will be preserved. For example nox -s isort black posarg - This refers to a Positional Argument . These can be provided to any Nox command by putting -- at the end of a command followed by the argument that you would like to provide. For instance nox -s dev -- shell param - This is a specified value that is provided directly to a session. For instance nox -s \"isort(<param>)\" . Note that due to terminal limitations, the session + param must be wrapped in quotes for proper escaping. Additionally, if a session has multiple params but none are specific, all permutations of that session will be run. Sessions to Know While there are many sessions available in our nox setup, these are the ones that you are most likely to use regularly. This is intended as a brief introduction, as many of these commands will be explained further in specific sections below. Command Description nox This is the default session that runs when no other session is provided. Automatically opens this page. nox -l Provides a list of all available nox sessions. nox -s usage -- <command> Shows the full docstring for a single session. The name of the session is provided as a positional argument. Use this whenever you want to know more about a specific session's usage. nox -s dev Spins up the Fides webserver with all required infrastructure. nox -s shell Opens an interactive shell in a running Fides webserver container. nox -s build Builds and tags docker containers. nox -s clean Completely wipes out all Docker volumes, images, and caches across the entire machine. Note: This should only be used as a last resort! If you find yourself running this command often, there is probably an issue that needs to be addressed. nox -s teardown Spins down all of the Docker containers for the Fides project. Including the -- volumes posarg will also delete the application database data. Getting Started This section will run through the basics of getting everything up and running so that you can start making changes. Docker Given that the majority of commands rely on Docker images, the first step is going to be getting some Docker images built. This is handled by the build session. As an excercise, let's check the docs for the build session via the usage session: 1 nox -s usage -- build The simplest way to build everything is to run nox -s build . This will build all available Docker images used for development and testing. Additionally, to build only a specific image(s), run nox -s usage -- build to see what params have been documented. Running the Webserver Now that all of the potential images we'll need are built, it's time to spin up the webserver: nox -s dev Depending on your computer, this will take anywhere from ~30 seconds to ~2 minutes. The webserver will log all of its activity to that window which is useful for debugging and checking potential server-side errors. Warning When running nox -s dev , if you get an importlib.metadata.PackageNotFoundError: fides , it means that fides was not properly installed. Run nox -s dev -- shell , and then run pip install -e . You can verify Fides is installed with pip list | grep fides Opening a Shell Now that the webserver is up and running, a convenient way to interact with it as well as the Fides CLI is to open a shell directly into the running webserver container. Open a new terminal and run the following: nox -s shell With the shell open, we'll need to authenticate before we can start using the CLI. Run the following to authenticate the shell and get ready to run the CLI: fides user login With that done, we can do things like evaluations: fides evaluate Listing all resources of a type: fides ls system and more. Run fides -h to see the full list of commands offered by the CLI. Checking Your Changes Once you've made some changes, it's time to verify that they are working as expected. If you've made changes to the CLI, you can verify them directly using the shell method described here . If you've made an API change, there are a few different ways to verify your changes. The first and most simple is to go to localhost:8080/docs and verify that the changes you made show up as expected in the documentation. This is most useful when adding a new endpoint or changing a schema. To dig in even deeper, you can use the Authorize button at the top of the API docs page to login (credentials are available in the .fides/fides.toml config file). This will allow you to send requests, view responses, etc. Running Tests For a full walkthrough on testing, head over to the Testing page. Static Checks For the sake of simplicity, all of the typical pre-commit static checks are packaged into a single session: nox -s static_checks This installs and runs the various checks in their own virtual environment for maximum consistency. For more information about code style in Fides, check Code Style . Debugging Fides in VSCode This is a quick guide to show how VSCode can be used to debug Fides running locally in Docker. The general approach is to allow the local fides Docker Compose service to allow remote debugging connections, and to start a remote debugger from a host VSCode workspace. Setup Run Fides with Remote Debugging Enabled In order to accept incoming remote debugging connections, the fides Docker Compose service must be run with slight alterations. To enable this functionality, simply add the remote_debug flag to a nox command. For example: nox -s dev -- remote_debug or nox -s dev -- remote_debug postgres timescale With those commands, the fides Docker Compose service that's running the Fides server locally is able to accept incoming remote debugging connections. Note that, at this point, the remote_debug flag is not enabled for other nox sessions, e.g. fides_env , pytest_ops , etc. Attach a Remote Debugger to the Fides Server Now that the running Fides server can accept incoming remote debugging connections, you can attach a remote debugger from a local VSCode workspace to actively debug the server application. A launch configuration is included in the fides repo to facilitate this step. Open up the fides repo in a VSCode workspace Go to the Run and Debug view From the debugger dropdown list, select the Python debugger: Remote Attach Fides configuration Click the Start Debugging play button The remote debugger should now be attached to the Fides server! To confirm the debugger is attached, at least one RUNNING line item should appear in the CALL STACK window Debug! At this point, VSCode is ready to debug the running Fides server. Try setting breakpoints and hitting them by, e.g., making certain HTTP requests against the Fides server. This guide provides more information on how to use the VSCode Python debugger. Links Some relevant VSCode documentation for reference: https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection https://code.visualstudio.com/docs/python/python-tutorial#_configure-and-run-the-debugger Debugging Fides in IntelliJ IDEA Ultimate This guide will show how to use the IntelliJ debugger with Fides running in Docker. The setup for PyCharm Professional should be very similar. Prerequisites Intellij IDEA Ultimate or PyCharm Professional Docker plugin Python plugin (this is needed for Intellij) Docker Desktop Setup Connect to Docker daemon This step will allow the IDE to connect to Docker Desktop. Go to: Settings/Preferences -> Docker -> + Select Docker for \"your operating system\" See the screenshot below: Configure Python Remote Interpreter Define a Docker-based remote interpreter. Go to: File -> Project Structure... -> Platform Settings -> SDKs -> + Set Server to Docker Set Configuration files to .docker-compose.yml Set Python interpreter path to python After clicking OK the Remote Python Docker Compose should be listed as an SDK. See screenshots below: Run/Debug Configuration Set up a Run/Debug Configuration so that breakpoints can be hit in the f sourcecode. Go to: Run/Debug Configurations -> + -> Python To debug Fides, debug the <path on your machine>/src/fides/main.py script Make sure to select Use specified interpreter set the Remote Python Docker Compose (created in the previous section) Add FIDES__CONFIG_PATH=/fides to Environment variables See screenshot below: Hit a Breakpoint Now the IDE is ready to debug the source code. Click the debug button for main (setup in the previous section) . Try firing a http request to Fides from Postman or Curl and hit a break point. There is a postman collection in this repo: docs/fides/docs/development/postman/Fides.postman_collection.json Screenshot of hit breakpoint below: Links The information is this guide is largely based on these docs https://www.jetbrains.com/help/pycharm/using-docker-as-a-remote-interpreter.html https://www.jetbrains.com/help/idea/configuring-local-python-interpreters.html","title":"Developing Fides"},{"location":"development/developing_fides/#developing-fides","text":"The primary developer interface for Fides is via a tool called Nox. Nox is a pure-Python replacement for tools like make . You can read more about Nox in the official documentation here . \u26a0\ufe0f Warning If you install nox using pipx , you may run into issues with it not detecting your Python version correctly. Install it using pip instead. Additionally, much of what nox helps abstract is related to Docker. This usually makes it possible to troubleshoot potential nox issues by using various Docker commands directly. If you haven't already, read the Requirements Installation Guide to get up and running with the required tools and optimal configurations.","title":"Developing Fides"},{"location":"development/developing_fides/#terminology","text":"For the purposes of this documentation, there is some Nox-specific terminology that is used and is helpful to understand before reading the rest of the guide. session - This is the equivalent of a single command, or a target in Make. They can be chained together arbitrarily, and the order of execution will be preserved. For example nox -s isort black posarg - This refers to a Positional Argument . These can be provided to any Nox command by putting -- at the end of a command followed by the argument that you would like to provide. For instance nox -s dev -- shell param - This is a specified value that is provided directly to a session. For instance nox -s \"isort(<param>)\" . Note that due to terminal limitations, the session + param must be wrapped in quotes for proper escaping. Additionally, if a session has multiple params but none are specific, all permutations of that session will be run.","title":"Terminology"},{"location":"development/developing_fides/#sessions-to-know","text":"While there are many sessions available in our nox setup, these are the ones that you are most likely to use regularly. This is intended as a brief introduction, as many of these commands will be explained further in specific sections below. Command Description nox This is the default session that runs when no other session is provided. Automatically opens this page. nox -l Provides a list of all available nox sessions. nox -s usage -- <command> Shows the full docstring for a single session. The name of the session is provided as a positional argument. Use this whenever you want to know more about a specific session's usage. nox -s dev Spins up the Fides webserver with all required infrastructure. nox -s shell Opens an interactive shell in a running Fides webserver container. nox -s build Builds and tags docker containers. nox -s clean Completely wipes out all Docker volumes, images, and caches across the entire machine. Note: This should only be used as a last resort! If you find yourself running this command often, there is probably an issue that needs to be addressed. nox -s teardown Spins down all of the Docker containers for the Fides project. Including the -- volumes posarg will also delete the application database data.","title":"Sessions to Know"},{"location":"development/developing_fides/#getting-started","text":"This section will run through the basics of getting everything up and running so that you can start making changes.","title":"Getting Started"},{"location":"development/developing_fides/#docker","text":"Given that the majority of commands rely on Docker images, the first step is going to be getting some Docker images built. This is handled by the build session. As an excercise, let's check the docs for the build session via the usage session: 1 nox -s usage -- build The simplest way to build everything is to run nox -s build . This will build all available Docker images used for development and testing. Additionally, to build only a specific image(s), run nox -s usage -- build to see what params have been documented.","title":"Docker"},{"location":"development/developing_fides/#running-the-webserver","text":"Now that all of the potential images we'll need are built, it's time to spin up the webserver: nox -s dev Depending on your computer, this will take anywhere from ~30 seconds to ~2 minutes. The webserver will log all of its activity to that window which is useful for debugging and checking potential server-side errors. Warning When running nox -s dev , if you get an importlib.metadata.PackageNotFoundError: fides , it means that fides was not properly installed. Run nox -s dev -- shell , and then run pip install -e . You can verify Fides is installed with pip list | grep fides","title":"Running the Webserver"},{"location":"development/developing_fides/#opening-a-shell","text":"Now that the webserver is up and running, a convenient way to interact with it as well as the Fides CLI is to open a shell directly into the running webserver container. Open a new terminal and run the following: nox -s shell With the shell open, we'll need to authenticate before we can start using the CLI. Run the following to authenticate the shell and get ready to run the CLI: fides user login With that done, we can do things like evaluations: fides evaluate Listing all resources of a type: fides ls system and more. Run fides -h to see the full list of commands offered by the CLI.","title":"Opening a Shell"},{"location":"development/developing_fides/#checking-your-changes","text":"Once you've made some changes, it's time to verify that they are working as expected. If you've made changes to the CLI, you can verify them directly using the shell method described here . If you've made an API change, there are a few different ways to verify your changes. The first and most simple is to go to localhost:8080/docs and verify that the changes you made show up as expected in the documentation. This is most useful when adding a new endpoint or changing a schema. To dig in even deeper, you can use the Authorize button at the top of the API docs page to login (credentials are available in the .fides/fides.toml config file). This will allow you to send requests, view responses, etc.","title":"Checking Your Changes"},{"location":"development/developing_fides/#running-tests","text":"For a full walkthrough on testing, head over to the Testing page.","title":"Running Tests"},{"location":"development/developing_fides/#static-checks","text":"For the sake of simplicity, all of the typical pre-commit static checks are packaged into a single session: nox -s static_checks This installs and runs the various checks in their own virtual environment for maximum consistency. For more information about code style in Fides, check Code Style .","title":"Static Checks"},{"location":"development/developing_fides/#debugging-fides-in-vscode","text":"This is a quick guide to show how VSCode can be used to debug Fides running locally in Docker. The general approach is to allow the local fides Docker Compose service to allow remote debugging connections, and to start a remote debugger from a host VSCode workspace.","title":"Debugging Fides in VSCode"},{"location":"development/developing_fides/#setup","text":"","title":"Setup"},{"location":"development/developing_fides/#run-fides-with-remote-debugging-enabled","text":"In order to accept incoming remote debugging connections, the fides Docker Compose service must be run with slight alterations. To enable this functionality, simply add the remote_debug flag to a nox command. For example: nox -s dev -- remote_debug or nox -s dev -- remote_debug postgres timescale With those commands, the fides Docker Compose service that's running the Fides server locally is able to accept incoming remote debugging connections. Note that, at this point, the remote_debug flag is not enabled for other nox sessions, e.g. fides_env , pytest_ops , etc.","title":"Run Fides with Remote Debugging Enabled"},{"location":"development/developing_fides/#attach-a-remote-debugger-to-the-fides-server","text":"Now that the running Fides server can accept incoming remote debugging connections, you can attach a remote debugger from a local VSCode workspace to actively debug the server application. A launch configuration is included in the fides repo to facilitate this step. Open up the fides repo in a VSCode workspace Go to the Run and Debug view From the debugger dropdown list, select the Python debugger: Remote Attach Fides configuration Click the Start Debugging play button The remote debugger should now be attached to the Fides server! To confirm the debugger is attached, at least one RUNNING line item should appear in the CALL STACK window","title":"Attach a Remote Debugger to the Fides Server"},{"location":"development/developing_fides/#debug","text":"At this point, VSCode is ready to debug the running Fides server. Try setting breakpoints and hitting them by, e.g., making certain HTTP requests against the Fides server. This guide provides more information on how to use the VSCode Python debugger.","title":"Debug!"},{"location":"development/developing_fides/#links","text":"Some relevant VSCode documentation for reference: https://code.visualstudio.com/docs/python/debugging#_debugging-by-attaching-over-a-network-connection https://code.visualstudio.com/docs/python/python-tutorial#_configure-and-run-the-debugger","title":"Links"},{"location":"development/developing_fides/#debugging-fides-in-intellij-idea-ultimate","text":"This guide will show how to use the IntelliJ debugger with Fides running in Docker. The setup for PyCharm Professional should be very similar.","title":"Debugging Fides in IntelliJ IDEA Ultimate"},{"location":"development/developing_fides/#prerequisites","text":"Intellij IDEA Ultimate or PyCharm Professional Docker plugin Python plugin (this is needed for Intellij) Docker Desktop","title":"Prerequisites"},{"location":"development/developing_fides/#setup_1","text":"","title":"Setup"},{"location":"development/developing_fides/#connect-to-docker-daemon","text":"This step will allow the IDE to connect to Docker Desktop. Go to: Settings/Preferences -> Docker -> + Select Docker for \"your operating system\" See the screenshot below:","title":"Connect to Docker daemon"},{"location":"development/developing_fides/#configure-python-remote-interpreter","text":"Define a Docker-based remote interpreter. Go to: File -> Project Structure... -> Platform Settings -> SDKs -> + Set Server to Docker Set Configuration files to .docker-compose.yml Set Python interpreter path to python After clicking OK the Remote Python Docker Compose should be listed as an SDK. See screenshots below:","title":"Configure Python Remote Interpreter"},{"location":"development/developing_fides/#rundebug-configuration","text":"Set up a Run/Debug Configuration so that breakpoints can be hit in the f sourcecode. Go to: Run/Debug Configurations -> + -> Python To debug Fides, debug the <path on your machine>/src/fides/main.py script Make sure to select Use specified interpreter set the Remote Python Docker Compose (created in the previous section) Add FIDES__CONFIG_PATH=/fides to Environment variables See screenshot below:","title":"Run/Debug Configuration"},{"location":"development/developing_fides/#hit-a-breakpoint","text":"Now the IDE is ready to debug the source code. Click the debug button for main (setup in the previous section) . Try firing a http request to Fides from Postman or Curl and hit a break point. There is a postman collection in this repo: docs/fides/docs/development/postman/Fides.postman_collection.json Screenshot of hit breakpoint below:","title":"Hit a Breakpoint"},{"location":"development/developing_fides/#links_1","text":"The information is this guide is largely based on these docs https://www.jetbrains.com/help/pycharm/using-docker-as-a-remote-interpreter.html https://www.jetbrains.com/help/idea/configuring-local-python-interpreters.html","title":"Links"},{"location":"development/development_tips/","text":"Development Tips This page is dedicated to providing further context and information around specific implementation details such as code organization, running migrations and more. If you're looking for a general getting started guide, please see the Overview and Development Guide . API Endpoints API URLs We define API URLs for specific API versions as constants within fides.common.api.v1.urn_registry (where v1 can be substituted for that particular API version), then import those URLs into their specific API views. Since we are on the first version, there is no clear precedent set for overriding URLs between versions yet. The most likely change is that we'll override the APIRouter class instantiation with a different base path (ie. /api/v2 instead of /api/v1 ). For example: 1 2 PRIVACY_REQUEST = \"/privacy-request\" PRIVACY_REQUEST_DETAIL = \"/privacy-request/{privacy_request_id}\" would both resolve as /api/v1/privacy-request and /api/v1/privacy-request/{privacy_request_id} respectively. Database and Models The ORM -- SQLAlchemy SQLAlchemy is an Object Relational Mapper, allowing us to avoid writing direct database queries within our codebase, and access the database via Python code instead. The ORM provides an additional configuration layer allowing user-defined Python classes to be mapped to database tables and other constructs, as well as an object persistence mechanism known as the Session . Some common uses cases are listed below, for a more comprehensive guide see: https://docs.sqlalchemy.org/en/14/tutorial/index.html Adding models Database tables are defined with model classes. Model files should live in src/fides/api/models/ . Individual model classes must inherit from our custom base class at fides.api.db.base_class.Base to ensure uniformity within the database. Multiple models per file are encouraged so long as they fit the same logical delineation within the project. An example model declaration is added below. For a comprehensive guide see: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping You should also import your model in src/fides/api/db/base.py so it is visible for alembic. 1 2 3 4 5 6 7 class Book ( Base ): __tablename__ = 'book' id = Column ( Integer , primary_key = True ) name = Column ( String , index = True ) page_count = Column ( Integer , nullable = True ) author_id = Column ( Integer , ForeignKey ( \"author.id\" ), nullable = False ) When models are added to the project, we must then add them to the database in a recordable and repeatable fashion using migrations. Using the database via models Once you've added database tables via project models, you're ready to read, write, and update them via Python code. Some examples of common use cases here are listed below. Official documentation is here: https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query . Import our application's database session: from fides.api.db.session import get_db_session Instantiate the database interaction object: 1 2 SessionLocal = get_db_session ( config ) db = SessionLocal () Create a new row in a table: 1 2 3 4 5 6 7 8 9 db_obj = User ( email = \"admin@fides.app\" , full_name = \"Fides Admin\" , is_superuser = True , is_active = True , ) db . add ( db_obj ) db . commit () db . refresh ( db_obj ) Fetch all objects in a table: users = db.query(User).all() Fetch all objects in a table that meet some criteria: active_users = db.query(User).filter(User.is_active == True) Get a specific row in a table: user = db.query(User).get(User.email == \"admin@fides.app\") Update a specific row in a table: 1 2 3 4 user . email = \"updated@fides.app\" db . add ( user ) db . commit () db . refresh () Connecting to the database When you run nox -s dev , the database will spin up in a Docker container with port 5432 exposed on localhost. You can connect to it using the credentials found in .fides.toml , e.g. Hostname: localhost Port: 5432 Username: see database.user in .fides.toml Password: see database.password in .fides.toml Alembic migrations Some common Alembic commands are listed below. For a comprehensive guide see: https://alembic.sqlalchemy.org/en/latest/tutorial.html . The commands will need to be run inside a shell on your Docker containers, which can be opened with nox -s dev -- shell . In the /src/fides/api/alembic directory: Migrate your database to the latest state: alembic upgrade head Merge heads (for when you have conflicting heads from a merge/rebase): alembic merge heads Get revision id of previous migration: alembic current Automatically generate a new migration: alembic revision --autogenerate -m \"<a message describing your changes>\" Create a new migration file to manually fill out: alembic revision -m \"<a message describing your changes>\" Migrate your database to a specific state alembic upgrade <revision-id> or alembic downgrade <revision-id> , (or if you want to be smart alembic upgrade <revision-id> || alembic downgrade <revision-id> is handy when you don't know whether the target revision is an upgrade or downgrade) NB. You can find the revision-id inside each migration file in alembic/versions/ on line 3 next to Revision ID: ... When working on a PR with a migration, ensure that down_revision in the generated migration file correctly references the previous migration before submitting/merging the PR. Exception Handling Our preference for exception handling is by overriding the nearest sensible error, for example: 1 2 3 4 5 6 class SomeException ( ValueError ): \"a docstring\" def some_method (): raise SomeException ( \"a message\" ) General debugging -- pdb The project uses pdb for debugging as a dev-requirement . You can set breakpoints with pdb in much the same way you'd set them using debugger in JavaScript. Insert import pdb; pdb.set_trace() into the line where you want the breakpoint to set, then run your Python code. Docker As a last resort you may need to tear everything down in Docker and rebuild. The following commands will achieve that, but be warned that rebuild times can be long! 1 nox -s clean Warning If you find yourself feeling the need to run this command regularly, open an issue or slack a member of the dev team as it is not expected that this will need to be run regularly. Performance and Benchmarking The following are a few options we have for monitoring and benchmarking application performance: docker stats - Running this command will show you the CPU and Memory usage of your containers. This is very handy for quickly checking the memory footprint of an image while running. drill - This is a CLI tool used for load-testing applications. It requires Rust and OpenSSL. This is used in CI to continually benchmark performance. nox -s performance_tests - This is a convenient combination of the prior two tools that is used in CI but also possible to use locally. profile-request - When in dev_mode , Adding profile-request: true to any request header will tell the server to profile the request and send back a text response containing the profile data, instead of returning the typical JSON response. This allows arbitrary profiling of any endpoint or feature.","title":"Development Tips"},{"location":"development/development_tips/#development-tips","text":"This page is dedicated to providing further context and information around specific implementation details such as code organization, running migrations and more. If you're looking for a general getting started guide, please see the Overview and Development Guide .","title":"Development Tips"},{"location":"development/development_tips/#api-endpoints","text":"","title":"API Endpoints"},{"location":"development/development_tips/#api-urls","text":"We define API URLs for specific API versions as constants within fides.common.api.v1.urn_registry (where v1 can be substituted for that particular API version), then import those URLs into their specific API views. Since we are on the first version, there is no clear precedent set for overriding URLs between versions yet. The most likely change is that we'll override the APIRouter class instantiation with a different base path (ie. /api/v2 instead of /api/v1 ). For example: 1 2 PRIVACY_REQUEST = \"/privacy-request\" PRIVACY_REQUEST_DETAIL = \"/privacy-request/{privacy_request_id}\" would both resolve as /api/v1/privacy-request and /api/v1/privacy-request/{privacy_request_id} respectively.","title":"API URLs"},{"location":"development/development_tips/#database-and-models","text":"","title":"Database and Models"},{"location":"development/development_tips/#the-orm-sqlalchemy","text":"SQLAlchemy is an Object Relational Mapper, allowing us to avoid writing direct database queries within our codebase, and access the database via Python code instead. The ORM provides an additional configuration layer allowing user-defined Python classes to be mapped to database tables and other constructs, as well as an object persistence mechanism known as the Session . Some common uses cases are listed below, for a more comprehensive guide see: https://docs.sqlalchemy.org/en/14/tutorial/index.html","title":"The ORM -- SQLAlchemy"},{"location":"development/development_tips/#adding-models","text":"Database tables are defined with model classes. Model files should live in src/fides/api/models/ . Individual model classes must inherit from our custom base class at fides.api.db.base_class.Base to ensure uniformity within the database. Multiple models per file are encouraged so long as they fit the same logical delineation within the project. An example model declaration is added below. For a comprehensive guide see: https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#declarative-mapping You should also import your model in src/fides/api/db/base.py so it is visible for alembic. 1 2 3 4 5 6 7 class Book ( Base ): __tablename__ = 'book' id = Column ( Integer , primary_key = True ) name = Column ( String , index = True ) page_count = Column ( Integer , nullable = True ) author_id = Column ( Integer , ForeignKey ( \"author.id\" ), nullable = False ) When models are added to the project, we must then add them to the database in a recordable and repeatable fashion using migrations.","title":"Adding models"},{"location":"development/development_tips/#using-the-database-via-models","text":"Once you've added database tables via project models, you're ready to read, write, and update them via Python code. Some examples of common use cases here are listed below. Official documentation is here: https://docs.sqlalchemy.org/en/14/orm/query.html#sqlalchemy.orm.Query . Import our application's database session: from fides.api.db.session import get_db_session Instantiate the database interaction object: 1 2 SessionLocal = get_db_session ( config ) db = SessionLocal () Create a new row in a table: 1 2 3 4 5 6 7 8 9 db_obj = User ( email = \"admin@fides.app\" , full_name = \"Fides Admin\" , is_superuser = True , is_active = True , ) db . add ( db_obj ) db . commit () db . refresh ( db_obj ) Fetch all objects in a table: users = db.query(User).all() Fetch all objects in a table that meet some criteria: active_users = db.query(User).filter(User.is_active == True) Get a specific row in a table: user = db.query(User).get(User.email == \"admin@fides.app\") Update a specific row in a table: 1 2 3 4 user . email = \"updated@fides.app\" db . add ( user ) db . commit () db . refresh ()","title":"Using the database via models"},{"location":"development/development_tips/#connecting-to-the-database","text":"When you run nox -s dev , the database will spin up in a Docker container with port 5432 exposed on localhost. You can connect to it using the credentials found in .fides.toml , e.g. Hostname: localhost Port: 5432 Username: see database.user in .fides.toml Password: see database.password in .fides.toml","title":"Connecting to the database"},{"location":"development/development_tips/#alembic-migrations","text":"Some common Alembic commands are listed below. For a comprehensive guide see: https://alembic.sqlalchemy.org/en/latest/tutorial.html . The commands will need to be run inside a shell on your Docker containers, which can be opened with nox -s dev -- shell . In the /src/fides/api/alembic directory: Migrate your database to the latest state: alembic upgrade head Merge heads (for when you have conflicting heads from a merge/rebase): alembic merge heads Get revision id of previous migration: alembic current Automatically generate a new migration: alembic revision --autogenerate -m \"<a message describing your changes>\" Create a new migration file to manually fill out: alembic revision -m \"<a message describing your changes>\" Migrate your database to a specific state alembic upgrade <revision-id> or alembic downgrade <revision-id> , (or if you want to be smart alembic upgrade <revision-id> || alembic downgrade <revision-id> is handy when you don't know whether the target revision is an upgrade or downgrade) NB. You can find the revision-id inside each migration file in alembic/versions/ on line 3 next to Revision ID: ... When working on a PR with a migration, ensure that down_revision in the generated migration file correctly references the previous migration before submitting/merging the PR.","title":"Alembic migrations"},{"location":"development/development_tips/#exception-handling","text":"Our preference for exception handling is by overriding the nearest sensible error, for example: 1 2 3 4 5 6 class SomeException ( ValueError ): \"a docstring\" def some_method (): raise SomeException ( \"a message\" )","title":"Exception Handling"},{"location":"development/development_tips/#general-debugging-pdb","text":"The project uses pdb for debugging as a dev-requirement . You can set breakpoints with pdb in much the same way you'd set them using debugger in JavaScript. Insert import pdb; pdb.set_trace() into the line where you want the breakpoint to set, then run your Python code.","title":"General debugging -- pdb"},{"location":"development/development_tips/#docker","text":"As a last resort you may need to tear everything down in Docker and rebuild. The following commands will achieve that, but be warned that rebuild times can be long! 1 nox -s clean Warning If you find yourself feeling the need to run this command regularly, open an issue or slack a member of the dev team as it is not expected that this will need to be run regularly.","title":"Docker"},{"location":"development/development_tips/#performance-and-benchmarking","text":"The following are a few options we have for monitoring and benchmarking application performance: docker stats - Running this command will show you the CPU and Memory usage of your containers. This is very handy for quickly checking the memory footprint of an image while running. drill - This is a CLI tool used for load-testing applications. It requires Rust and OpenSSL. This is used in CI to continually benchmark performance. nox -s performance_tests - This is a convenient combination of the prior two tools that is used in CI but also possible to use locally. profile-request - When in dev_mode , Adding profile-request: true to any request header will tell the server to profile the request and send back a text response containing the profile data, instead of returning the typical JSON response. This allows arbitrary profiling of any endpoint or feature.","title":"Performance and Benchmarking"},{"location":"development/documentation/","text":"Documentation Primary documentation for Fides now lives at https://docs.ethyca.com , however autogenerated documentation as well as developer documentation is still maintained and hosted within the Fides project repo . Previewing Docs Locally Documentation (including both developer documentation as well as API references) are built and deployed with every merge to Fides' main branch. nox -s docs_serve You'll see a status update as the docs build, and then an announcement that they are available at localhost:8080/fides . The docs will hot-reload as changes are made, so there is no need to rerun the command whenever a change is made.","title":"Documentation"},{"location":"development/documentation/#documentation","text":"Primary documentation for Fides now lives at https://docs.ethyca.com , however autogenerated documentation as well as developer documentation is still maintained and hosted within the Fides project repo .","title":"Documentation"},{"location":"development/documentation/#previewing-docs-locally","text":"Documentation (including both developer documentation as well as API references) are built and deployed with every merge to Fides' main branch. nox -s docs_serve You'll see a status update as the docs build, and then an announcement that they are available at localhost:8080/fides . The docs will hot-reload as changes are made, so there is no need to rerun the command whenever a change is made.","title":"Previewing Docs Locally"},{"location":"development/fideslog/","text":"Analytics Fides includes an implementation of fideslog to provide Ethyca with an understanding of user interactions with fides tooling. All collected analytics are anonymized, and only used in either product roadmap determination, or as insight into product adoption. Information collected by fideslog is received via HTTPs request, stored in a secure database, and never shared with third parties unless required by law. More information on use, implementation, and configuration can be found in the fideslog repository . Collected Data Fideslog collects information on instances of Fides by recording internal events. Using Fides may result in sending any or all of the following analytics data to Ethyca: Parameter Description docker If fides is run in a docker container. event The type of analytics event - currently, either a server start or endpoint call . event_created The time of the event. endpoint The endpoint accessed. status_code The status result of the request. error Error information, if any. Disabling Fideslog To opt out of analytics, set either the following fides environment variable or .toml configuration variable to True . Variable Default Use analytics_opt_out False Include in your fides.toml file. FIDES__USER__ANALYTICS_OPT_OUT False Include in your environment variables.","title":"User Analytics"},{"location":"development/fideslog/#analytics","text":"Fides includes an implementation of fideslog to provide Ethyca with an understanding of user interactions with fides tooling. All collected analytics are anonymized, and only used in either product roadmap determination, or as insight into product adoption. Information collected by fideslog is received via HTTPs request, stored in a secure database, and never shared with third parties unless required by law. More information on use, implementation, and configuration can be found in the fideslog repository .","title":"Analytics"},{"location":"development/fideslog/#collected-data","text":"Fideslog collects information on instances of Fides by recording internal events. Using Fides may result in sending any or all of the following analytics data to Ethyca: Parameter Description docker If fides is run in a docker container. event The type of analytics event - currently, either a server start or endpoint call . event_created The time of the event. endpoint The endpoint accessed. status_code The status result of the request. error Error information, if any.","title":"Collected Data"},{"location":"development/fideslog/#disabling-fideslog","text":"To opt out of analytics, set either the following fides environment variable or .toml configuration variable to True . Variable Default Use analytics_opt_out False Include in your fides.toml file. FIDES__USER__ANALYTICS_OPT_OUT False Include in your environment variables.","title":"Disabling Fideslog"},{"location":"development/overview/","text":"Development Overview Thank you for your interest in contributing to Fides! This section of our documentation is designed to help you become familiar with how we work, the standards we apply, and how to ensure your contribution is successful. If you're stuck, don't be shy about asking for help on GitHub . Getting Started The first step is to clone the Fides repo for development if you haven't already: 1 git clone https://github.com/ethyca/fides Once that's complete, there are a few different tools to install for get everything up and running. Requirements The primary requirements for contributing to Fides are Docker and Python . The download links as well as minimum required versions are provided below NOTE: Installing these requirements via Brew or other package managers is highly discouraged. Please use the provided links for a more stable experience. Docker Desktop (version 20.10.11 or later) - Docker Desktop Download Page Python (version 3.9 through 3.10) - To simplify the installation experience and create a more stable Python installation that can be managed indepently, we recommend installing Python via Anaconda. The installer for Anaconda can be found here . Warning Mac Users : Apple's ARM silicon (M-series chips, i.e. M1, M2, M2 Max, etc.) have a few extra requirements to get Fides running Additional Requirements for Mac Users (ARM-based) Install FreeTDS and OpenSSL 1 brew install freetds openssl Add the following to your run commands (i.e. .zshrc ), updating any path/versions to match yours 1 2 export LDFLAGS = \"-L/opt/homebrew/Cellar/freetds/1.3.18/lib -L/opt/homebrew/Cellar/openssl@1.1/1.1.1u/lib\" export CFLAGS = \"-I/opt/homebrew/Cellar/freetds/1.3.18/include\" Optional Requirements for Mac Users (ARM-based) Explicitly set resource allocations in Docker Desktop CPUs: 4 Memory:8GB Disk Limit: 200GB Now that those are installed, the final step is to install the Python dev requirements for the Fides project. We recommend doing this in a virtual environment. 1 pip install -r dev-requirements.txt Write your code We have no doubt you can write amazing code! However, we want to help you ensure your code follows the style and patterns of Fides and has the highest chance possible to be accepted. Many projects describe code style and documentation as a suggestion; in Fides it's a CI-checked requirement. To learn how to develop new features or fix bugs, see the developing Fides page. To learn how to style your code, see the style guide . To learn how to document your code, see the docs guide . To learn how to test your code, see the tests guide . To learn what format your PR should follow, make sure to follow the pull request guidelines . Submit your code In order to submit code to Fides, please: Fork the Fides repository Create a new branch on your fork Open a Pull Request once your work is ready for review Once automated tests have passed, a maintainer will review your PR and provide feedback on any changes it requires to be approved. Once approved, your PR will be merged into Fides and included in a future release. Congratulations You're a Fides contributor - welcome to the team! \ud83c\udf89","title":"Overview"},{"location":"development/overview/#development-overview","text":"Thank you for your interest in contributing to Fides! This section of our documentation is designed to help you become familiar with how we work, the standards we apply, and how to ensure your contribution is successful. If you're stuck, don't be shy about asking for help on GitHub .","title":"Development Overview"},{"location":"development/overview/#getting-started","text":"The first step is to clone the Fides repo for development if you haven't already: 1 git clone https://github.com/ethyca/fides Once that's complete, there are a few different tools to install for get everything up and running.","title":"Getting Started"},{"location":"development/overview/#requirements","text":"The primary requirements for contributing to Fides are Docker and Python . The download links as well as minimum required versions are provided below NOTE: Installing these requirements via Brew or other package managers is highly discouraged. Please use the provided links for a more stable experience. Docker Desktop (version 20.10.11 or later) - Docker Desktop Download Page Python (version 3.9 through 3.10) - To simplify the installation experience and create a more stable Python installation that can be managed indepently, we recommend installing Python via Anaconda. The installer for Anaconda can be found here . Warning Mac Users : Apple's ARM silicon (M-series chips, i.e. M1, M2, M2 Max, etc.) have a few extra requirements to get Fides running","title":"Requirements"},{"location":"development/overview/#additional-requirements-for-mac-users-arm-based","text":"Install FreeTDS and OpenSSL 1 brew install freetds openssl Add the following to your run commands (i.e. .zshrc ), updating any path/versions to match yours 1 2 export LDFLAGS = \"-L/opt/homebrew/Cellar/freetds/1.3.18/lib -L/opt/homebrew/Cellar/openssl@1.1/1.1.1u/lib\" export CFLAGS = \"-I/opt/homebrew/Cellar/freetds/1.3.18/include\"","title":"Additional Requirements for Mac Users (ARM-based)"},{"location":"development/overview/#optional-requirements-for-mac-users-arm-based","text":"Explicitly set resource allocations in Docker Desktop CPUs: 4 Memory:8GB Disk Limit: 200GB Now that those are installed, the final step is to install the Python dev requirements for the Fides project. We recommend doing this in a virtual environment. 1 pip install -r dev-requirements.txt","title":"Optional Requirements for Mac Users (ARM-based)"},{"location":"development/overview/#write-your-code","text":"We have no doubt you can write amazing code! However, we want to help you ensure your code follows the style and patterns of Fides and has the highest chance possible to be accepted. Many projects describe code style and documentation as a suggestion; in Fides it's a CI-checked requirement. To learn how to develop new features or fix bugs, see the developing Fides page. To learn how to style your code, see the style guide . To learn how to document your code, see the docs guide . To learn how to test your code, see the tests guide . To learn what format your PR should follow, make sure to follow the pull request guidelines .","title":"Write your code"},{"location":"development/overview/#submit-your-code","text":"In order to submit code to Fides, please: Fork the Fides repository Create a new branch on your fork Open a Pull Request once your work is ready for review Once automated tests have passed, a maintainer will review your PR and provide feedback on any changes it requires to be approved. Once approved, your PR will be merged into Fides and included in a future release.","title":"Submit your code"},{"location":"development/overview/#congratulations","text":"You're a Fides contributor - welcome to the team! \ud83c\udf89","title":"Congratulations"},{"location":"development/pull_requests/","text":"Pull Requests Pull requests are the primary unit of work within the Fides project. All code changes are expected to be submitted via a PR with the following requirements: Completely fill out the provided pull request template. PRs should be in a draft state until they are ready for a final review + merge. A non-draft PR signals to the community that the author believes the PR is ready to ship! If you need early feedback on your PR, feel free to ask for it directly while your PR is in a draft state. Make sure that all checks are passing, and all boxes have been checked before taking the PR out of a draft state. PR reviews require other people to spend their time, so please be courteous and double check your work before passing it to a reviewer. If you're unsure about a potential feature implementation or there is anything else that needs discussing, feel free to ask for an early review/feedback in the comments of the draft PR. PRs should be focused, reflecting a single logical change or feature. Generally, it is better to have multiple smaller PRs than one big one. This reduces the merge risk and shortens review time.","title":"Pull Requests"},{"location":"development/pull_requests/#pull-requests","text":"Pull requests are the primary unit of work within the Fides project. All code changes are expected to be submitted via a PR with the following requirements: Completely fill out the provided pull request template. PRs should be in a draft state until they are ready for a final review + merge. A non-draft PR signals to the community that the author believes the PR is ready to ship! If you need early feedback on your PR, feel free to ask for it directly while your PR is in a draft state. Make sure that all checks are passing, and all boxes have been checked before taking the PR out of a draft state. PR reviews require other people to spend their time, so please be courteous and double check your work before passing it to a reviewer. If you're unsure about a potential feature implementation or there is anything else that needs discussing, feel free to ask for an early review/feedback in the comments of the draft PR. PRs should be focused, reflecting a single logical change or feature. Generally, it is better to have multiple smaller PRs than one big one. This reduces the merge risk and shortens review time.","title":"Pull Requests"},{"location":"development/releases/","text":"Releases Versioning Fides uses semantic versioning. Due to the rapid development of the project, some minor versions may also contain minor breaking changes. The best practice is to always pin versions, and carefully test before bumping to a new version. Patch versions will never cause breaking changes, and are only used to hotfix critical bugs. Release schedule Fides does not follow a set release schedule, and instead ships versions based on the addition of features and functionality. Each release, with the exception of hotfixes, contains at least one substantial new feature. Branching Fides uses continuous delivery with a single main branch. All code changes are merged into this branch. When it comes times to prepare for a new release, a release branch is created for stability and thoroughly tested. When releasing, a new tag is created on the release branch and the release process proceeds automatically. In the case of patches, a branch is created from the relevant tag. Commits are then cherry-picked into this branch, and a new patch version tag is created. Release Steps We use GitHub\u2019s release feature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use a CHANGELOG.md to mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows: Major and Minor Open a PR that is titled the version of the release (i.e. 1.6.0 ) Rename the Unreleased section of CHANGELOG.md to the new version number and put a date next to it Update the compare links for both the new version and for the new Unreleased section Once approved, merge the PR Create a new release, ensuring that the last PR to get merged is the aforementioned CHANGELOG.md update PR Add the new version as the tag (i.e. 1.6.0 ) Make the title the version with a v in front of it (i.e. v1.6.0 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Patch It may be necessary for a patch release to contain only select commits to the main branch since the last major or minor release. To create a release with only the desired changes, follow the steps below: Checkout the most recent release's tag To fetch the most recent tag's name, run: 1 2 3 4 # fides on main git describe --abbrev = 0 --tags #=> 1.2.3 To checkout the most recent tag, run: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #fides on main git checkout 1 .2.3 #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Tip This can be combined into a single command: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # fides on main git checkout $( git describe --abbrev = 0 --tags ) #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Create a new branch from the HEAD commit of the most recent release's tag, called release-v<tag> 1 2 3 4 # fides on tags/1.2.3 git checkout -b release-v1.2.4 #=> Switched to a new branch 'release-v1.2.4' If the changes to be included in the patch release are contained in one or more unmerged pull requests, change the base branch of the pull request(s) to the release branch created in the previous step Once approved, merge the pull request(s) into the release branch Create a new branch off of the release branch by running: 1 2 3 4 # fides on release-v1.2.4 git checkout -b prepare-release-v1.2.4 #=> Switched to a new branch 'prepare-release-v1.2.4' Optional: Incorporate any additional specific changes required for the patch release by running: 1 2 # fides on prepare-release-v1.2.4 git cherry-pick <commit>... Copy the Unreleased section of CHANGELOG.md and paste above the release being patched Rename Unreleased to the new version number and put a date next to it Cut and paste the documented changes that are now included in the patch release to the correct section Commit these changes Open a pull request to incorporate any cherry-picked commits and the CHANGELOG.md changes into the release branch Set the base branch of this pull request to the release branch Once approved, merge the pull request into the release branch Create a new release from the release branch Add the new version as the tag (i.e. 1.2.4 ) Title the release with the version number, prefixed with a v (i.e. v1.2.4 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Merge the new release tag into main Warning Pushing commits (including merge commits) to the main branch requires admin-level repository permissions. Checkout the main branch, and update the local repository: 1 2 3 4 git checkout main #=> Switched to branch 'main'... git pull Merge the new release tag into main : 1 git merge tags/1.2.4 Handle any merge conflicts, and push to the remote main branch Release Checklist The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check. This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step. Additionally, there is a robust Release Process page available in Confluence ( internal only ). Pre-Release Steps General From the release branch, confirm the following: [ ] Quickstart works: nox -s quickstart (verify you can complete the interactive prompts from the command-line) [ ] Test environment works: nox -s \"fides_env(test)\" (verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver) [ ] Have Roger run a QATouch automation run Next, run the following checks via the test environment: API [ ] Verify that the generated API docs are correct @ http://localhost:8080/docs CLI Run these from within the test environment shell: [ ] git reset --hard - Note: This is required for the pull command to work [ ] fides user login [ ] fides push src/fides/data/sample_project/sample_resources/ [ ] fides pull src/fides/data/sample_project/sample_resources/ [ ] fides evaluate src/fides/data/sample_project/sample_resources/ [ ] fides generate dataset db --credentials-id app_postgres test.yml - Note: Because the filesystem isn't mounted, the new file will only show up within the container [ ] fides scan dataset db --credentials-id app_postgres Privacy Center [ ] Every navigation button works [ ] DSR submission succeeds [ ] Consent request submission succeeds Admin UI [ ] Every navigation button works [ ] DSR approval succeeds [ ] DSR execution succeeds User Permissions [ ] Verify user creation [ ] Verify a Viewer can view all systems [ ] Verify a Data Steward can edit systems they are assigned Documentation [ ] Verify that the CHANGELOG is formatted correctly and clean up verbiage where needed [ ] Verify that the CHANGELOG is representative of the actual changes :warning: Note that any updates that need to be made to the CHANGELOG should not be commited directly to the release branch. Instead, they should be committed on a branch off of main and then PR'd and merged into main , before being cherry-picked over to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and main . Publishing the release When publishing the release, be sure to include the following sections in the release description: [ ] ## Release Pull Request section that includes a link back to the release PR (i.e., this one!) for tracking purposes [ ] ## QA Touch Test Run section that includes a link to the QATouch test run (QA team should provide this) Post-Release Steps [ ] Verify the ethyca-fides release is published to PyPi: https://pypi.org/project/ethyca-fides/#history [ ] Verify the fides release is published to DockerHub: https://hub.docker.com/r/ethyca/fides [ ] Verify the fides-privacy-center release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-privacy-center [ ] Verify the fides-sample-app release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-sample-app [ ] Smoke test the PyPi & DockerHub releases: [ ] Create a fresh venv with python3 -m venv 2_12_0_venv [ ] Activate the venv source 2_12_0_venv/bin/activate [ ] pip install ethyca-fides [ ] fides deploy up [ ] Announce the release!","title":"Releases"},{"location":"development/releases/#releases","text":"","title":"Releases"},{"location":"development/releases/#versioning","text":"Fides uses semantic versioning. Due to the rapid development of the project, some minor versions may also contain minor breaking changes. The best practice is to always pin versions, and carefully test before bumping to a new version. Patch versions will never cause breaking changes, and are only used to hotfix critical bugs.","title":"Versioning"},{"location":"development/releases/#release-schedule","text":"Fides does not follow a set release schedule, and instead ships versions based on the addition of features and functionality. Each release, with the exception of hotfixes, contains at least one substantial new feature.","title":"Release schedule"},{"location":"development/releases/#branching","text":"Fides uses continuous delivery with a single main branch. All code changes are merged into this branch. When it comes times to prepare for a new release, a release branch is created for stability and thoroughly tested. When releasing, a new tag is created on the release branch and the release process proceeds automatically. In the case of patches, a branch is created from the relevant tag. Commits are then cherry-picked into this branch, and a new patch version tag is created.","title":"Branching"},{"location":"development/releases/#release-steps","text":"We use GitHub\u2019s release feature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use a CHANGELOG.md to mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows:","title":"Release Steps"},{"location":"development/releases/#major-and-minor","text":"Open a PR that is titled the version of the release (i.e. 1.6.0 ) Rename the Unreleased section of CHANGELOG.md to the new version number and put a date next to it Update the compare links for both the new version and for the new Unreleased section Once approved, merge the PR Create a new release, ensuring that the last PR to get merged is the aforementioned CHANGELOG.md update PR Add the new version as the tag (i.e. 1.6.0 ) Make the title the version with a v in front of it (i.e. v1.6.0 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release","title":"Major and Minor"},{"location":"development/releases/#patch","text":"It may be necessary for a patch release to contain only select commits to the main branch since the last major or minor release. To create a release with only the desired changes, follow the steps below: Checkout the most recent release's tag To fetch the most recent tag's name, run: 1 2 3 4 # fides on main git describe --abbrev = 0 --tags #=> 1.2.3 To checkout the most recent tag, run: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #fides on main git checkout 1 .2.3 #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Tip This can be combined into a single command: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # fides on main git checkout $( git describe --abbrev = 0 --tags ) #=> Note: switching to '1.2.3'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by switching back to a branch. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -c with the switch command. Example: # # git switch -c <new-branch-name> # # Or undo this operation with: # # git switch - # # Turn off this advice by setting config variable advice.detachedHead to false # # HEAD is now at 0123abcd Commit Message Create a new branch from the HEAD commit of the most recent release's tag, called release-v<tag> 1 2 3 4 # fides on tags/1.2.3 git checkout -b release-v1.2.4 #=> Switched to a new branch 'release-v1.2.4' If the changes to be included in the patch release are contained in one or more unmerged pull requests, change the base branch of the pull request(s) to the release branch created in the previous step Once approved, merge the pull request(s) into the release branch Create a new branch off of the release branch by running: 1 2 3 4 # fides on release-v1.2.4 git checkout -b prepare-release-v1.2.4 #=> Switched to a new branch 'prepare-release-v1.2.4' Optional: Incorporate any additional specific changes required for the patch release by running: 1 2 # fides on prepare-release-v1.2.4 git cherry-pick <commit>... Copy the Unreleased section of CHANGELOG.md and paste above the release being patched Rename Unreleased to the new version number and put a date next to it Cut and paste the documented changes that are now included in the patch release to the correct section Commit these changes Open a pull request to incorporate any cherry-picked commits and the CHANGELOG.md changes into the release branch Set the base branch of this pull request to the release branch Once approved, merge the pull request into the release branch Create a new release from the release branch Add the new version as the tag (i.e. 1.2.4 ) Title the release with the version number, prefixed with a v (i.e. v1.2.4 ) Add a link to the CHANGELOG.md Auto-populate the release notes Publish the release Merge the new release tag into main Warning Pushing commits (including merge commits) to the main branch requires admin-level repository permissions. Checkout the main branch, and update the local repository: 1 2 3 4 git checkout main #=> Switched to branch 'main'... git pull Merge the new release tag into main : 1 git merge tags/1.2.4 Handle any merge conflicts, and push to the remote main branch","title":"Patch"},{"location":"development/releases/#release-checklist","text":"The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check. This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step. Additionally, there is a robust Release Process page available in Confluence ( internal only ).","title":"Release Checklist"},{"location":"development/releases/#pre-release-steps","text":"","title":"Pre-Release Steps"},{"location":"development/releases/#general","text":"From the release branch, confirm the following: [ ] Quickstart works: nox -s quickstart (verify you can complete the interactive prompts from the command-line) [ ] Test environment works: nox -s \"fides_env(test)\" (verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver) [ ] Have Roger run a QATouch automation run Next, run the following checks via the test environment:","title":"General"},{"location":"development/releases/#api","text":"[ ] Verify that the generated API docs are correct @ http://localhost:8080/docs","title":"API"},{"location":"development/releases/#cli","text":"Run these from within the test environment shell: [ ] git reset --hard - Note: This is required for the pull command to work [ ] fides user login [ ] fides push src/fides/data/sample_project/sample_resources/ [ ] fides pull src/fides/data/sample_project/sample_resources/ [ ] fides evaluate src/fides/data/sample_project/sample_resources/ [ ] fides generate dataset db --credentials-id app_postgres test.yml - Note: Because the filesystem isn't mounted, the new file will only show up within the container [ ] fides scan dataset db --credentials-id app_postgres","title":"CLI"},{"location":"development/releases/#privacy-center","text":"[ ] Every navigation button works [ ] DSR submission succeeds [ ] Consent request submission succeeds","title":"Privacy Center"},{"location":"development/releases/#admin-ui","text":"[ ] Every navigation button works [ ] DSR approval succeeds [ ] DSR execution succeeds","title":"Admin UI"},{"location":"development/releases/#user-permissions","text":"[ ] Verify user creation [ ] Verify a Viewer can view all systems [ ] Verify a Data Steward can edit systems they are assigned","title":"User Permissions"},{"location":"development/releases/#documentation","text":"[ ] Verify that the CHANGELOG is formatted correctly and clean up verbiage where needed [ ] Verify that the CHANGELOG is representative of the actual changes :warning: Note that any updates that need to be made to the CHANGELOG should not be commited directly to the release branch. Instead, they should be committed on a branch off of main and then PR'd and merged into main , before being cherry-picked over to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and main .","title":"Documentation"},{"location":"development/releases/#publishing-the-release","text":"When publishing the release, be sure to include the following sections in the release description: [ ] ## Release Pull Request section that includes a link back to the release PR (i.e., this one!) for tracking purposes [ ] ## QA Touch Test Run section that includes a link to the QATouch test run (QA team should provide this)","title":"Publishing the release"},{"location":"development/releases/#post-release-steps","text":"[ ] Verify the ethyca-fides release is published to PyPi: https://pypi.org/project/ethyca-fides/#history [ ] Verify the fides release is published to DockerHub: https://hub.docker.com/r/ethyca/fides [ ] Verify the fides-privacy-center release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-privacy-center [ ] Verify the fides-sample-app release is published to DockerHub: https://hub.docker.com/r/ethyca/fides-sample-app [ ] Smoke test the PyPi & DockerHub releases: [ ] Create a fresh venv with python3 -m venv 2_12_0_venv [ ] Activate the venv source 2_12_0_venv/bin/activate [ ] pip install ethyca-fides [ ] fides deploy up [ ] Announce the release!","title":"Post-Release Steps"},{"location":"development/testing/","text":"Testing Fides loves tests! There are a few important reasons to write tests: Make sure your code works Tests ensure that your code does the thing you intend it to do. If you have a function that adds two numbers, you'll want to test that it does, in fact, return their sum. If behavior depends on a configuration setting, ensure that changing that setting changes the behavior. In short, if you wrote a line of code, you should test that line works as expected. Make sure your code doesn't not work It may seem silly, but another important reason to write tests is to ensure that your code behaves as expected even when it's broken . This is especially important for a project like Fides, which is focused on helping engineers when something unexpected happens to their code. For example, you could write tests about what you expect to happen if your function is called with incorrect (or no) arguments, or to ensure that any errors are properly trapped and handled. Tests are documentation Ultimately, your tests are the best documentation for your code. Another developer should be able to look at your tests and understand what your code does, how to invoke it, and what edge cases it contains. Therefore, try to write short, self-explanatory tests with descriptive titles. Help future developers As Fides grows, your code will be reused in more and more places, by developers who may not be familiar with the details of your implementation. Therefore, your tests are an opportunity to ensure that your code is used correctly in the future. For example, if your code needs to be used in a certain way, or expects a certain configuration, or is always expected to return a certain output, or has any other details that might impact its ability to be used in the framework, write a test for it! At minimum, you'll help a future developer understand that you consciously chose to design your code a certain way. Writing tests Fides' tests are stored in the tests directory. Tests should have descriptive names that make it clear what you're testing. If necessary, add a docstring or comment to explain why you're testing this specific thing. 1 2 3 4 5 6 7 # Good test name def test_dry_evaluate_system_fail ( server_url , resources_dict ): ... # Bad test name def test_dry_evaluate (): ... Fides has a few pytest fixtures available for testing; see conftest.py for details. Integration tests vs. mocked tests Generally, tests that include mocking are discouraged. Mocking can create a false sense of security and obfuscate possible errors in the code that only present themselves when integration tested. Running tests Given the relative complexity of the setup around Fides and reliance on Docker, test commands should usually be run in a shell or via Nox sessions. The following subsections describe how to execute both. Running Tests in a Shell As described in Developing Fides , we'll be running these tests from within a shell. As a reminder, spinning up Fides and opening a shell requires the following commands: nox -s dev Once the webserver is running from the previous command, open a new terminal and run nox -s shell You're now ready to start testing! Invoking Pytest Fides uses pytest for unit testing. Let's collect all of the available tests to verify pytest is working as expected: 1 2 # Collects all available tests without running anything pytest --collect-only Running specific tests To run a subset of tests, provide a filename or directory; to match a specific test name, use the -k flag: 1 2 # Run all tests in the tests/ctl/ directory that contain the word \"api\" in their name pytest tests/ctl/ -k api The --sw flag will exit pytest the first time it encounters an error; subsequent runs with the same flag will skip any tests that succeeded and run the failed test first. For more information on available Pytest invocation options, see the documentation here . Excluding tests Some tests also test integration with external services like Snowflake which require both internet access and authentication credentials. It is possible to skip these tests by excluding tests with the external mark. 1 2 # Run all tests except for external ones pytest -m \"not external\" This is far from the only mark used in the test suite however. To see a full list, they are all documented in the [tool.pytest] section of the pyproject.toml . Running Test Suites via Nox To run tests in a more robust and repeatable way, Nox also has extensive commands for running tests packaged with various marks and infrastructure. However, it is important to note that these commands are not designed for rapid iteration and TDD in mind, but instead for maximum reproducability. To run tests in a more TDD-style, see the section Running Tests in a Shell . Additionally, these are the exact same Nox sessions that are run in CI. Thus if you are seeing CI failures and are trying to reproduce or remediate them, it is recommended to run those failing tests locally via these Nox sessions as the results will generally always be the same. Building the Test Image The Nox test sessions assume that all of the required images have already been built. To build the Fides image used for testing, run the following command: 1 nox -s \"build(test)\" Once that is complete, you're ready to start running test sessions. Test Sessions The following table describes each pytest-related session: Session (with Param) Mark(s) Test Path Requires Credentials? Description pytest(ctl-unit) unit tests/ctl No Simplest set of ctl tests Should generally avoid the webserver but not guaranteed. pytest(ctl-integration) integration tests/ctl No Tests that are known to require the webserver. pytest(ctl-not-external) not external tests/ctl No Tests unit/integration but without touching external resources. pytest(ctl-external) external tests/ctl Yes Tests that require external resources such as Snowflake or BigQuery. pytest(ops-unit) not integration and not integration_external and not integration_saas tests/ops No As there is no \"unit\" tag within the ops tests, it is instead achieved via numerous \"not\" marks. pytest(ops-integration) N/A N/A No This is a special test case, as the handling of test running is done by run_infrastructure.py . More information and logic can be found there. pytest(ops-external-datastores) integration_external tests/ops Yes Runs tests that connect to external datastores such as Snowflake. pytest(ops-saas) integration_saas tests/ops Yes Runs tests related to the connectors code. Spins up additional local resources and connects to outside resources. pytest(lib) N/A tests/lib No Test lib module functionality. pytest(nox) N/A tests/nox No Tests functionality related to the nox session. Note For additional information, you can view the source file test_setup_nox.py that contains all of the code that runs these tests. Testing Environment Quickstart Use nox -s \"fides_env(test)\" to launch the test environment Read the terminal output for details Customize Fides ENV variables by editing .env Overview To facilitate thorough manual testing of the application, there is a comprehensive testing environment that can be set up via a single nox command: nox -s \"fides_env(test)\" . This test environment includes: Fides Server Fides Admin UI Fides Postgres Database & Redis Cache Sample \"Cookie House\" Application Test Postgres Database Test Redis Database Sample Resources Sample Connectors etc. This test environment is exactly the same environment that users can launch themselves using fides deploy up , and you can find all the configuration and settings in src/fides/data/sample_project . Configuration There are two ways to configure the fides server and CLI: Editing the ENV file in the project root: .env Editing the TOML file in the sample project files: src/fides/data/sample_project/fides.toml The .env file is safest to add secrets and local customizations, since it is .gitignore 'd and will not be accidentally committed to version control. The fides.toml file should be used for configurations that should be present for all users testing out the application. Advanced Usage The environment will work \"out of the box\", but can also be configured to enable other features like S3 storage, email notifications, etc. To configure these, you'll need to edit the .env file and provide some secrets - see example.env for what is supported. Automated Cypress E2E Tests The test environment is also used to run automated end-to-end (E2E) tests via Cypress. Use nox -s e2e_test to run this locally.","title":"Testing"},{"location":"development/testing/#testing","text":"Fides loves tests! There are a few important reasons to write tests: Make sure your code works Tests ensure that your code does the thing you intend it to do. If you have a function that adds two numbers, you'll want to test that it does, in fact, return their sum. If behavior depends on a configuration setting, ensure that changing that setting changes the behavior. In short, if you wrote a line of code, you should test that line works as expected. Make sure your code doesn't not work It may seem silly, but another important reason to write tests is to ensure that your code behaves as expected even when it's broken . This is especially important for a project like Fides, which is focused on helping engineers when something unexpected happens to their code. For example, you could write tests about what you expect to happen if your function is called with incorrect (or no) arguments, or to ensure that any errors are properly trapped and handled. Tests are documentation Ultimately, your tests are the best documentation for your code. Another developer should be able to look at your tests and understand what your code does, how to invoke it, and what edge cases it contains. Therefore, try to write short, self-explanatory tests with descriptive titles. Help future developers As Fides grows, your code will be reused in more and more places, by developers who may not be familiar with the details of your implementation. Therefore, your tests are an opportunity to ensure that your code is used correctly in the future. For example, if your code needs to be used in a certain way, or expects a certain configuration, or is always expected to return a certain output, or has any other details that might impact its ability to be used in the framework, write a test for it! At minimum, you'll help a future developer understand that you consciously chose to design your code a certain way.","title":"Testing"},{"location":"development/testing/#writing-tests","text":"Fides' tests are stored in the tests directory. Tests should have descriptive names that make it clear what you're testing. If necessary, add a docstring or comment to explain why you're testing this specific thing. 1 2 3 4 5 6 7 # Good test name def test_dry_evaluate_system_fail ( server_url , resources_dict ): ... # Bad test name def test_dry_evaluate (): ... Fides has a few pytest fixtures available for testing; see conftest.py for details.","title":"Writing tests"},{"location":"development/testing/#integration-tests-vs-mocked-tests","text":"Generally, tests that include mocking are discouraged. Mocking can create a false sense of security and obfuscate possible errors in the code that only present themselves when integration tested.","title":"Integration tests vs. mocked tests"},{"location":"development/testing/#running-tests","text":"Given the relative complexity of the setup around Fides and reliance on Docker, test commands should usually be run in a shell or via Nox sessions. The following subsections describe how to execute both.","title":"Running tests"},{"location":"development/testing/#running-tests-in-a-shell","text":"As described in Developing Fides , we'll be running these tests from within a shell. As a reminder, spinning up Fides and opening a shell requires the following commands: nox -s dev Once the webserver is running from the previous command, open a new terminal and run nox -s shell You're now ready to start testing!","title":"Running Tests in a Shell"},{"location":"development/testing/#invoking-pytest","text":"Fides uses pytest for unit testing. Let's collect all of the available tests to verify pytest is working as expected: 1 2 # Collects all available tests without running anything pytest --collect-only","title":"Invoking Pytest"},{"location":"development/testing/#running-specific-tests","text":"To run a subset of tests, provide a filename or directory; to match a specific test name, use the -k flag: 1 2 # Run all tests in the tests/ctl/ directory that contain the word \"api\" in their name pytest tests/ctl/ -k api The --sw flag will exit pytest the first time it encounters an error; subsequent runs with the same flag will skip any tests that succeeded and run the failed test first. For more information on available Pytest invocation options, see the documentation here .","title":"Running specific tests"},{"location":"development/testing/#excluding-tests","text":"Some tests also test integration with external services like Snowflake which require both internet access and authentication credentials. It is possible to skip these tests by excluding tests with the external mark. 1 2 # Run all tests except for external ones pytest -m \"not external\" This is far from the only mark used in the test suite however. To see a full list, they are all documented in the [tool.pytest] section of the pyproject.toml .","title":"Excluding tests"},{"location":"development/testing/#running-test-suites-via-nox","text":"To run tests in a more robust and repeatable way, Nox also has extensive commands for running tests packaged with various marks and infrastructure. However, it is important to note that these commands are not designed for rapid iteration and TDD in mind, but instead for maximum reproducability. To run tests in a more TDD-style, see the section Running Tests in a Shell . Additionally, these are the exact same Nox sessions that are run in CI. Thus if you are seeing CI failures and are trying to reproduce or remediate them, it is recommended to run those failing tests locally via these Nox sessions as the results will generally always be the same.","title":"Running Test Suites via Nox"},{"location":"development/testing/#building-the-test-image","text":"The Nox test sessions assume that all of the required images have already been built. To build the Fides image used for testing, run the following command: 1 nox -s \"build(test)\" Once that is complete, you're ready to start running test sessions.","title":"Building the Test Image"},{"location":"development/testing/#test-sessions","text":"The following table describes each pytest-related session: Session (with Param) Mark(s) Test Path Requires Credentials? Description pytest(ctl-unit) unit tests/ctl No Simplest set of ctl tests Should generally avoid the webserver but not guaranteed. pytest(ctl-integration) integration tests/ctl No Tests that are known to require the webserver. pytest(ctl-not-external) not external tests/ctl No Tests unit/integration but without touching external resources. pytest(ctl-external) external tests/ctl Yes Tests that require external resources such as Snowflake or BigQuery. pytest(ops-unit) not integration and not integration_external and not integration_saas tests/ops No As there is no \"unit\" tag within the ops tests, it is instead achieved via numerous \"not\" marks. pytest(ops-integration) N/A N/A No This is a special test case, as the handling of test running is done by run_infrastructure.py . More information and logic can be found there. pytest(ops-external-datastores) integration_external tests/ops Yes Runs tests that connect to external datastores such as Snowflake. pytest(ops-saas) integration_saas tests/ops Yes Runs tests related to the connectors code. Spins up additional local resources and connects to outside resources. pytest(lib) N/A tests/lib No Test lib module functionality. pytest(nox) N/A tests/nox No Tests functionality related to the nox session. Note For additional information, you can view the source file test_setup_nox.py that contains all of the code that runs these tests.","title":"Test Sessions"},{"location":"development/testing/#testing-environment","text":"","title":"Testing Environment"},{"location":"development/testing/#quickstart","text":"Use nox -s \"fides_env(test)\" to launch the test environment Read the terminal output for details Customize Fides ENV variables by editing .env","title":"Quickstart"},{"location":"development/testing/#overview","text":"To facilitate thorough manual testing of the application, there is a comprehensive testing environment that can be set up via a single nox command: nox -s \"fides_env(test)\" . This test environment includes: Fides Server Fides Admin UI Fides Postgres Database & Redis Cache Sample \"Cookie House\" Application Test Postgres Database Test Redis Database Sample Resources Sample Connectors etc. This test environment is exactly the same environment that users can launch themselves using fides deploy up , and you can find all the configuration and settings in src/fides/data/sample_project .","title":"Overview"},{"location":"development/testing/#configuration","text":"There are two ways to configure the fides server and CLI: Editing the ENV file in the project root: .env Editing the TOML file in the sample project files: src/fides/data/sample_project/fides.toml The .env file is safest to add secrets and local customizations, since it is .gitignore 'd and will not be accidentally committed to version control. The fides.toml file should be used for configurations that should be present for all users testing out the application.","title":"Configuration"},{"location":"development/testing/#advanced-usage","text":"The environment will work \"out of the box\", but can also be configured to enable other features like S3 storage, email notifications, etc. To configure these, you'll need to edit the .env file and provide some secrets - see example.env for what is supported.","title":"Advanced Usage"},{"location":"development/testing/#automated-cypress-e2e-tests","text":"The test environment is also used to run automated end-to-end (E2E) tests via Cypress. Use nox -s e2e_test to run this locally.","title":"Automated Cypress E2E Tests"},{"location":"development/update_erd_diagram/","text":"Updating database diagram If you make updates to the Fides application database, you should update the DB Architecture diagram in the documentation. Connect DBeaver to our app DB container DBeaver > Database > New Database Connection > PostgreSQL Add configuration details Right-click on postgres connection > Create > Other Select ER Diagram, Click Next Drill down to Postgres > app > Schemas > public and click the checkbox. Add a name to your ER Diagram Click Finish Drag and drop tables so they are less messy. File > Save As (app_database.png) Replace img/app_database.png with the new file","title":"Updating the Database Diagram"},{"location":"development/update_erd_diagram/#updating-database-diagram","text":"If you make updates to the Fides application database, you should update the DB Architecture diagram in the documentation. Connect DBeaver to our app DB container DBeaver > Database > New Database Connection > PostgreSQL Add configuration details Right-click on postgres connection > Create > Other Select ER Diagram, Click Next Drill down to Postgres > app > Schemas > public and click the checkbox. Add a name to your ER Diagram Click Finish Drag and drop tables so they are less messy. File > Save As (app_database.png) Replace img/app_database.png with the new file","title":"Updating database diagram"},{"location":"development/postman/using_postman/","text":"Using the Fides postman collection A minimal Postman collection is included to assist in setting up your privacy request configurations, and in executing example access and erasure requests against mock external databases. Loading the collection Get Postman Postman > File > Import Upload the Fides collection found in docs/fides/docs/postman/Fides.postman_collection.json Click on the imported fidesops collection in the left pane, and then find Variables to edit the fidesops collection variables. Some variables are populated for you, and some will be added in this guide's next steps. Add your oauth_root_client_id and oauth_root_client_secret under CURRENT VALUE . fidesadmin and fidesadminsecret are default configurations for testing, found in your fides.toml . Add the appropriate values for your instance if they differ. Important: Click Save ! Bring up local servers and mock databases Run nox -s dev -- <datastore> in your terminal. This brings up the Fides server and the list of datastores specified, i.e. nox -s dev -- postgres mongodb . These mock datastores are pre-populated with test data to represent your datastores. The following list of requests is kept in the Minimum API calls to create an Access Privacy Request folder. Some of the returned data will need to be saved as additional variables for use in other steps. Saving Authentication variables Click on the Get Root Client Token request, and click Send to send a POST request to Fides to create a root token. Copy the access_token returned in the response body, and paste it as the Current Value of root_client_token in Fides' variables. Important: Click Save ! Similarly, click on Create Client , and click Send to send a POST request to Fides to create a new client. Copy the client_id and client_secret and paste into Current Value slots in Fides variables and click \"Save\". Finally, click on the Get Client Token request, and click Send to send another POST request to Fides. This will create a token for the client made in the previous step. If you click on Body , you can see that the client_id and client_secret have been added as form data for you. Save the returned token under client_token in the Fides variables. The client_token will be automatically passed into the rest of your requests as the Bearer Token. Building out remaining privacy request configuration Run through the remaining requests in the Minimum API calls to create an Access Privacy Request folder. Because variables are automatically being populated for you, you should be able to click on each request, clicking Send for each one. Inspect the Body of each request to see what is sent to Fides: Specify where your data is going: SEND Create/Update Storage - Local Storage Config - Sets up a local folder for uploading your privacy request results (local testing only) Configure what data you care about, and what to do with it: SEND Create/Update Policies - Creates a Policy to handle Privacy Requests SEND Create/Update Access Rule - Defines an access Rule on the previous Policy, which specifies results will be uploaded to the configured local storage SEND Create/Update Rule Targets - Specify a RuleTarget that says to will return data that has been marked as having a user data category Create ConnectionConfigs, and add connection secrets for the postgres_example and mongodb_example mock databases: SEND Create/Update Connection Configs: Postgres SEND Create/Update Connection Configs: Mongo SEND Update Connection Secrets: Postgres SEND Update Connection Secrets: Mongo Add annotations of the Postgres and Mongo datastores: SEND Create/Update Postgres Dataset SEND Create/Update Dataset Mongo API calls to additional supported datastores (MsSQL, MySQL) are in separate folders within the collection. Run a privacy request You have now completed the basic configuration required to create an Access Request. SEND Create Access Privacy Requests If \"succeeded\", note the \"id\" that is returned. Succeeded means the privacy request has been created and is pending, not that its execution is complete. Check your local fides_uploads folder, configured earlier, to see access request results. This is run asynchronously, so it may take a few moments to complete. This particular request should have retrieved data from both the postgres_example and mongodb_example databases with the user data_category Next steps Check out other requests in the collection! The Calls to create an Erasure Request folder walks you through configuring a separate erasure policy, and executing an erasure request. Note that these erasure requests will mask data in your connected datastores ( postgres_example and mongo_example here. If you connect your own live databases, data may be deleted. Happy experimenting!","title":"Using Postman"},{"location":"development/postman/using_postman/#using-the-fides-postman-collection","text":"A minimal Postman collection is included to assist in setting up your privacy request configurations, and in executing example access and erasure requests against mock external databases.","title":"Using the Fides postman collection"},{"location":"development/postman/using_postman/#loading-the-collection","text":"Get Postman Postman > File > Import Upload the Fides collection found in docs/fides/docs/postman/Fides.postman_collection.json Click on the imported fidesops collection in the left pane, and then find Variables to edit the fidesops collection variables. Some variables are populated for you, and some will be added in this guide's next steps. Add your oauth_root_client_id and oauth_root_client_secret under CURRENT VALUE . fidesadmin and fidesadminsecret are default configurations for testing, found in your fides.toml . Add the appropriate values for your instance if they differ. Important: Click Save !","title":"Loading the collection"},{"location":"development/postman/using_postman/#bring-up-local-servers-and-mock-databases","text":"Run nox -s dev -- <datastore> in your terminal. This brings up the Fides server and the list of datastores specified, i.e. nox -s dev -- postgres mongodb . These mock datastores are pre-populated with test data to represent your datastores. The following list of requests is kept in the Minimum API calls to create an Access Privacy Request folder. Some of the returned data will need to be saved as additional variables for use in other steps.","title":"Bring up local servers and mock databases"},{"location":"development/postman/using_postman/#saving-authentication-variables","text":"Click on the Get Root Client Token request, and click Send to send a POST request to Fides to create a root token. Copy the access_token returned in the response body, and paste it as the Current Value of root_client_token in Fides' variables. Important: Click Save ! Similarly, click on Create Client , and click Send to send a POST request to Fides to create a new client. Copy the client_id and client_secret and paste into Current Value slots in Fides variables and click \"Save\". Finally, click on the Get Client Token request, and click Send to send another POST request to Fides. This will create a token for the client made in the previous step. If you click on Body , you can see that the client_id and client_secret have been added as form data for you. Save the returned token under client_token in the Fides variables. The client_token will be automatically passed into the rest of your requests as the Bearer Token.","title":"Saving Authentication variables"},{"location":"development/postman/using_postman/#building-out-remaining-privacy-request-configuration","text":"Run through the remaining requests in the Minimum API calls to create an Access Privacy Request folder. Because variables are automatically being populated for you, you should be able to click on each request, clicking Send for each one. Inspect the Body of each request to see what is sent to Fides: Specify where your data is going: SEND Create/Update Storage - Local Storage Config - Sets up a local folder for uploading your privacy request results (local testing only) Configure what data you care about, and what to do with it: SEND Create/Update Policies - Creates a Policy to handle Privacy Requests SEND Create/Update Access Rule - Defines an access Rule on the previous Policy, which specifies results will be uploaded to the configured local storage SEND Create/Update Rule Targets - Specify a RuleTarget that says to will return data that has been marked as having a user data category Create ConnectionConfigs, and add connection secrets for the postgres_example and mongodb_example mock databases: SEND Create/Update Connection Configs: Postgres SEND Create/Update Connection Configs: Mongo SEND Update Connection Secrets: Postgres SEND Update Connection Secrets: Mongo Add annotations of the Postgres and Mongo datastores: SEND Create/Update Postgres Dataset SEND Create/Update Dataset Mongo API calls to additional supported datastores (MsSQL, MySQL) are in separate folders within the collection.","title":"Building out remaining privacy request configuration"},{"location":"development/postman/using_postman/#run-a-privacy-request","text":"You have now completed the basic configuration required to create an Access Request. SEND Create Access Privacy Requests If \"succeeded\", note the \"id\" that is returned. Succeeded means the privacy request has been created and is pending, not that its execution is complete. Check your local fides_uploads folder, configured earlier, to see access request results. This is run asynchronously, so it may take a few moments to complete. This particular request should have retrieved data from both the postgres_example and mongodb_example databases with the user data_category","title":"Run a privacy request"},{"location":"development/postman/using_postman/#next-steps","text":"Check out other requests in the collection! The Calls to create an Erasure Request folder walks you through configuring a separate erasure policy, and executing an erasure request. Note that these erasure requests will mask data in your connected datastores ( postgres_example and mongo_example here. If you connect your own live databases, data may be deleted. Happy experimenting!","title":"Next steps"},{"location":"development/ui/admin_ui/","text":"Admin UI Accessing the Control Panel From the root fides directory, run the following: 1 2 3 4 cd clients npm install cd admin-ui turbo run dev This will navigate you to the admin-ui directory, and start the development environment. Visit http://localhost:3000/ in your browser, and provide your user credentials to log in. Backend deployment Fides automatically serves a version of the UI when running nox -s dev . To deploy a full version of the UI from a backend, run the following from the root fidesops directory: 1 2 3 4 cd clients npm install cd admin-ui turbo run prod-export This will build and place the Admin UI files into a location accessible by backend fidesops deployments. To test the UI, run nox -s dev from the root directory, and visit http://0.0.0.0:8080/index.html .","title":"Admin UI"},{"location":"development/ui/admin_ui/#admin-ui","text":"","title":"Admin UI"},{"location":"development/ui/admin_ui/#accessing-the-control-panel","text":"From the root fides directory, run the following: 1 2 3 4 cd clients npm install cd admin-ui turbo run dev This will navigate you to the admin-ui directory, and start the development environment. Visit http://localhost:3000/ in your browser, and provide your user credentials to log in.","title":"Accessing the Control Panel"},{"location":"development/ui/admin_ui/#backend-deployment","text":"Fides automatically serves a version of the UI when running nox -s dev . To deploy a full version of the UI from a backend, run the following from the root fidesops directory: 1 2 3 4 cd clients npm install cd admin-ui turbo run prod-export This will build and place the Admin UI files into a location accessible by backend fidesops deployments. To test the UI, run nox -s dev from the root directory, and visit http://0.0.0.0:8080/index.html .","title":"Backend deployment"},{"location":"development/ui/overview/","text":"UI Development Overview The /clients directory houses all front-end packages and shared code amongst clients, and also includes e2e tests. Prerequisites To run and develop the Fides UI components locally, you'll need to do the following: Clone the Fides repository Install Node.js Globally install Turbo In the clients folder, run npm install . This will install the dev dependency turbo . This will also install the appropriate dependencies in clients and in each client within clients folder. You may need to first remove all node_modules in each of the clients (admin-ui, privacy-center, etc) Dependencies within this directory are managed by Turborepo. Our root package.json file defines 3 workspaces (or packages) that are part of the Turbo ecosystem: admin-ui privacy-center fides-js Running Locally 1 turbo run dev Running this in the root clients folder will result in every workspace being run. Running this command within admin-ui will result in only admin-ui being run. Available commands that exist for every workspace are defined in the root turbo.json file, while commands unique to a specific workspace are defined in the turbo.json file within the workspace. It's important to use the turbo command because, as you see in the turbo.json files, we've defined some dependencies and caching details on some turbo commands. Adding packages To install packages in any package in clients , run the following from clients : 1 npm install <package> --workspace = <workspace> Example: 1 npm install react --workspace = admin-ui See https://turbo.build/repo/docs/handbook/package-installation#addingremovingupgrading-packages for more details","title":"Overview"},{"location":"development/ui/overview/#ui-development-overview","text":"The /clients directory houses all front-end packages and shared code amongst clients, and also includes e2e tests.","title":"UI Development Overview"},{"location":"development/ui/overview/#prerequisites","text":"To run and develop the Fides UI components locally, you'll need to do the following: Clone the Fides repository Install Node.js Globally install Turbo In the clients folder, run npm install . This will install the dev dependency turbo . This will also install the appropriate dependencies in clients and in each client within clients folder. You may need to first remove all node_modules in each of the clients (admin-ui, privacy-center, etc) Dependencies within this directory are managed by Turborepo. Our root package.json file defines 3 workspaces (or packages) that are part of the Turbo ecosystem: admin-ui privacy-center fides-js","title":"Prerequisites"},{"location":"development/ui/overview/#running-locally","text":"1 turbo run dev Running this in the root clients folder will result in every workspace being run. Running this command within admin-ui will result in only admin-ui being run. Available commands that exist for every workspace are defined in the root turbo.json file, while commands unique to a specific workspace are defined in the turbo.json file within the workspace. It's important to use the turbo command because, as you see in the turbo.json files, we've defined some dependencies and caching details on some turbo commands.","title":"Running Locally"},{"location":"development/ui/overview/#adding-packages","text":"To install packages in any package in clients , run the following from clients : 1 npm install <package> --workspace = <workspace> Example: 1 npm install react --workspace = admin-ui See https://turbo.build/repo/docs/handbook/package-installation#addingremovingupgrading-packages for more details","title":"Adding packages"},{"location":"development/ui/privacy_center/","text":"Privacy Center A web application built in Next.js to collect privacy requests from users: access, erasure, consent, and more! Development To serve this application locally, first install your local dependencies at the root client directory level: In /clients : 1 npm install Then, run: 1 2 cd privacy-center turbo run dev This will automatically build and run the project. Building To build this application directly, run: 1 turbo run build As a Next application, it will output build artifacts to the .next directory. API The Privacy Center is a full-stack webserver but generally makes all it's API calls to the connected Fides server. However, it does host a small API of it's own that enables some basic \"edge\" functions like hosting a customized bundle of the fides.js script. To view the OpenAPI documentation, run the application locally and visit the /docs page for details: http://localhost:3000/docs Testing To run the interactive test interface, run: 1 turbo run test For a fully-loaded development & test setup of both the Privacy Center, run the following commands in two separate terminals: 1 2 cd privacy-center && turbo run dev cd privacy-center && turbo run cy:open There are two ways to test Fides consent components: Navigate to http://localhost:3000/fides-js-components-demo.html . This page comes pre-packaged with some default configurations to get up and running quickly with the consent components, and is also the page used by cypress e2e tests. To test other configurations, edit the fidesConfig object passed into Fides.init() in privacy-center/public/fides-js-components-demo.html . Navigate to http://localhost:3000/fides-js-demo.html . This page, unlike the above, calls the /api/fides-js Privacy Center endpoint. This endpoint loads config from the privacy center's legacy config.json , so it's closer to how a customer would actually use the fides-js package. In addition, we inject only the minimal config into fides-js . The overlay is not enabled by default on this page. Deployment To deploy this site, typically you should use the published ethyca/fides-privacy-center Docker image which is production-built Next.js image. See https://docs.ethyca.com for more! Configuration You may configure the appearance of this web application at build time by modifying the config.json file inside the config directory. You're able to control: The header of the document The descriptive text of the document Which actions are present, and each action's: Personally Identifying Information a user must submit Title Description Icon Policy key Whether consent management is enabled Consent options: Personally Identifying Information a user must submit Title Description Icon Which consent management options are present, and each option's: The Fides Data Use that the user may consent to Descriptive information for the type of consent The default consent state (opt in/out): This can be a single boolean which will apply when the user has not modified their consent. Or this can be an object with consent values that depend on the user's consent context, such as whether they are using Global Privacy Control. See fides-js for details. The cookie keys that will be available to fides.js , which can be used to access a user's consent choices outside of the Privacy Center. Whether the user's consent choice should be propagated to any configured third party services (executable). Note that currently, only one option may be marked executable at a time. You can also add any CSS you'd like to the page by adding it to the config.css file inside the config directory. Additionally, if you're handy with React and are feeling a little brave you can customize the entire application by modifying the TypeScript source code in pages/index.tsx and components/RequestModal.tsx . Configuring CSS In order to modify the way your application appears visually, you can add custom css to the config/config.css file. For example, to change the application's font to Courier: 1 2 3 * { font-family : Courier !important ; } Additionally, because this application uses CSS variables, you can modify those CSS variables directly, rather than adding custom CSS. The only caveat to this is that we need to do so in a way that overrides the CSS variables' original values so that we can avoid the complexity of modifying the JavaScript file that holds the base values. Our recommendation is that you do so by using selector specificity, as in the following example: 1 2 3 4 5 6 7 : root : root { /* Changes the text color to red */ --chakra-colors-gray-600 : #f00 ; /* Changes the background color to blue */ --chakra-colors-gray-50 : #00f ; } Not exactly the most appealing color scheme \u2013 but note that wherever those variables are used, they have been replaced. This allows you to modify the theme of the application consistently and with a single source of truth, adhering to modern CSS best practices.","title":"Privacy Center"},{"location":"development/ui/privacy_center/#privacy-center","text":"A web application built in Next.js to collect privacy requests from users: access, erasure, consent, and more!","title":"Privacy Center"},{"location":"development/ui/privacy_center/#development","text":"To serve this application locally, first install your local dependencies at the root client directory level: In /clients : 1 npm install Then, run: 1 2 cd privacy-center turbo run dev This will automatically build and run the project.","title":"Development"},{"location":"development/ui/privacy_center/#building","text":"To build this application directly, run: 1 turbo run build As a Next application, it will output build artifacts to the .next directory.","title":"Building"},{"location":"development/ui/privacy_center/#api","text":"The Privacy Center is a full-stack webserver but generally makes all it's API calls to the connected Fides server. However, it does host a small API of it's own that enables some basic \"edge\" functions like hosting a customized bundle of the fides.js script. To view the OpenAPI documentation, run the application locally and visit the /docs page for details: http://localhost:3000/docs","title":"API"},{"location":"development/ui/privacy_center/#testing","text":"To run the interactive test interface, run: 1 turbo run test For a fully-loaded development & test setup of both the Privacy Center, run the following commands in two separate terminals: 1 2 cd privacy-center && turbo run dev cd privacy-center && turbo run cy:open There are two ways to test Fides consent components: Navigate to http://localhost:3000/fides-js-components-demo.html . This page comes pre-packaged with some default configurations to get up and running quickly with the consent components, and is also the page used by cypress e2e tests. To test other configurations, edit the fidesConfig object passed into Fides.init() in privacy-center/public/fides-js-components-demo.html . Navigate to http://localhost:3000/fides-js-demo.html . This page, unlike the above, calls the /api/fides-js Privacy Center endpoint. This endpoint loads config from the privacy center's legacy config.json , so it's closer to how a customer would actually use the fides-js package. In addition, we inject only the minimal config into fides-js . The overlay is not enabled by default on this page.","title":"Testing"},{"location":"development/ui/privacy_center/#deployment","text":"To deploy this site, typically you should use the published ethyca/fides-privacy-center Docker image which is production-built Next.js image. See https://docs.ethyca.com for more!","title":"Deployment"},{"location":"development/ui/privacy_center/#configuration","text":"You may configure the appearance of this web application at build time by modifying the config.json file inside the config directory. You're able to control: The header of the document The descriptive text of the document Which actions are present, and each action's: Personally Identifying Information a user must submit Title Description Icon Policy key Whether consent management is enabled Consent options: Personally Identifying Information a user must submit Title Description Icon Which consent management options are present, and each option's: The Fides Data Use that the user may consent to Descriptive information for the type of consent The default consent state (opt in/out): This can be a single boolean which will apply when the user has not modified their consent. Or this can be an object with consent values that depend on the user's consent context, such as whether they are using Global Privacy Control. See fides-js for details. The cookie keys that will be available to fides.js , which can be used to access a user's consent choices outside of the Privacy Center. Whether the user's consent choice should be propagated to any configured third party services (executable). Note that currently, only one option may be marked executable at a time. You can also add any CSS you'd like to the page by adding it to the config.css file inside the config directory. Additionally, if you're handy with React and are feeling a little brave you can customize the entire application by modifying the TypeScript source code in pages/index.tsx and components/RequestModal.tsx .","title":"Configuration"},{"location":"development/ui/privacy_center/#configuring-css","text":"In order to modify the way your application appears visually, you can add custom css to the config/config.css file. For example, to change the application's font to Courier: 1 2 3 * { font-family : Courier !important ; } Additionally, because this application uses CSS variables, you can modify those CSS variables directly, rather than adding custom CSS. The only caveat to this is that we need to do so in a way that overrides the CSS variables' original values so that we can avoid the complexity of modifying the JavaScript file that holds the base values. Our recommendation is that you do so by using selector specificity, as in the following example: 1 2 3 4 5 6 7 : root : root { /* Changes the text color to red */ --chakra-colors-gray-600 : #f00 ; /* Changes the background color to blue */ --chakra-colors-gray-50 : #00f ; } Not exactly the most appealing color scheme \u2013 but note that wherever those variables are used, they have been replaced. This allows you to modify the theme of the application consistently and with a single source of truth, adhering to modern CSS best practices.","title":"Configuring CSS"}]}
\ No newline at end of file
diff --git a/dev/sitemap.xml b/dev/sitemap.xml
index 22c737ad5a..0366f08d8a 100644
--- a/dev/sitemap.xml
+++ b/dev/sitemap.xml
@@ -2,94 +2,94 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     <url>
          <loc>https://ethyca.github.io/fides/dev/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/ethyca/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/license/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/api/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/cli/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/community/code_of_conduct/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/community/hints_tips/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/community/overview/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/config/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/code_style/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/developing_fides/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/development_tips/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/documentation/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/fideslog/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/overview/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/pull_requests/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/releases/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/testing/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/update_erd_diagram/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/postman/using_postman/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/ui/admin_ui/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/ui/overview/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
     <url>
          <loc>https://ethyca.github.io/fides/dev/development/ui/privacy_center/</loc>
-         <lastmod>2025-01-10</lastmod>
+         <lastmod>2025-01-13</lastmod>
     </url>
 </urlset>
\ No newline at end of file
diff --git a/dev/sitemap.xml.gz b/dev/sitemap.xml.gz
index 31b28faf58..a232135efd 100644
Binary files a/dev/sitemap.xml.gz and b/dev/sitemap.xml.gz differ