From eb99bd3e68fe4815181d1c2c08550888f1b5aa5a Mon Sep 17 00:00:00 2001
From: smvgarcia <111767892+smvgarcia@users.noreply.github.com>
Date: Tue, 5 Nov 2024 11:27:55 -0600
Subject: [PATCH 1/2] Update fence_create.md

fix broken link
---
 docs/additional_documentation/fence_create.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/additional_documentation/fence_create.md b/docs/additional_documentation/fence_create.md
index 398544f98..db2b735f3 100644
--- a/docs/additional_documentation/fence_create.md
+++ b/docs/additional_documentation/fence_create.md
@@ -53,7 +53,7 @@ curl --request POST https://FENCE_URL/oauth2/token?grant_type=client_credentials
 
 The optional `--expires-in` parameter allows specifying the number of *days* until this client expires. The recommendation is to rotate credentials with the `client_credentials` grant at least once a year (see [Rotate client credentials](#rotate-client-credentials) section).
 
-NOTE: In Gen3, you can grant specific access to a client the same way you would to a user. See the [user.yaml guide](https://github.com/uc-cdis/fence/blob/master/docs/user.yaml_guide.md) for more details.
+NOTE: In Gen3, you can grant specific access to a client the same way you would to a user. See the [user.yaml guide](https://github.com/uc-cdis/fence/blob/master/docs/additional_documentation/user.yaml_guide.md) for more details.
 
 NOTE: Client credentials tokens are not linked to a user (the claims contain no `sub` or `context.user.name` like other tokens). Some Gen3 endpoints that assume the token is linked to a user, or whose logic require there being a user, do not support them. For an example of how to adapt an endpoint to support client credentials tokens, see [here](https://github.com/uc-cdis/requestor/commit/a5078fae27fa258ac78045cf2bb89cb2104f53cf). For an example of how to explicitly reject client credentials tokens, see [here](https://github.com/uc-cdis/requestor/commit/0f4974c25343d2185c7cdb48dcdeb58f97800672).
 

From 1a7a534d7d75c9fb0570e94bb8a60fb022fbe080 Mon Sep 17 00:00:00 2001
From: smvgarcia <111767892+smvgarcia@users.noreply.github.com>
Date: Tue, 5 Nov 2024 11:30:22 -0600
Subject: [PATCH 2/2] Update user.yaml_guide.md

fix broken link
---
 docs/additional_documentation/user.yaml_guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/additional_documentation/user.yaml_guide.md b/docs/additional_documentation/user.yaml_guide.md
index 893d32045..77e9e2b1d 100644
--- a/docs/additional_documentation/user.yaml_guide.md
+++ b/docs/additional_documentation/user.yaml_guide.md
@@ -16,7 +16,7 @@
 
 The `user.yaml` file is one way to get authorization information into Gen3. It is ingested via [Fence's `usersync` script](usersync.md). The format of this file is tightly coupled with the notions of resource, role and policy as defined by Gen3's policy engine, [Arborist](https://github.com/uc-cdis/arborist#arborist).
 
-For Gen3 Data Commons that do not use Arborist or that use the Google Data Access method of [Google Service Account Registration](https://github.com/uc-cdis/fence/blob/master/docs/google_architecture.md#google-account-linking-and-service-account-registration), refer to the [Deprecated format](#deprecated-format) section.
+For Gen3 Data Commons that do not use Arborist or that use the Google Data Access method of [Google Service Account Registration](https://github.com/uc-cdis/fence/blob/master/docs/additional_documentation/google_architecture.md#google-account-linking-and-service-account-registration), refer to the [Deprecated format](#deprecated-format) section.
 
 In a fully deployed Gen3 Commons using [Cloud Automation](https://github.com/uc-cdis/cloud-automation), the `user.yaml` file is usually hosted in S3 and configured via the `global.useryaml_s3path` setting of the Gen3 Data Commons manifest:
 ```