+
+# Release 0.16.4
+
+We are thrilled to announce the latest release of Infrahub, version *0.16.4*!
+
+This release focuses largely on bug fixes and is driven by our Beta Test users,
+and as always we greatly appreciate their feedback and time!
+
+## Main changes
+
+The complete list of changes can always be found in the `CHANGELOG.md` file in the Infrahub Git repository.
+
+### Fixed
+
+- Fixed an issue on the UI where a new relationship was being added to the main branch instead of the current branch. ([#4598](https://github.com/opsmill/infrahub/issues/4598))
+
+## Migration guide
+
+To migrate your instance of Infrahub to the latest version, please run the following commands and restart all instances of Infrahub.
+
+
+```shell
+infrahub db migrate
+infrahub db update-core-schema
+```
+
+
+> if you are running in docker these commands need to run from the container where Infrahub is installed
+
+### Migration of the demo instance
+
+If you are using the demo environment, you can migrate to the latest version with the following commands
+
+```shell
+invoke demo.stop
+invoke demo.build
+invoke demo.migrate
+invoke demo.start
+```
+
+If you don't want to keep your data, you can start a clean instance with the following command
+
+```shell
+invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data
+```
+
+> All data will be lost, please make sure to backup everything you need before running this command.
+
+The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.
diff --git a/docs/docs/release-notes/infrahub/release-1_0.mdx b/docs/docs/release-notes/infrahub/release-1_0.mdx
new file mode 100644
index 0000000000..897d81017f
--- /dev/null
+++ b/docs/docs/release-notes/infrahub/release-1_0.mdx
@@ -0,0 +1,252 @@
+---
+title: Release 1.0.0
+---
+
+
+# Release 1.0
+
+We are thrilled to announce the general availability release of Infrahub, version *1.0*!
+
+We greatly appreciate all the time and efforts of our dedicated community of developers and beta testers!
+
+## Main changes
+
+Infrahub 1.0 is focused on bringing Infrahub to even more organizations and equipping them with a
+production-ready solution to their infrastructure automation challenges.
+
+There are four key features and changes in Infrahub version 1.0 as outlined below:
+
+- SSO login capabilities (OIDC/OUATH2)
+- A new permission framework
+- Performance enhancements to version control actions (diff/merge/rebase)
+- An exciting UI and navigation redesign
+
+In addition to these, there have been many bug-fixes and quality-of-life enhancements shown in the detailed changelog.
+
+### Single sign-on and user permissions
+
+Early in the development of Infrahub, we consciously decided to focus on the groundbreaking and critical features that make
+Infrahub a uniquely world-class Source of Truth.
+As a result, we set aside some standard enterprise features, such as Single Sign-On, until later,
+knowing that they would be straightforward to implement in the system.
+
+As we enter a new era with Infrahub 1.0, we have focused on rounding out the enterprise-grade features
+that our customers require.
+For example, we added Single Sign-On (SSO) integrations for OIDC/Oauth 2.0 and implemented a robust and granular permissions system.
+These two features combine to give organizations a level of control that allows them to trust their mission-critical
+data in Infrahub and bring even closer integration with existing enterprise systems and workflows.
+
+#### SSO
+
+The new OIDC/OAuth2 capabilities, tested and functioning in the field with many Identity Providers
+such as Keycloak, Authentik, and Google Auth, allow organizations to manage their users and groups centrally
+instead of in the Infrahub UI.
+Subsequent releases of Infrahub will soon include validated support for additional Identity Providers
+and other authentication methods (such as LDAP).
+
+This functionality goes hand in hand with the feature we will discuss next: our new User Permissions structure.
+
+##### Documentation
+
+- https://docs.infrahub.app/guides/sso
+
+#### User permissions
+
+As users store more data in Infrahub and more teams interact with that data, it becomes crucial to protect it
+from accidental changes.
+By implementing a granular role-based permission system, Infrahub allows organizations to prevent unauthorized changes
+to the data behind critical infrastructure automation efforts.
+
+In the permission structure introduced in Infrahub 1.0, Users are added to Groups, Groups are given Roles,
+and Permissions are finally allocated to those Roles.
+Permissions come in two fundamental varieties: Global Permissions and Object Permissions.
+
+The below diagram lays out the relationship between each of these entities.
+A User can belong to one or more Groups, a Group can have multiple Roles assigned to it, and each Role can be granted one
+or more Global or Object Permissions.
+
+
+
+##### Global vs. object permissions
+
+It is also worth mentioning the difference between Global Permissions and Object Permissions.
+
+- Global Permissions are specific permission sets that can give users system-wide rights to perform particular actions, for example:
+ - Editing the default Branch
+ - Editing Permissions
+ - Allowing the merging of proposed changes
+ - Account management
+- Object Permissions are tied to individual objects within Infrahub and control what actions users can take on those objects; examples could include:
+ - Allow read-only access to all objects
+ - Deny the ability to update Tags
+ - Allow editing on any object type that starts with `DataCenter`
+
+For either style, Permissions are structured to be robust and granular by allowing complete control over
+the Action, Decision, and Role of a given Permission set (plus the Object Type for Object Permissions).
+
+##### Documentation
+
+This is a significant topic on a new feature that enables complex workflows to meet organizational needs. Because of this, we strongly recommend diving into the documentation links below.
+
+- https://docs.infrahub.app/guides/accounts-permissions
+- https://docs.infrahub.app/topics/permissions-roles
+- https://docs.infrahub.app/reference/permissions
+
+### Performance improvements
+
+Our design philosophy at OpsMill has always been driven by long experience as network practitioners or admins
+in Unix-like systems: “Make it work, make it right, make it fast.”
+
+In Infrahub 1.0, we focused on the last part, “Make it fast.”
+
+As our early beta testers began to utilize Infrahub in increasingly large infrastructures (greater than 50,000 nodes),
+we expected (and found) opportunities for performance improvements.
+This was especially true when performing Version Control actions on large data sets.
+As a result of the intensive testing, we made dramatic improvements to branch change management.
+Infrahub 1.0 has improved how Infrahub computes a difference between two branches, re-bases a branch,
+and handles the merge.
+For example, in the “diff” generation for a proposed change, we have seen a 30% increase in performance over earlier versions.
+As a result, the proposed change functionality can now reliably handle much larger data sets for comparison.
+
+These performance improvements are only the beginning of our optimization efforts, but they have already improved
+the experience of Infrahub users of all infrastructure sizes.
+
+### UI redesign
+
+While the UI in Infrahub before 1.0 served its purpose well, there was room for improvement.
+A corollary fourth phrase to our design philosophy might be, “Now, make it pretty!”
+
+We didn’t just change around some colors or styles; we worked closely with our beta testers and a dedicated
+User Experience professional to ensure that using Infrahub 1.0 would be an experience that our users enjoyed.
+
+
+
+We also provided capabilities for complete customization of the navigation menu.
+We continue to emphasize that Infrahub is a powerful, fully customizable system that meets your
+organization where it needs to be.
+
+#### Documentation
+
+- https://docs.infrahub.app/guides/menu
+- https://docs.infrahub.app/reference/menu
+
+## Other
+
+### Removed
+
+- Remove previously deprecated GET API endpoint "/api/schema/" ([#3884](https://github.com/opsmill/infrahub/issues/3884))
+
+### Deprecated
+
+- Marked CoreAccount.role as deprecated
+ Due to the new permissions framework the account roles "admin" / "read-only" / "read-write" are deprecated and will be removed in Infrahub 1.1
+
+### Added
+
+- Reworked branch selector:
+ - Redesigned the UI
+ - Added filter for branch
+ - Improved accessibility & keyboard navigation
+ - Improved UX on new branch form
+ - Added quick link to view all branches
+- Add support to sign in with OAuth2 and Open ID Connect (OIDC) ([#1568](https://github.com/opsmill/infrahub/issues/1568))
+- Add internal HTTP adapter to allow for generic access from Infrahub ([#3302](https://github.com/opsmill/infrahub/issues/3302))
+- Add support to search a node by human friendly ID within a GraphQL query ([#3908](https://github.com/opsmill/infrahub/issues/3908))
+- Added link to our Discord server in the account menu
+- Added permissions framework for global and object kind level permissions
+
+ In this first iteration the object permissions are applied to nodes as a whole, in upcoming versions it will be possible to define attribute level permissions as well.
+- New permissions system in UI:
+ - Implemented CRUD views for managing accounts, groups, roles, and permissions
+ - Updated all components to support new permission system
+ - Added dynamic message display according to user access levels
+
+### Fixed
+
+- The `infrahub-git` agent service has been renamed to `task-worker` in docker compose and the command to start it has been updated as well ([#1075](https://github.com/opsmill/infrahub/issues/1075))
+- Add ability to import repositories with default branch other than 'main' ([#3435](https://github.com/opsmill/infrahub/issues/3435))
+- Disable approve/merge/close buttons for merged Proposed Changes ([#3495](https://github.com/opsmill/infrahub/issues/3495))
+- Fixed regex validation for List type attributes ([#3929](https://github.com/opsmill/infrahub/issues/3929))
+- Allow users to run artifacts and generators on nodes without name attribute ([#4062](https://github.com/opsmill/infrahub/issues/4062))
+- In the schema, properly delete inherited attribute and relationship on Node when the original attribute or relationship are being deleted on the Generic ([#4301](https://github.com/opsmill/infrahub/issues/4301))
+- "Retry All" button for checks is bigger ([#4315](https://github.com/opsmill/infrahub/issues/4315))
+- Add a size restriction on common attribute kinds. Only TextArea and JSON support large values ([#4432](https://github.com/opsmill/infrahub/issues/4432))
+- The HFID of a related node is properly returned via GraphQL in all scenarios ([#4482](https://github.com/opsmill/infrahub/issues/4482))
+- Add full validation to BranchMerge and BranchRebase mutations ([#4595](https://github.com/opsmill/infrahub/issues/4595))
+- Report user-friendly error for invalid uniqueness_constraints when loading schemas ([#4677](https://github.com/opsmill/infrahub/issues/4677))
+- Fixed pagination query for nodes with order_by clause using non unique attributes ([#4700](https://github.com/opsmill/infrahub/issues/4700))
+- Fixed schema migration when an attribute previously present on a node is added back ([#4727](https://github.com/opsmill/infrahub/issues/4727))
+- Add order_weight property to multiple attributes and relationships in the demo schema to improve how some models are displayed in the list views
+- Changed the Python SDK connection timeout to 60s
+- Fix metric missing the query name in Prometheus data
+- Fixes an issue where docker compose would output ANSI control characters that don't support it
+- Prevent temporary directories generated by Docusaurus to be imported by Docker
+
+## Migration guide
+
+The process to migrate your instance of Infrahub to the latest version may vary depending on your deployment of Infrahub.
+However, at a high-level, it will involve getting the latest version of the Infrahub code, and then performing any needed Database Migrations and Schema updates.
+
+Please ensure you have a **backup of your Infrahub environment** prior to attempting any migration or upgrade activities.
+
+### Migration of an Infrahub instance
+
+**First**, update the Infrahub version running in your environment.
+
+Below are some example ways to get the latest version of Infrahub in your environment.
+
+- For deployments via Docker Compose, update your container version by updating the `IMAGE_VER` environment variable and relaunch:
+ - `export IMAGE_VER="1.0.0"; docker compose pull && docker compose up -d`
+- For deployments via Kubernetes, utilize the latest version of the Helm chart supplied with this release
+
+**Second**, once you have gotten the desired version of Infrahub in your environment, please run the following commands.
+
+> Note: If you are running Infrahub in Docker/K8s, these commands need to run from a container where Infrahub is installed.
+
+```shell
+infrahub db migrate
+infrahub db update-core-schema
+```
+
+**Finally**, restart all instances of Infrahub.
+
+### Migration of a dev or demo instance
+
+If you are using the `dev` or `demo` environments, we have provided `invoke` commands to aid in the migration to the latest version.
+The below examples provide the `demo` version of the commands, however similar commands can be used for `dev` as well.
+
+```shell
+invoke demo.stop
+invoke demo.build
+invoke demo.migrate
+invoke demo.start
+```
+
+If you don't want to keep your data, you can start a clean instance with the following command.
+
+> **Warning: All data will be lost, please make sure to backup everything you need before running this command.**
+
+```shell
+invoke demo.destroy demo.build demo.start demo.load-infra-schema demo.load-infra-data
+```
+
+The repository https://github.com/opsmill/infrahub-demo-edge has also been updated, it's recommended to pull the latest changes into your fork.
\ No newline at end of file
diff --git a/docs/docs/release-notes/infrahub/release-1_0-DRAFT.mdx b/docs/docs/release-notes/infrahub/release-1_0_1-DRAFT.mdx
similarity index 96%
rename from docs/docs/release-notes/infrahub/release-1_0-DRAFT.mdx
rename to docs/docs/release-notes/infrahub/release-1_0_1-DRAFT.mdx
index 185e7db431..28c209c497 100644
--- a/docs/docs/release-notes/infrahub/release-1_0-DRAFT.mdx
+++ b/docs/docs/release-notes/infrahub/release-1_0_1-DRAFT.mdx
@@ -1,5 +1,5 @@
---
-title: Release 0.16 - DEVELOPMENT
+title: Release 1.0.1 - DEVELOPMENT
---
@@ -22,7 +22,7 @@ title: Release 0.16 - DEVELOPMENT
-# Release 1.0
+# Release 1.0.1
## Main changes
diff --git a/docs/docs/topics/architecture.mdx b/docs/docs/topics/architecture.mdx
index 44ed346db0..8bcd36668c 100644
--- a/docs/docs/topics/architecture.mdx
+++ b/docs/docs/topics/architecture.mdx
@@ -14,7 +14,8 @@ The main components are:
- A **Frontend** written in React and rendered in the user's browser.
- An **API server** written in Python with FastAPI.
-- A **Git agent** written in Python to manage the interaction with external Git repositories.
+- A **Task manager** based on `Prefect` to orchestrate workflow tasks.
+- A **Task worker** written in Python to execute specific tasks such as managing the interaction with external Git repositories.
- A **Graph database** based on `neo4j`.
- A **Message bus** based on `RabbitMQ`.
- A **Cache** based on `redis`.
@@ -33,13 +34,23 @@ Multiple instance of the API Server can run at the same time to process more req
:::
-### Git agent
+### Task manager
+
+The Task manager is based on Prefect, and is responsible for orchestration of tasks to be delegated to one or more Task workers.
+
+### Task worker
Language: Python
-The Git agent is responsible for managing all the content related to the Git repositories. It organizes the file systems in order to quickly access any relevant commit. The Git Agent periodically pulls the Git server for updates and listens to the RPC channel on the event bus for tasks to execute.
+The Task worker is responsible for managing all the content related to the Git repositories. It organizes the file systems in order to quickly access any relevant commit. The Task worker periodically pulls the Git server for updates and listens to the RPC channel on the event bus for tasks to execute.
+
+Currently there are three types of tasks:
+
+- *Internal* tasks
+- *User* tasks
+- *Git* tasks
-Some of the tasks that can be executed on the Git agent includes:
+Some of the tasks that can be executed on the Task worker include:
- Rendering a Jinja template.
- Rendering a transform function.
@@ -48,7 +59,7 @@ Some of the tasks that can be executed on the Git agent includes:
:::note
-Multiple instance of the Git agent can run at the same time to process more requests.
+Multiple instance of the Task worker can run at the same time to process more requests.
:::
diff --git a/docs/docs/topics/artifact.mdx b/docs/docs/topics/artifact.mdx
index 08afd41a3e..88b1982b8f 100644
--- a/docs/docs/topics/artifact.mdx
+++ b/docs/docs/topics/artifact.mdx
@@ -34,7 +34,7 @@ An **artifact definition** centralizes all the information required to generate
- Format of the output
- Information to extract from each target that must be passed to the transformation.
-From an **artifact definition** artifact nodes are created, for each target which is part of the group. The result of the transformation is stored in the [object storage](./object-storage.mdx). The generation of the artifacts is performed by the Git agent(s).
+From an **artifact definition** artifact nodes are created, for each target which is part of the group. The result of the transformation is stored in the [object storage](./object-storage.mdx). The generation of the artifacts is performed by the Task worker(s).
diff --git a/docs/docs/topics/auth.mdx b/docs/docs/topics/auth.mdx
index 3793295007..63cbda2a98 100644
--- a/docs/docs/topics/auth.mdx
+++ b/docs/docs/topics/auth.mdx
@@ -4,39 +4,110 @@ title: User management and authentication
# User management and authentication
-Infrahub now supports standard user management and authentication systems.
-
-A user account can have 3 levels of permissions
-
-- `admin`
-- `read-write`
-- `read-only`
-
-By default, Infrahub will allow anonymous access in read-only. It's possible to disable this via the configuration `main.allow_anonymous_access` or via the environment variable `INFRAHUB_ALLOW_ANONYMOUS_ACCESS`.
+By default, Infrahub will allow anonymous access in read-only mode. It's possible to disable this via the configuration `main.allow_anonymous_access` or via the environment variable `INFRAHUB_ALLOW_ANONYMOUS_ACCESS`.
## Authentication mechanisms
-Infrahub supports two authentication methods
+Infrahub supports two authentication methods:
-- JWT token: Short life tokens generated on demand from the API.
-- API Token: Long life tokens generated ahead of time.
+- **JWT Token**: Short-lived tokens generated on demand from the API.
+- **API Token**: Long-lived tokens generated ahead of time.
| | JWT | TOKEN |
| ------------------ | ---- | ----- |
| API / GraphQL | Yes | Yes |
| Frontend | Yes | No |
-| Python SDK | Soon | Yes |
-| infrahubctl | Soon | Yes |
+| Python SDK | Yes | Yes |
+| infrahubctl | Yes | Yes |
| GraphQL Playground | No | Yes |
-More information on managing API token can be found in the [managing API tokens guide](/guides/managing-api-tokens).
+More information on managing API tokens can be found in the [Managing API Tokens Guide](/guides/managing-api-tokens).
:::info
While using the API, the authentication token must be provided in the header:
```yaml
-X-INFRAHUB-KEY: 06438eb2-8019-4776-878c-0941b1f1d1ec
-```
+X-INFRAHUB-KEY: 06438eb2-8019-4776-878c-0941b1f1d1ec```
:::
+
+## Users permissions management
+
+Users are allocated permissions through groups and roles.
+
+- **Users** are members of **Groups**.
+- **Groups** are related with **Roles**.
+- **Roles** are allocated **Permissions** (global or object-specific).
+
+Using roles and groups to manage permissions, **Infrahub offers a scalable way** to control access for numerous users simultaneously. For more detailed information, visit the [role and permissions page](/topics/permissions-roles).
+
+## Default setup
+
+Infrahub comes with a default configuration that contains pre-configured users, groups, and roles to simplify access management from the start. These **default settings** guarantee that key access and admin capabilities are ready to use out of the box.
+
+### Default account
+
+| Accounts | Description |
+|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **Admin** | The default administrative user in Infrahub. This user is part of the **Super Administrators** group, which gives them full system-wide permissions. |
+
+### Default groups
+
+| Group Name | Description | Assigned Role |
+|------------------------|------------------------------------------------------------------------------------------------------------|-------------------------------|
+| **Infrahub Users** | Standard users who have general access to Infrahub, with permission to view and interact with resources. | **General Access** |
+| **Super Administrators**| Administrators with full control over the system. Users in this group have unrestricted access to all features. | **Super Administrator** |
+
+### Default roles
+
+#### General access
+
+This role gives standard users general permissions to view and interact with resources across the platform while restricting administrative actions.
+
+| Permission | Description |
+|-------------------------------------------|-------------------------------------------------------------------------------------------------|
+| `global:manage_repositories:allow_all` | Enables repository management for all branches. |
+| `global:manage_schema:allow_all` | Permits global schema management. |
+| `global:merge_proposed_change:allow_all` | Allows merging proposed changes across all branches. |
+| `object:*:*:view:allow_all` | Allows seeing all objects, across all branches and namespaces. |
+| `object:*:*:any:allow_other` | Permits executing any action on non-default branches for all object types. |
+
+#### Super administrator
+
+This role provides full administrative control over Infrahub. Users with this role can manage everything within the system.
+
+| Permission | Description |
+|-------------------------------------|--------------------------------------------------------------------------------------------------------------|
+| `global:super_admin:allow_all` | Permits complete administrative control, including schema, permissions, users, and repositories management. |
+
+#### Anonymous user
+
+If Infrahub is setup to allow anonymous access when it is first initialized, an additional account role called **Anonymous User** will be created. This role defines all the permissions that a user will inherit when not logged in. The default configuration for this role ships with two permissions:
+
+| Permission | Description |
+|-------------------------------------|--------------------------------------------------------------------------------------------------------------|
+| `object:*:*:any:deny` | Denies anything on all objects, across all branches (this one is not required, but it is more explicit) |
+| `object:*:*:view:allow_all` | llows seeing all objects, across all branches and namespaces. |
+
+The role is defined by its name in Infrahub's configuration and can be adjusted by changing the setting `main.anonymous_access_role` or the environment variable `INFRAHUB_ANONYMOUS_ACCESS_ROLE`.
+
+Note that an anonymous user will never be able to make changes to data inside Infrahub whether the role's permisssions allow it or not.
+
+## Authentication backends
+
+Infrahub supports authenticating users in a local user store or by using single sign-on through an external identity provider.
+
+### Local user store
+
+Users can be created in the local user store. Local users can be added to groups, which can have roles assigned to them.
+
+### Single sign-on
+
+Infrahub supports identity providers that support either OAuth2 or OpenID Connect (OIDC).
+
+Multiple identity providers can be enabled simultaneously, for example to support organizations that use different providers for different security domains.
+
+A user that was authenticated using SSO will be created in the local user store of Infrahub and optionally automatically added to groups, which can have roles assigned to them.
+
+For more information on setting up single sign-on can be found in the [configuring single sign-on guide](/guides/sso).
diff --git a/docs/docs/topics/graphql.mdx b/docs/docs/topics/graphql.mdx
index 2a132920a5..7ee0f06853 100644
--- a/docs/docs/topics/graphql.mdx
+++ b/docs/docs/topics/graphql.mdx
@@ -8,17 +8,22 @@ The GraphQL interface is the main interface to interact with Infrahub. The Graph
The endpoint to interact with the main branch is accessible at `https:///graphql`.
To interact with a branch the URL must include the name of the branch, such as `https:///graphql/`.
+If you need to extract the current GraphQL schema in your environment you can issue an HTTP get request to:
+
+- `https:////schema.graphql`
+- `https:////schema.graphql?branch=some-other-branch`
## Query & mutations
-For each model in the schema, a GraphQL query and 3 mutations will be generated based on the namespace and the name of the model.
+In GraphQL, a query is used to fetch data and mutations are use to create/update or delete data. In Infrahub, a GraphQL query and 4 mutations will be generated for each model you define in the schema. The name of the query or mutation is based on the namespace and name of the model.
For example, for the model `CoreRepository` the following query and mutations have been generated:
-- `Query` : **CoreRepository**
-- `Mutation` : **CoreRepositoryCreate**
-- `Mutation` : **CoreRepositoryUpdate**
-- `Mutation` : **CoreRepositoryDelete**
+- `Query` : **CoreRepository** to fetch `CoreRepository` nodes from Infrahub
+- `Mutation` : **CoreRepositoryCreate** to create a `CoreRepository` node
+- `Mutation` : **CoreRepositoryUpdate** to update an existing `CoreRepository` node
+- `Mutation` : **CoreRepositoryUpsert** to create or update a `CoreRepository` node
+- `Mutation` : **CoreRepositoryDelete** to delete a `CoreRepository` node
### Query format
@@ -26,16 +31,17 @@ The top level query for each model will always return a list of objects and the
```graphql
query {
- CoreRepository { # PaginatedCoreRepository object
- count
- edges { # EdgedCoreRepository object
- node { # CoreRepository object
- id
- display_label
- __typename
- }
- }
+ CoreRepository { # PaginatedCoreRepository object
+ count
+ edges { # EdgedCoreRepository object
+ node { # CoreRepository object
+ id
+ hfid
+ display_label
+ __typename
+ }
}
+ }
}
```
@@ -45,9 +51,13 @@ All list of objects will be nested under `edges` & `node` to make it possible to
:::
-#### `ID` and `display_label`
+#### `ID`, `hfid` and `display_label`
+
+For all nodes, the attribute `id`, `hfid` and `display_label` are automatically available.
-For all nodes, the attribute `id` and `display_label` are automatically available. The value used to generate the `display_label` can be defined for each model in the schema. If no value has been provided a generic display label with the kind and the ID of the Node will be generated.
+The value used to generate the `display_label` can be defined for each model in the schema. If no value has been provided a generic display label with the kind and the ID of the Node will be generated.
+
+The value used to generate the `hfid` can be defined for each model in the schema. If no value has been provided and the `model` has a single uniqueness constraint defined, then the `hfid` will be automatically generated from the uniqueness constraint.
At the object level, there are mainly 3 types of resources that can be accessed, each with a different format:
@@ -64,22 +74,22 @@ At the same level all the metadata of the attribute are also available example:
```graphql {6-14} title="Example query to access the value and the properties of the attribute 'name'"
query {
- CoreRepository {
- count
- edges {
- node {
- name { # TextAttribute object
- value
- is_protected
- is_visible
- source {
- id
- display_label
- }
- }
- }
+ CoreRepository {
+ count
+ edges {
+ node {
+ name { # TextAttribute object
+ value
+ is_protected
+ is_visible
+ source {
+ id
+ display_label
+ }
}
+ }
}
+ }
}
```
@@ -89,27 +99,28 @@ A relationship to another model with a cardinality of `One` will be represented
```graphql {6-19} title="Example query to access the peer and the properties of the relationship 'account', with a cardinality of one."
query {
- CoreRepository {
- count
- edges {
- node {
- account {
- properties {
- is_visible
- is_propected
- source {
- id
- display_label
- }
- }
- node {
- display_label
- id
- }
- }
+ CoreRepository {
+ count
+ edges {
+ node {
+ account {
+ properties {
+ is_visible
+ is_propected
+ source {
+ id
+ display_label
}
+ }
+ node {
+ display_label
+ hfid
+ id
+ }
}
+ }
}
+ }
}
```
@@ -119,46 +130,48 @@ A relationship with a cardinality of `Many` will be represented with a `NestedPa
```graphql {6-20} title="Example query to access the relationship 'tags', with a cardinality of Many."
query {
- CoreRepository {
- count
- edges {
+ CoreRepository {
+ count
+ edges {
+ node {
+ tags { # NestedPaginatedBuiltinTag object
+ count
+ edges { # NestedEdgedBuiltinTag object
+ properties {
+ is_protected
+ source {
+ id
+ }
+ }
node {
- tags { # NestedPaginatedBuiltinTag object
- count
- edges { # NestedEdgedBuiltinTag object
- properties {
- is_protected
- source {
- id
- }
- }
- node {
- display_label
- id
- }
- }
- }
+ display_label
+ hfid
+ id
}
+ }
}
+ }
}
+ }
}
```
### Mutations format
-The format of the mutation to `Create` and `Update` an object has some similarities with the query format. The format will be slightly different for:
+The format of the mutation to `Create`, `Update` and `Upsert` an object has some similarities with the query format. The format will be slightly different for:
- An `Attribute`
- A relationship of `Cardinality One`
- A relationship of `Cardinality Many`
-#### Create and update
+#### Create, update and upsert
-To `Create` or `Update` an object, the mutations will have the following properties.
+To `Create`, `Update` or `Upsert` an object, the mutations will have the following properties.
- The input for the mutation must be provided inside `data`.
- All mutations will return `ok` and `object` to access some information after the mutation has been executed.
-- For `Update`, it is mandatory to provide an `id`.
+- `Update` mutations require you to provide an `id` or `hfid` to identify the object you want to update.
+- `Upsert` mutations do not require you to provide the `id` or the `hfid`, but enough information needs to be provided for the back-end to uniquely identify the node. Typically this means that all the attribute or relationship values need to be provided that make up the `hfid` or `uniqueness_constraints` of the node.
```graphql
mutation {
@@ -166,17 +179,30 @@ mutation {
data: {
name: { value: "myrepop" }, # Attribute
location: { value: "myrepop" }, # Attribute
- account: { id: "myaccount" }, # Relationship One
- tags: [ { id: "my_id" } ]} # Relationship Many
+ account: { hfid: ["my_account"] }, # Relationship One
+ tags: [ { hfid: ["my_tag"] } ]} # Relationship Many
) {
ok
object {
id
+ hfid
}
}
}
```
+#### Delete
+
+For a `Delete` mutation, we have to provide the `id` or the `hfid` of the node as part of the `data` argument.
+
+```graphql
+mutation {
+ CoreRepositoryDelete(data: {hfid: ["myrepo"]}) {
+ ok
+ }
+}
+```
+
## Branch management
In addition to the queries and the mutations automatically generated based on the schema, there are some queries and mutations to interact with the branches.
diff --git a/docs/docs/topics/local-demo-environment.mdx b/docs/docs/topics/local-demo-environment.mdx
index d96c7c2840..98dca32f9c 100644
--- a/docs/docs/topics/local-demo-environment.mdx
+++ b/docs/docs/topics/local-demo-environment.mdx
@@ -28,7 +28,7 @@ It's designed to be controlled by `invoke` using a list of predefined commands.
| **message-queue** | rabbitmq:3.12-management | Message bus based on RabbitMQ |
| **cache** | redis:7.2 | Cache based on Redis, mainly used for distributed lock |
| **infrahub-server** | Dockerfile | Instance of the API server, running GraphQL |
-| **infrahub-git** | Dockerfile | Instance of the Git agent, managing the Git Repository |
+| **infrahub-git** | Dockerfile | Instance of the Task worker, managing the Git Repository |
diff --git a/docs/docs/topics/object-storage.mdx b/docs/docs/topics/object-storage.mdx
index 0676f0ab43..b39a322a01 100644
--- a/docs/docs/topics/object-storage.mdx
+++ b/docs/docs/topics/object-storage.mdx
@@ -15,7 +15,7 @@ At this moment Infrahub supports using local storage, or AWS S3 storage backends
### Local storage
-Infrahub can use local storage as a storage backend. It can be any directory on a filesystem that is attached to the system on which Infrahub runs. The only requirement is that all the Infrahub API servers and Git Agents need access to the filesystem.
+Infrahub can use local storage as a storage backend. It can be any directory on a filesystem that is attached to the system on which Infrahub runs. The only requirement is that all the Infrahub API servers and Task workers need access to the filesystem.
To setup Infrahub to use local storage backend you can use the following configuration:
diff --git a/docs/docs/topics/permissions-roles.mdx b/docs/docs/topics/permissions-roles.mdx
new file mode 100644
index 0000000000..9ef256bccb
--- /dev/null
+++ b/docs/docs/topics/permissions-roles.mdx
@@ -0,0 +1,74 @@
+---
+title: Permissions and Roles
+---
+
+# Roles and permissions
+
+Roles and permissions are essential for controlling user access and behavior in **Infrahub**. Within the platform, they **offer exact control** over what users can see, modify, or control.
+
+The permissions system is split into two main types: **Global** and **Object-specific**. These permissions aid in defining what users are permitted to do on particular system objects or throughout the system.
+
+More information on users authentication, can be found in the [User management and authentication Topic](/topics/auth).
+
+## Overview
+
+Permissions fall into two categories: **Global** and **Object-specific**, while roles act as **convenient bundles** of permissions. To simplify things further, **Account Groups** let you manage permissions for multiple users at once.
+
+- **GlobalPermissions** gives users system-wide rights to perform specific actions. **[See full list of available global permissions](/reference/permissions.mdx#global-permissions).**
+- **ObjectPermissions** are tied to individual objects within Infrahub and control what actions users can take on those objects. **[See full list of available object permissions](/reference/permissions.mdx#object-permissions).**
+- **AccountRoles** are groups of permissions you can assign to accounts.
+- **AccountGroups** allow you to manage permissions for multiple users all at once.
+
+Permissions are allocated to users through groups and roles.
+For more detailed information on this allocation, you can check [Users permissions management Section](/topics/auth.mdx#users-permissions-management).
+
+## Types of permissions
+
+### Global permissions
+
+With a **GlobalPermission**, a user may act on the entire system, not just on particular objects. **A person with the authority to handle accounts, for instance, can do so globally.**
+**The action is blocked** if the required permission is not granted.
+
+:::info Example:
+
+Take the `global:manage_accounts:allow_all` permission:
+
+- **Action**: `manage_accounts`
+- **Decision**: `Allow`
+
+This gives the user the ability to manage all user accounts.
+
+:::
+
+### Object permissions
+
+**ObjectPermission** specifies actions, that apply to a certain kind of object. Actions like create, update, remove, and view are supported. Depending on the kind of object or branch, object permissions may be granted or refused.
+
+**Key features**:
+
+- **Supports wildcards (`*`)** to apply permissions across multiple object types.
+- **Can define different permissions per branch types (default or non-default branches).**
+- **Grants or denies actions based on the assigned permission.**
+
+:::info Example:
+
+Here are some examples of object permissions and their descriptions:
+
+| Identifier | Object Type | Action | Decision | Description |
+|-----------------------------------------------|---------------|---------|-------------|---------------------------------------------------------------------------------------------|
+| `object:*:*:create:allow_other` | `*` (all types)| `any` | `allow_other`| Allows creating any object, but only on non-default branches. |
+| `object:*:*:view:allow_all` | `*` (all types)| `view` | `allow_all` | Allows viewing any object, anywhere, across both default and non-default branches. |
+| `object:Builtin:Tag:update:deny` | `BuiltinTag` | `update`| `deny` | Denies the ability to update any object of type BuiltinTag, across all branches. |
+| `object:*:Generic:view:allow_all` | `*Generic` | `view` | `allow_all` | Allows viewing all objects that contain 'Generic' in their type (example: LocationGeneric, DeviceGeneric) in all namespaces, across all branches. |
+
+:::
+
+## Future developments
+
+The authorization structure for Infrahub is constantly changing. Here are some exciting upcoming features:
+
+- **Attribute-based permissions**: Grant permissions at the attribute level within objects.
+- **Metadata-based permissions**: Use metadata to specify access controls.
+- **Group-based permissions**: Deepen the integration of group memberships for permission assignments.
+
+These new features will make Infrahub's permission system even more powerful and flexible in the future.
diff --git a/docs/docs/topics/repository.mdx b/docs/docs/topics/repository.mdx
index f8c3322234..c9f367a809 100644
--- a/docs/docs/topics/repository.mdx
+++ b/docs/docs/topics/repository.mdx
@@ -23,13 +23,13 @@ See [this topic](/topics/infrahub-yml) for a full explanation of everything that
## Architecture {#architecture}
-The [Infrahub web server](/reference/api-server) will never connect directly with external Git repositories. All interactions between Infrahub and remote Git repositories are handled by the [Git agent](/reference/git-agent). The Git agent(s) can work with any remote Git server that using either `git` or `http` protocols. The Infrahub web server can send commands to the Git agent via our message broker and the Git agent can send data back to the Infrahub web server via GraphQL mutations.
+The [Infrahub web server](/reference/api-server) will never connect directly with external Git repositories. All interactions between Infrahub and remote Git repositories are handled by the [Task worker](/reference/git-agent). The Task worker(s) can work with any remote Git server that using either `git` or `http` protocols. The Infrahub web server can send commands to the Task worker via our message broker and the Task worker can send data back to the Infrahub web server via GraphQL mutations.
-Infrahub stores all of the data that it needs for every remote repository in a directory defined by the `git.repositories_directory` setting in `infrahub.toml`. When the Git agent receives an instruction to update a remote repository, it pulls data from the remote repositories and saves it to the filesystem in the `git.repositories_directory` directory. The Git agent then parses the new data and sends the necessary GraphQL mutations to the Infrahub web server. Infrahub attempts to update `Repository` with any changes in the remote repository several times per minute. Read-only repositories are only updated when specifically requested.
+Infrahub stores all of the data that it needs for every remote repository in a directory defined by the `git.repositories_directory` setting in `infrahub.toml`. When the Task worker receives an instruction to update a remote repository, it pulls data from the remote repositories and saves it to the filesystem in the `git.repositories_directory` directory. The Task worker then parses the new data and sends the necessary GraphQL mutations to the Infrahub web server. Infrahub attempts to update `Repository` with any changes in the remote repository several times per minute. Read-only repositories are only updated when specifically requested.
-Please note that each Git agent must have access to the same directory on the file system so that they can share work among each other.
+Please note that each Task worker must have access to the same directory on the file system so that they can share work among each other.
## Read-only Repository vs. Repository {#read-only-vs-core}
@@ -45,13 +45,13 @@ Updates **to** remote | When merging Proposed Change | No
### Read-only Repository {#read-only-repository}
-Read-only Repositories will only pull data from an external repository into Infrahub and will never push any data to the external repository. A Read-only Repository will pull changes from a single `ref` (branch, tag, or commit) into the Infrahub branch(es) on which it exists. Read-only repositories are not automatically updated. To update a Read-only Repository, you must manually update the `ref` property to a new value, then the Git agent will pull the appropriate commit and create the appropriate objects in Infrahub.
+Read-only Repositories will only pull data from an external repository into Infrahub and will never push any data to the external repository. A Read-only Repository will pull changes from a single `ref` (branch, tag, or commit) into the Infrahub branch(es) on which it exists. Read-only repositories are not automatically updated. To update a Read-only Repository, you must manually update the `ref` property to a new value, then the Task worker will pull the appropriate commit and create the appropriate objects in Infrahub.
See the [guide](/guides/repository) for instructions on pulling changes from read-only repositories in Infrahub.
### Repository {#repository}
-When you create a `Repository`, Infrahub will try to pull every branch defined in the external repository and create an associated Infrahub branch with the same name and matching data according to what is defined in the `.infrahub.yml` configuration file on the particular remote branch. Infrahub will attempt to sync updates from the external repository several times per minute in a background task that runs on the Git agent(s).
+When you create a `Repository`, Infrahub will try to pull every branch defined in the external repository and create an associated Infrahub branch with the same name and matching data according to what is defined in the `.infrahub.yml` configuration file on the particular remote branch. Infrahub will attempt to sync updates from the external repository several times per minute in a background task that runs on the Task worker(s).
Editing a given GraphQL Query, Transform, Artifact Definition, or Schema within Infrahub **will not** result in those changes being pushed to the external repository and **could potentially be overwritten** when Infrahub pulls new commits from the external repository. Infrahub will only push changes to an external repository when a [Proposed Change](/topics/proposed-change) is merged for which the source and destination branch are both linked to branches on the same external repository. In this case, Infrahub will attempt to create a merge commit and push that commit to the destination branch on the external repository.
diff --git a/docs/docs/topics/resource-manager.mdx b/docs/docs/topics/resource-manager.mdx
index 389802e46b..a7435118f2 100644
--- a/docs/docs/topics/resource-manager.mdx
+++ b/docs/docs/topics/resource-manager.mdx
@@ -11,7 +11,7 @@ Examples:
- allocating the next available IP Prefix out of a IP Prefix pool
- allocating the next available IP addresses out of a IP Address pool
- allocating the next available VLAN ID out of a pool of valid VLAN ID's
-- allocating the next available device ID out of a pool of valid Device ID's
+- allocating the next available ASN (Autonomous System Number) out of a number pool
A resource manager in Infrahub allocates resources in a branch agnostic way. When you allocate a resource out of a pool in a branch, then that allocation happens in all the branches.
@@ -22,7 +22,4 @@ Resources can be allocated in 2 different ways:
- Direct allocation: A direct allocation is typically used when you don't need the resource to be related to another node in Infrahub, or if you want establish such a relation at a later time. For example, you want to allocated an IP address out of a pool that is not going to be linked to another node in Infrahub.
- Relationship resource allocation: A resource can be allocated to a relationship of a node, when you create a new node. For example, when you want to create a device and assign an IP address out of a pool to an interface at device creation time.
-## Known limitations
-
-- We only support resource pools for IP Prefixes and IP Addresses, support for other resource pools will come in future releases
-- Direct resource allocations can only happen from the GraphQL API or the Python SDK, support for allocating resources in the web UI will come in a future release.
+See the [guide](/guides/resource-manager) for instructions on creating and using resource manager in Infrahub.
diff --git a/docs/docs/topics/resources-testing-framework.mdx b/docs/docs/topics/resources-testing-framework.mdx
index 3d9fc9295c..d6c6279705 100644
--- a/docs/docs/topics/resources-testing-framework.mdx
+++ b/docs/docs/topics/resources-testing-framework.mdx
@@ -138,7 +138,7 @@ In this output we can see `infrahub-sdk-0.8.1` (0.8.1 being the Infrahub SDK ver
Tests can also run as part of the Infrahub CI pipeline. This is a feature which allows to validate the proper behaviour of a proposed change.
-This means that the Infrahub Git agent will take care of running the `pytest` process on behalf of users after creating a proposed change or updating it with new changes. User defined tests, if found, will be run as part of the CI pipeline and be logged in checks. One check per test is created which allows to see the outcome of it and an optional message that gives more details in case of failure.
+This means that the Infrahub Task worker will take care of running the `pytest` process on behalf of users after creating a proposed change or updating it with new changes. User defined tests, if found, will be run as part of the CI pipeline and be logged in checks. One check per test is created which allows to see the outcome of it and an optional message that gives more details in case of failure.
## How testing work
diff --git a/docs/docs/topics/schema.mdx b/docs/docs/topics/schema.mdx
index 5530d15819..b09c0728ab 100644
--- a/docs/docs/topics/schema.mdx
+++ b/docs/docs/topics/schema.mdx
@@ -91,11 +91,107 @@ The `kind` of a model is generated by concatenating the `namespace` and the `nam
#### Relationship kinds
-- `Generic`: Default relationship without specific significance
-- `Attribute`: Relationship of type Attribute are represented in the detailed view and the list view
-- `Component`: Indicate a relationship with another node that is a component of the current node. Example: Interface is a component to a Device
-- `Parent`: Indicate a relationship with another node that is a parent to the current node. Example: Device is a parent to an Interface
-- `Group`: Indicate a relationship to a member or a subscriber of a group
+- `Generic`: A flexible relationship with no specific functional significance. It is commonly used when an entity doesn't fit into specialized categories like `Component` or `Parent`.
+- `Attribute`: A relationship where related entities' attributes appear directly in the detailed view and list views. It's used for linking key information, like statuses or roles.
+- `Component`: This relationship indicates that one entity is part of another and appears in a separate tab in the detailed view of a node in the UI. It represents a composition-like relationship where one node is a component of the current node.
+- `Parent`: This relationship defines a hierarchical link, with the parent entity often serving as a container or owner of another node. **Parent relationships are mandatory** and allow filtering in the UI, such as showing all components for a given parent.
+- `Group`: Defines a relationship where a node (inheriting from `CoreNode`) is a member or subscriber to a group (inheriting from `CoreGroup`). These relationships appear in the "Manage Groups" form.
+- `Profile`: A special relationship where a node is assigned a profile (inheriting from `CoreProfile`), visible during creation or updates through a "select profile" dropdown.
+
+:::info Complementary relationship
+
+Component and Parent typically belong together:
+The `Component` relationship is typically paired with the `Parent` relationship.
+This ensures a strong relationship in both directions, where the parent node can manage its components, and the component refers back to its parent.
+
+:::
+
+:::warning Cascade deletion
+Relationships of kind `Component` include an implicit `on_delete: cascade`. This means that if you delete a node with a `Component` relationship, the related nodes connected by this relationship will also be deleted.
+:::
+
+:::info Internal Usage
+
+Group and Profile are **internal** relationship:
+The `Group` and `Profile` relationship kinds are internal types and should not be directly used by the user in their schema.
+These are automatically handled by the system for managing memberships and configurations.
+
+:::
+
+To help you understand the relationship types better, here’s an example schema using a real-world model of **Car**, **Person**, **Wheel**, and **Car Group**.
+
+```yaml
+version: "1.0"
+
+nodes:
+ - name: Car
+ namespace: Auto
+ description: "A vehicle used for transportation."
+ attributes:
+ - name: model
+ kind: Text
+ description: "The model of the car."
+ - name: year
+ kind: Number
+ description: "The manufacturing year of the car."
+ - name: license_plate
+ kind: Text
+ unique: true
+ description: "License plate number."
+ relationships:
+ - name: owner
+ peer: AutoPerson
+ kind: Attribute
+ cardinality: one
+ optional: false
+ - name: wheels
+ peer: AutoWheel
+ kind: Component
+ cardinality: many
+
+ - name: Wheel
+ namespace: Auto
+ description: "A wheel of the car, a critical component for movement."
+ attributes:
+ - name: wheel_size
+ kind: Number
+ description: "Size of the wheel in inches."
+ - name: type
+ kind: Text
+ description: "Type of the wheel (e.g., alloy, steel)."
+ relationships:
+ # A wheel must belong to a car, hence the Parent relationship is mandatory
+ - name: car
+ peer: AutoCar
+ kind: Parent
+ cardinality: one
+ optional: false
+
+ - name: Person
+ namespace: Auto
+ description: "A person who may own a car."
+ attributes:
+ - name: first_name
+ kind: Text
+ description: "First name of the person."
+ - name: last_name
+ kind: Text
+ description: "Last name of the person."
+ - name: driver_license_number
+ kind: Text
+ unique: true
+ description: "Driver's license number."
+ relationships:
+ - name: cars
+ peer: AutoCar
+ kind: Component
+ cardinality: many
+ optional: true
+```
+
+- A `Car` node might have an `owner` attribute linking it to a `Person`. This relationship will be visible in the car's detailed view.
+- A `Wheel` is a component of a `Car`, meaning wheels are an essential part of the car. The wheels will be displayed in a separate "Components" tab.
+- A `Car` can have a `ProfileCar` selected during its creation or update. The insurance details appear in the form where you can pick or assign a profile for the car.
Attribute kinds behavior in the UI
@@ -143,18 +239,24 @@ The `kind` of a model is generated by concatenating the `namespace` and the `nam
+::: warning
+
+When you create a relationship of kind Component, automatically the `on_delete` property of the relationship will get set to the value `cascade`. This means that when you delete a node, all the related nodes of that relationship will also be deleted.
+
+:::
+
### Uniqueness Constraints
More complex uniqueness constraints, composed of multiple attributes and/or relationships can be defined at the Node or Generic level with the property `uniqueness_constraints`.
It's possible to define multiple uniqueness constraints and each of them will be evaluated individually.
-In the example below, the node schema `ExampleCar`, `["owner", "model__value"]` guarantee that a car will unique based on the `owner` and the `model` of the car.
+In the example below, the node schema `ExampleCar`, `["owner", "model__value"]` guarantees that a car will be unique based on the `owner` and the `model` of the car.
-`uniqueness_constraints` can be composed of a list of N number of attribute or relationship of cardinality one:
+`uniqueness_constraints` can be composed of a list of N number of attributes or relationships of cardinality one:
-- For an attribute, the valid format is `__value`. *Currently only value is supported but in the future the plan is to allow additional metadata to be used as well.*
-- For a relationship, only the name of the relationship should be provided ``. *Only relationship of cardinality one are supported and the relationship must be mandatory.*
+- For an attribute, the valid format is `__value`. *Currently only value is supported but in the future, the plan is to allow additional metadata to be used as well.*
+- For a relationship, only the name of the relationship should be provided ``. *Only relationships of cardinality `one` are supported and the relationship must be mandatory.*
```yaml {10} showLineNumbers
nodes:
@@ -196,10 +298,10 @@ In the network industry:
In the example below, each `ExamplePerson`, will have a `hfid` composed of his/her `lastname` and `firstname`.
-`human_friendly_id` can be composed of N number of attribute or relationship of cardinality one:
+`human_friendly_id` can be composed of N number of attributes or relationships of cardinality one:
-- For an attribute, the valid format is `__value`. *Currently only value is supported but in the future the plan is to allow additional metadata to be used as well.*
-- For a relationship, the name of the relationship and the name of a unique attribute must be provided `____value`. *Only relationship of cardinality one are supported and the relationship must be mandatory.*
+- For an attribute, the valid format is `__value`. *Currently only value is supported but in the future, the plan is to allow additional metadata to be used as well.*
+- For a relationship, the name of the relationship and the name of a unique attribute must be provided `____value`. *Only relationships of cardinality `one` are supported and the relationship must be mandatory.*
```yaml {4} showLineNumbers
nodes:
diff --git a/docs/docs/tutorials/getting-started/branches.mdx b/docs/docs/tutorials/getting-started/branches.mdx
index 00eba0cf35..fec2f8d442 100644
--- a/docs/docs/tutorials/getting-started/branches.mdx
+++ b/docs/docs/tutorials/getting-started/branches.mdx
@@ -12,7 +12,7 @@ The default branch is called `main`.
To get started, let's create a new **branch** that we'll call `cr1234`.
-You can create a new branch in the frontend by using the button with a `+ sign` in the top right corner, next to the name of the current branch, i.e., `main`.
+You can create a new branch in the frontend by using the button with a `+ sign` in the top left corner, next to the name of the current branch, i.e., `main`.
Branch names are fairly permissive, but must conform to [git ref format](https://git-scm.com/docs/git-check-ref-format). For example, slashes (`/`) are allowed, tildes (`~`) are not.
@@ -65,7 +65,7 @@ Branch names are fairly permissive, but must conform to [git ref format](https:/
## Modify an organization via the UI
-The name of the active branch in the top right corner should now be `cr1234`.
+The name of the active branch in the top left corner should now be `cr1234`.
1. Select `Organization` under Object in the left menu (near the top).
@@ -167,4 +167,4 @@ Go back to the detailed page for the Organization `my-first-tenant`.
For an in-depth understanding of Infrahub's approach to handling differences between branches and merging them, please consult the [proposed change topic](/topics/proposed-change).
-:::
\ No newline at end of file
+:::
diff --git a/docs/docs/tutorials/getting-started/git-integration.mdx b/docs/docs/tutorials/getting-started/git-integration.mdx
index 7098239cd3..b4c1355133 100644
--- a/docs/docs/tutorials/getting-started/git-integration.mdx
+++ b/docs/docs/tutorials/getting-started/git-integration.mdx
@@ -6,7 +6,7 @@ title: Integration with Git
One of the three pillars Infrahub is built on is the idea of having unified storage for data and files. The data is stored in the graph database and the files are stored in Git.
-When integrating a Git repository with Infrahub, the Git agent will ensure that both systems stay in sync at any time. Changes to branches or files in a Git repository will be synced to Infrahub automatically.
+When integrating a Git repository with Infrahub, the Task worker will ensure that both systems stay in sync at any time. Changes to branches or files in a Git repository will be synced to Infrahub automatically.
Please refer to [Repository](/topics/repository) to learn more about it.
@@ -58,7 +58,7 @@ After adding the `infrahub-demo-edge` repository you will be able to see several
:::note Troubleshooting
-If you don't see additional objects under the transformations or `GraphQL Queries`, it's possible that the `Git agent` might not be running anymore.
+If you don't see additional objects under the transformations or `GraphQL Queries`, it's possible that the `Task worker` might not be running anymore.
In this case, you should run `invoke demo.start` first to ensure that everything is working.
diff --git a/docs/docs/tutorials/getting-started/introduction-to-infrahub.mdx b/docs/docs/tutorials/getting-started/introduction-to-infrahub.mdx
index 86e59711f3..d367972c57 100644
--- a/docs/docs/tutorials/getting-started/introduction-to-infrahub.mdx
+++ b/docs/docs/tutorials/getting-started/introduction-to-infrahub.mdx
@@ -17,7 +17,8 @@ During this tutorial we'll mainly use the Frontend, the `infrahubctl` CLI and th
| **infrahubctl** | Command line utility to interact with Infrahub and manage some core objects like the branches or the schema. | `invoke demo.cli-git` |
| **Frontend** | Main User interface | [http://localhost:8000](http://localhost:8000) |
| **API server** | GraphQL and REST API server, primary component to interact with the data. | [http://localhost:8000/graphql](http://localhost:8000/graphql) |
-| **Git agent** | Infrahub agent that manages all content hosted in Git. | --- |
+| **Task manager** | Orchestrator of workflow tasks | --- |
+| **Task worker** | Infrahub agent that manages all content hosted in Git. | --- |
| **Git server** | External Git server like GitHub or GitLab that can host some Git repositories. | --- |
| **GraphDB** | Main database based on neo4j where all information in the graph are stored. | --- |
| **Cache** | Cache based on Redis. Mainly used to support the reservation of shared resources across all components. | --- |
diff --git a/docs/docs/tutorials/getting-started/readme.mdx b/docs/docs/tutorials/getting-started/readme.mdx
index 93438bbee5..15b5e61924 100644
--- a/docs/docs/tutorials/getting-started/readme.mdx
+++ b/docs/docs/tutorials/getting-started/readme.mdx
@@ -79,12 +79,18 @@ Refer to [User management](/topics/auth/) page for more information regarding th
To follow the tutorial you should use the `admin` account but you can try the other accounts too to see how the interface behaves with different permission levels.
-| name | username | password | role |
-| ------------- | --------------- | ------------- | ---------- |
-| Administrator | `admin` | `infrahub` | admin |
-| Chloe O'Brian | `Chloe O'Brian` | `Password123` | read-write |
-| David Palmer | `David Palmer` | `Password123` | read-write |
-| Jack Bauer | `Jack Bauer` | `Password123` | read-only |
+| name | username | password | group |
+| --------------- | --------------- | ------------- | -------------------- |
+| Administrator | `admin` | `infrahub` | Super Administrators |
+| Sue Dough | `sudo` | `Password123` | Administrators |
+| Chloe O'Brian | `cobrian` | `Password123` | Engineering Team |
+| Sofia Hernandez | `shernandez` | `Password123` | Engineering Team |
+| Ryan Patel | `rpatel` | `Password123` | Engineering Team |
+| Jack Bauer | `jbauer` | `Password123` | Operations Team |
+| Emily Lawson | `elawson` | `Password123` | Operations Team |
+| Jacob Thompson | `jthompson` | `Password123` | Operations Team |
+| David Palmer | `dpalmer` | `Password123` | Architecture Team |
+| Olivia Carter | `ocarter` | `Password123` | Architecture Team |
## Access the Infrahub interfaces
diff --git a/docs/sidebars.ts b/docs/sidebars.ts
index 47e20ad177..22ff56b098 100644
--- a/docs/sidebars.ts
+++ b/docs/sidebars.ts
@@ -67,6 +67,8 @@ const sidebars: SidebarsConfig = {
'guides/installation',
'guides/create-schema',
'guides/import-schema',
+ 'guides/menu',
+ 'guides/accounts-permissions',
'guides/groups',
'guides/generator',
'guides/repository',
@@ -102,10 +104,10 @@ const sidebars: SidebarsConfig = {
'topics/groups',
'topics/metadata',
'topics/object-storage',
+ 'topics/permissions-roles',
'topics/version-control',
'topics/proposed-change',
'topics/repository',
- 'topics/schema',
'topics/transformation',
'topics/auth',
'topics/database-backup',
@@ -139,6 +141,7 @@ const sidebars: SidebarsConfig = {
'reference/schema/validator-migration',
],
},
+ 'reference/menu',
{
type: 'category',
label: 'infrahub cli',
@@ -158,6 +161,7 @@ const sidebars: SidebarsConfig = {
'reference/api-server',
'reference/dotinfrahub',
'reference/infrahub-tests',
+ 'reference/permissions',
'reference/schema-validation'
],
},
@@ -308,7 +312,9 @@ const sidebars: SidebarsConfig = {
slug: 'release-notes/infrahub',
},
items: [
- // 'release-notes/infrahub/release-1_0-DRAFT',
+ // 'release-notes/infrahub/release-1_0_1-DRAFT',
+ 'release-notes/infrahub/release-1_0',
+ 'release-notes/infrahub/release-0_16_4',
'release-notes/infrahub/release-0_16_3',
'release-notes/infrahub/release-0_16_2',
'release-notes/infrahub/release-0_16_1',
diff --git a/frontend/app/biome.json b/frontend/app/biome.json
index 67fe8fd929..bf337a6dc0 100644
--- a/frontend/app/biome.json
+++ b/frontend/app/biome.json
@@ -91,8 +91,10 @@
"suspicious": {
"noArrayIndexKey": "off",
"noAssignInExpressions": "off",
- "noConsole": "off",
- "noConsoleLog": "off",
+ "noConsole": {
+ "level": "error",
+ "options": { "allow": ["assert", "error", "info", "warn"] }
+ },
"noDoubleEquals": "off",
"noEmptyBlock": "off",
"noEmptyBlockStatements": "off",
@@ -118,5 +120,13 @@
"attributePosition": "auto",
"bracketSpacing": true
}
+ },
+ "graphql": {
+ "formatter": {
+ "enabled": true
+ },
+ "linter": {
+ "enabled": true
+ }
}
}
diff --git a/frontend/app/package-lock.json b/frontend/app/package-lock.json
index a8405253e9..57fb9fb7da 100644
--- a/frontend/app/package-lock.json
+++ b/frontend/app/package-lock.json
@@ -62,6 +62,7 @@
"react-markdown": "^9.0.1",
"react-paginate": "^8.2.0",
"react-popper": "^2.3.0",
+ "react-resizable-panels": "^2.1.5",
"react-router-dom": "^6.22.3",
"react-simple-code-editor": "^0.13.1",
"react-toastify": "^9.1.3",
@@ -15190,6 +15191,16 @@
}
}
},
+ "node_modules/react-resizable-panels": {
+ "version": "2.1.5",
+ "resolved": "https://registry.npmjs.org/react-resizable-panels/-/react-resizable-panels-2.1.5.tgz",
+ "integrity": "sha512-JMSe18rYupmx+dzYcdfWYZ93ZdxqQmLum3xWDVSUMI0UVwl9bB9gUaFmPbxYoO4G+m5sqgdXQCYQxnOysytfnw==",
+ "license": "MIT",
+ "peerDependencies": {
+ "react": "^16.14.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc",
+ "react-dom": "^16.14.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc"
+ }
+ },
"node_modules/react-router": {
"version": "6.27.0",
"resolved": "https://registry.npmjs.org/react-router/-/react-router-6.27.0.tgz",
diff --git a/frontend/app/package.json b/frontend/app/package.json
index a5202297ff..749d833a50 100644
--- a/frontend/app/package.json
+++ b/frontend/app/package.json
@@ -81,6 +81,7 @@
"react-markdown": "^9.0.1",
"react-paginate": "^8.2.0",
"react-popper": "^2.3.0",
+ "react-resizable-panels": "^2.1.5",
"react-router-dom": "^6.22.3",
"react-simple-code-editor": "^0.13.1",
"react-toastify": "^9.1.3",
diff --git a/frontend/app/src/components/account-menu.tsx b/frontend/app/src/components/account-menu.tsx
index d06493e4ef..acc362f66d 100644
--- a/frontend/app/src/components/account-menu.tsx
+++ b/frontend/app/src/components/account-menu.tsx
@@ -91,7 +91,7 @@ const UnauthenticatedAccountMenu = () => {
return (
@@ -174,7 +174,6 @@ const AuthenticatedAccountMenu = ({