> For the complete documentation index, see [llms.txt](https://academy.shade.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.shade.inc/shade-academy/shade-academy-es/compartir-y-colaborar/permission-inheritance-examples.md). # Ejemplos de herencia de permisos ### Escenario: Miembro del espacio de trabajo + herencia de unidad **Tú** * Rol: **Miembro del espacio de trabajo** * No eres administrador del espacio de trabajo * Te unes a un espacio de trabajo que ya tiene dos unidades *** ### Configuración de las unidades (por un administrador) #### Unidad A: `Proyecto de marketing` * **Herencia predeterminada para los miembros del espacio de trabajo:** **Acceso completo** #### Unidad B: `Finanzas y Asuntos Legales` * **Herencia predeterminada para los miembros del espacio de trabajo:** **Sin acceso** *** ### Lo que ves cuando te unes al espacio de trabajo #### Unidad A — `Proyecto de marketing` Porque la herencia predeterminada de la unidad es **Acceso completo**: * La unidad aparece en tu lista de unidades * Puedes abrir todas las carpetas y archivos * Puedes: * Subir archivos * Cambiar el nombre, eliminar y reorganizar archivos * Administrar permisos a nivel de archivo y carpeta * No eres **un** administrador de la unidad * No puedes cambiar el nombre ni eliminar la unidad * No puedes administrar permisos a nivel de la unidad * No puedes administrar metadatos a nivel de la unidad *** #### Unidad B — `Finanzas y Asuntos Legales` Porque la herencia predeterminada de la unidad es **Sin acceso**: * La unidad no **un** aparece en tu lista de unidades * No puedes explorar sus carpetas o archivos * No tienes ninguna visibilidad de que siquiera existan sus contenidos > En la práctica: > > **Esta unidad es invisible para ti a menos que alguien te agregue explícitamente.** *** ### Si más tarde un administrador cambia algo #### Caso 1: El administrador te agrega explícitamente a la Unidad B como editor * La Unidad B ahora aparece en tu lista de unidades * Puedes acceder a todas las carpetas y archivos de esa unidad * Tus permisos son **Editor**, independientemente de la herencia predeterminada *** #### Caso 2: El administrador cambia la herencia predeterminada de la Unidad B a “Lector” * Ves la unidad * Puedes ver/descargar archivos, pero no editarlos ni subirlos ### Escenario: Contratista del espacio de trabajo **Tú** * Rol: **Contratista del espacio de trabajo** * La misma configuración que antes, dos unidades, una con “Sin acceso” y otra con herencia predeterminada de “Acceso completo” *** ### Lo que ves cuando te unes al espacio de trabajo #### Ambas unidades son invisibles: Porque los contratistas ignoran la herencia predeterminada: * Las unidades no **un** aparece en tu lista de unidades * No puedes explorar sus carpetas o archivos * No tienes ninguna visibilidad de que siquiera existan sus contenidos *** ### Si más tarde un administrador cambia algo #### Caso 1: El administrador te agrega explícitamente a la Unidad A como editor * La Unidad A ahora aparece en tu lista de unidades * Puedes acceder a todas las carpetas y archivos de esa unidad * Tus permisos son **Editor**, independientemente de la herencia predeterminada *** #### Caso 2: El administrador te agrega a una carpeta específica dentro de la Unidad A * Ves la unidad * Puedes ver y descargar archivos dentro de esa carpeta específica, y si montaras esa unidad solo verías esa carpeta específica a la que fuiste agregado. * Si fueras agregado a una carpeta secundaria, podrías navegar hasta esa carpeta a través de la carpeta principal, pero no **podrías** ver ninguna carpeta a la que no hayas sido agregado explícitamente. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://academy.shade.inc/shade-academy/shade-academy-es/compartir-y-colaborar/permission-inheritance-examples.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.