Launch Week 07 B-Sides Documentation #15
Conversation
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
docs/accounts/org/people.md
Outdated
| ## Last Activity | ||
|
|
||
| The **Last Activity** column displays the most recent date on which a user performed any activity within your organization. This includes interactions such as accessing the organization or any associated workspace, running queries or pipelines in a workspace, or engaging with any other resources under the organization. This timestamp helps track the latest user engagement, offering valuable insights into activity trends and system usage within the organization. |
There was a problem hiding this comment.
What does accessing the organization or any associated workspace mean? what does engaging with any other resources under the organization mean?
docs/accounts/tenant/people.md
Outdated
| ## Last Activity | ||
|
|
||
| The **Last Activity** column represents the most recent date on which any activity was performed by a user within the tenant. This includes any interaction or action initiated by a user, such as logging in, accessing an org / workspace, running a query / pipeline or performing any other activity on any resource under the tenant. The column serves as a timestamp to track the latest user engagement within the tenant, providing insights into user activity and system usage trends. |
There was a problem hiding this comment.
What does accessing an org / workspace mean? what does performing any other activity on any resource under the tenant mean?
docs/workspaces/people.md
Outdated
|
|
||
| ## Last Activity | ||
|
|
||
| The **Last Activity** column shows the most recent date a user performed any activity within your workspace. This includes actions such as accessing the workspace, running queries or pipelines, or interacting with any resources within the workspace. It serves as a useful indicator of user engagement, providing insights into workspace activity trends. |
There was a problem hiding this comment.
what does accessing the workspace mean? interacting with any resources within the workspace ?
There was a problem hiding this comment.
I've re-worded each of the last activity sections to be more explicit around actions that are considered as activity currently.
There was a problem hiding this comment.
To be honest, I think your previous one was better - It was vague, but I dont like the bullets here, and its incomplete anyway. Let's use the previous one for now. I feel like we need to rework this whole page at some point anyway.
docs/integrations/gitlab.md
Outdated
| GitLab Integration configuration management form shows up. Enter the following information: | ||
| - **Handle** for the integration. This handle should be meaningful and must be unique for all integrations in the tenant (including any org-level integrations). | ||
| - **Host** for your GitLab installation which defaults to **gitlab.com**. | ||
| - **Token** to be used by Pipes to discover projects. Please note that the token must be granted `api` access which is required to create and manage webhooks that enables Pipes to keep the mods managed by the integration up-to-date. Pipes supports [user](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), [group](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) or [project](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) access tokens. |
There was a problem hiding this comment.
Are there any specific scopes or permissions required for this integration?
There was a problem hiding this comment.
Do you mean scope for the token? I have added required permissions for the token against the token attribute Please note that the token must be granted api access which is required to create and manage webhooks that enables Pipes to keep the mods managed by the integration up-to-date.
Are you thinking about mentioning the token scope elsewhere?
There was a problem hiding this comment.
is api a scope? If so, that is not clear from the sentence, and saying Please note that the token must be granted the `api ` scope ... would be clearer.
docs/integrations/gitlab.md
Outdated
| - **Token** to be used by Pipes to discover projects. Please note that the token must be granted `api` access which is required to create and manage webhooks that enables Pipes to keep the mods managed by the integration up-to-date. Pipes supports [user](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), [group](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) or [project](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) access tokens. | ||
| - **Token Scope** is an optional section which allows you to further scope a token down to a GitLab group / project. The following cases might require you to configure this section: | ||
| - Using a **Personal Access Token** you need to mention the group / project to be used by Pipes to setup the webhook against. | ||
| - Using a **Group Access Token** and you want to further scope the webhook creation down to a group / project and restrict list of projects accessible to Pipes. |
There was a problem hiding this comment.
Is this a single project? this is confusing. it sounds like it can be a list of projects?? scope the webhook creation down to a group / project and restrict list of projects accessible to Pipes.. Also, it suggests that this can be a group, but isn't that what the 'group scope' is for?
There was a problem hiding this comment.
I added a single Token Scope section similar to the UI, which we are using to further scope a token down to a group / project. The attributes that need to be set are indeed group / project and not token scope.
The pointers outlines the use cases where you might need to use the token scope section as a whole.
I'll be more explicit in what attributes one needs to set in each case to make it less confusing.
There was a problem hiding this comment.
This is confusing to me both in the UI and in the docs. I can't offer a suggestion for working because I don't know how it is meant to work. we may have to discuss this one....
There was a problem hiding this comment.
Valid token type / filter combos are:
- Personal access token = you must also provide a
grouporprojectpath, which we will create the webhook at. It will also provide the "root" that we will search for projects within. - Group access token = you may optionally provide a
grouporprojectpath, at which level which we will create the webhook at. It will also provide the "root" within the group that the access token belongs to where we will search for projects within. - Project access token = you cannot provide any
grouporprojectpath, as the token is already bound to a project, which is a lead node in the GitLab hierarchy. We will create the webhook on this project.
There was a problem hiding this comment.
- In the Group and Personal access token cases - is that
orexclusive or inclusive? Can you provide both agroupandprojectpath? - Can we tell from the token structure which type it is? Should we consider customizing the rest of the screen based on the token type?
There was a problem hiding this comment.
@sidr0cker would need to confirm - I believe it is exclusive and you can provide one, but not the other.
@sidr0cker would also need to confirm RE token structure, but I recall a conversation that indicated we can't tell just by looking at the token.
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
docs/integrations/gitlab.md
Outdated
| GitLab Integration configuration management form shows up. Enter the following information: | ||
| - **Handle** for the integration. This handle should be meaningful and must be unique for all integrations in the tenant (including any org-level integrations). | ||
| - **Host** for your GitLab installation which defaults to **gitlab.com**. | ||
| - **Token** to be used by Pipes to discover projects. Please note that the token must be granted `api` access which is required to create and manage webhooks that enables Pipes to keep the mods managed by the integration up-to-date. Pipes supports [user](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), [group](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) or [project](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) access tokens. |
There was a problem hiding this comment.
is api a scope? If so, that is not clear from the sentence, and saying Please note that the token must be granted the `api ` scope ... would be clearer.
docs/workspaces/people.md
Outdated
|
|
||
| ## Last Activity | ||
|
|
||
| The **Last Activity** column shows the most recent date a user performed any activity within your workspace. This includes actions such as accessing the workspace, running queries or pipelines, or interacting with any resources within the workspace. It serves as a useful indicator of user engagement, providing insights into workspace activity trends. |
There was a problem hiding this comment.
To be honest, I think your previous one was better - It was vague, but I dont like the bullets here, and its incomplete anyway. Let's use the previous one for now. I feel like we need to rework this whole page at some point anyway.
docs/integrations/gitlab.md
Outdated
| - **Token** to be used by Pipes to discover projects. Please note that the token must be granted `api` access which is required to create and manage webhooks that enables Pipes to keep the mods managed by the integration up-to-date. Pipes supports [user](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), [group](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) or [project](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) access tokens. | ||
| - **Token Scope** is an optional section which allows you to further scope a token down to a GitLab group / project. The following cases might require you to configure this section: | ||
| - Using a **Personal Access Token** you need to mention the group / project to be used by Pipes to setup the webhook against. | ||
| - Using a **Group Access Token** and you want to further scope the webhook creation down to a group / project and restrict list of projects accessible to Pipes. |
There was a problem hiding this comment.
This is confusing to me both in the UI and in the docs. I can't offer a suggestion for working because I don't know how it is meant to work. we may have to discuss this one....
|
|
||
| **Workspace** is the minimum level of visibility required for snapshots and is not allowed to be unset. | ||
|
|
||
| Turning off **Anyone with link** will restrict users from sharing snapshots across all workspaces of the tenant. This will also prevent users from accessing snapshots that were shared prior to restricting the same. |
There was a problem hiding this comment.
i dont like 'the same' eg that were shared prior to restricting the same.. I'd rather repeat it - This will also prevent users from accessing snapshots that were shared prior to restricting **Anyone with link**.
docs/accounts/org/people.md
Outdated
| ## Last Activity | ||
|
|
||
| The **Last Activity** column represents the most recent date on which an activity was performed by a user in an organization. This timestamp helps track the latest user engagement, offering valuable insights into activity trends and system usage within the organization. The following actions currently count as user activity for an organization: |
There was a problem hiding this comment.
To be honest, I think your previous one was better - It was vague, but I dont like the bullets here, and its incomplete anyway. Let's use the previous one for now. I feel like we need to rework this whole page at some point anyway.
docs/accounts/tenant/people.md
Outdated
| ## Last Activity | ||
|
|
||
| The **Last Activity** column represents the most recent date on which an activity was performed by a user in the tenant. The column serves as a timestamp to track the latest user engagement within the tenant, providing insights into user activity and system usage trends. The following actions currently count as user activity for a tenant: |
There was a problem hiding this comment.
To be honest, I think your previous one was better - It was vague, but I dont like the bullets here, and its incomplete anyway. Let's use the previous one for now. I feel like we need to rework this whole page at some point anyway.
docs/workspaces/people.md
Outdated
|
|
||
| ## Last Activity | ||
|
|
||
| The **Last Activity** column represents the most recent date on which an activity was performed by a user in a workspace. It serves as a useful indicator of user engagement, providing insights into workspace activity trends. The following actions currently count as user activity for a workspace: |
There was a problem hiding this comment.
To be honest, I think your previous one was better - It was vague, but I dont like the bullets here, and its incomplete anyway. Let's use the previous one for now. I feel like we need to rework this whole page at some point anyway.
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
Preview Available 🚀Commit Author: bob-bot Preview Link: turbot-com-git-docs-pipeslw07b-sides-turbot.vercel.app |
No description provided.