Repository navigation
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
| } | ||
|
|
||
| filtered := make([]*user.User, 0, len(users)) | ||
| for _, u := range users { |
There was a problem hiding this comment.
I'd try to include some tracing information around here to know how much time we take to gather the information based on the number of users.
Since we don't know how many users the group will have, we might need to perform more than 1000 requests to the gateway here (the infamous "all users" group, for example), so we might need either caching or a worker pool.
| for _, u := range users { | ||
| allowed, err := vault.HasVaultMode(ctx, gatewayClient, u.GetId()) | ||
| if err != nil { | ||
| s.logger.Error().Err(err).Str("event", "filterVaultGrantees").Str("userId", u.GetId().GetOpaqueId()).Msg("could not check vault permission, skipped") |
There was a problem hiding this comment.
I'm for including the origin of the log message (the "filterVaultGrantees"), but I don't think it's an event. There are already events being handled, so it might be confusing.
I don't think we need that information in this case though. The log message should be good enough to point it here. The "event", "filterVaultGrantees" doesn't seem to add any valuable information here.
Just log the error with the log message and the userid.
There was a problem hiding this comment.
Changed to
if inVault {
members = s.filterVaultModeUsers(ctx, gatewayClient, members)
}
|
|
||
| // filterVaultUsers removes the users who do not hold the VaultMode permission. | ||
| // A group can contain such users, because the gateway does not check the group members. | ||
| func (ul *UserlogService) filterVaultUsers(ctx context.Context, gwc gateway.GatewayAPIClient, users []string) []string { |
There was a problem hiding this comment.
Taking into account that this is very similar to the code in the notifications service, can we move it to a common place? The "vault.go" file seems fine if there isn't anything better.
7c60dca to
04f9e15
Compare
| func FilterVaultModeUsers(ctx context.Context, gwc gateway.GatewayAPIClient, userIDs []*user.UserId, onError func(*user.UserId, error)) []*user.UserId { | ||
| ctx, span := trace.SpanFromContext(ctx).TracerProvider().Tracer(tracerName).Start(ctx, "FilterVaultModeUsers") | ||
| defer span.End() | ||
| span.SetAttributes(attribute.Int("vault.users.checked", len(userIDs))) |
There was a problem hiding this comment.
From the docs:
// Note that adding attributes at span creation using [WithAttributes] is preferred
// to calling SetAttribute later, as samplers can only consider information
// already present during span creation.
.Tracer(...).Start(ctx, "FilterVaultModeUsers", trace.WithAttributes(attribute.Int(....)))
For the allowed and failed users, we'll have to add them separately (no changes in the code)
| eg.SetLimit(maxConcurrentChecks) | ||
| for i, id := range userIDs { | ||
| eg.Go(func() error { | ||
| allowed[i], errs[i] = HasVaultMode(ctx, gwc, id) |
There was a problem hiding this comment.
I assume this is fine because each goroutine will write in a different memory address, but I'd rather have some confirmation.
There was a problem hiding this comment.
Yes, it is safe. The code makes both slices at full length before the loop starts, and they never grow. Each goroutine writes only its own index, and eg.Wait() makes the writes visible before the reads. Go 1.22+ gives each loop pass its own i and id.
| if err != nil { | ||
| return nil, err | ||
| } | ||
| if len(s.filterVaultModeUsers(ctx, gatewayClient, []*user.UserId{u})) == 0 { |
There was a problem hiding this comment.
Why not return s.filterVaultModeUsers(ctx, gatewayClient, []*user.UserId{u})), nil?
I'd prefer to return an empty list rather than nil on a successful case.
There was a problem hiding this comment.
Maybe I misunderstood, but we shouldn't return if len==1 and we should go further.
It doesn't matter whether the function returns nil or an empty list because later this will all be reduced to nil anyway
func (s eventsNotifier) ensureGranteeList(ctx context.Context, executant, u *user.UserId, g *group.GroupId, inVault bool) []*user.User {
granteeList, err := s.getGranteeList(ctx, executant, u, g, inVault)
if err != nil {
s.logger.Error().Err(err).Str("event", "ensureGranteeList").Msg("Could not get grantee list")
return nil
} else if len(granteeList) == 0 {
return nil
}
return granteeList
}
- web: the share dialog searches for groups in vault mode. - notifications, userlog: send vault notifications only to the users who hold the VaultMode permission. A group can contain other users. - ocis-pkg/vault: add the shared helpers for the vault checks. - acceptance: a group invitation to a vault resource now succeeds. The gateway change is in owncloud/reva#787. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…embers - Add a scenario outline for a vault resource share to a group: only the group members with the VaultMode permission get an in-app notification and can download the file. The other members get no notification, cannot download the file, and do not see it in the Shares space. - Add a scenario outline for a vault space membership of a group, with the space roles Manager, Space Viewer and Space Editor. Only the group members with the VaultMode permission get the notification and can access the space. The other members cannot download the file and do not see the space in their drive list. - The examples cover the roles Space Admin, Admin, User Light and User. - Assign the role "Space Admin" to Brian in the group share scenario, because the default role has no VaultMode permission. - Add NotificationContext to the apiVault suite. - Fix the pull request number in the changelog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Move the VaultMode recipient filter to ocis-pkg/vault as FilterVaultModeUsers. The notifications and userlog services both use it. - Run the checks in parallel, with at most 10 at the same time, so that a large group does not block the event handler. - Add a tracing span with the number of checked, allowed and failed users. - In the notifications service, check the vault permission before the settings and user lookups, so that a member without the permission costs one call only. - Log a failed check with the user ID only, without the "event" field. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ss when sharing Show a notice in the share form when a group is selected for a vault resource, and add the same information to the "Share with people" help. Signed-off-by: Matteo <matteo.sonnenholzner@kiteworks.com>
04f9e15 to
cd9821a
Compare
Samplers see only the attributes that exist at span start. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The gateway change is in owncloud/reva#787.
Group shares in the vault (Safe), from the user's point of view
The sharer
A group member who has the Safe permission
A group member who does not have the Safe permission
When the group changes after the share exists
When the share is removed or expires
The gateway change is in owncloud/reva#787.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: