Skip to content

[FEATURE REQUEST] Add the role/account information to the user #4605

@jesmrec

Description

@jesmrec

Update:

In the clients, the rol is not so important as the permissions that are granted to such role. Instead of getting the role (admin, space admin, user, user light) would be enough to know the permissions granted to the account. How to get them?

Requesting the following endpoint:

graph/v1.0/me

will return something like:

{
   "displayName" : "Joe Smith",
   "id" : "52037314-d64f-49cb-a0be-1db422d172e9",
   "identities" : [
      {
         "issuer" : "https://mymachine:9200",
         "issuerAssignedId" : "52037314-d64f-49cb-a0be-1db422d172e9"
      }
   ],
   "mail" : "joe@smith.com",
   "onPremisesSamAccountName" : "jsmith",
   "preferredLanguage" : "en",
   "userType" : "Member"
}

the id field is the account id, static and useful to get info about it

Then, requesting

/api/v0/settings/permissions-list

with body:

{
    "account_uuid": "<id>"
}

will get something like:

{
    "permissions": [
        "Event.SpaceMembershipExpired.ReadWrite.own",
        "Event.SpaceDisabled.ReadWrite.own",
        "Event.SpaceDeleted.ReadWrite.own",
        "Groups.ReadWrite.all",
        "Drives.Create.all",
        "ReadOnlyPublicLinkPassword.Delete.all",
        "Event.ShareExpired.ReadWrite.own",
        "Event.SpaceShared.ReadWrite.own",
        "Drives.ReadWriteEnabled.all",
        "Drives.ReadWriteProjectQuota.all",
        "Drives.DeleteProject.all",
        "Event.ShareRemoved.ReadWrite.own",
        "Favorites.List.own",
        "Roles.ReadWrite.all",
        "AutoAcceptShares.ReadWriteDisabled.own",
        "Event.ShareCreated.ReadWrite.own",
        "Language.ReadWrite.all",
        "Drives.List.all",
        "PublicLink.Write.all",
        "Drives.ReadWritePersonalQuota.all",
        "Favorites.Write.own",
        "Settings.ReadWrite.all",
        "Shares.Write.all",
        "Drives.DeletePersonal.all",
        "EmailNotifications.ReadWriteDisabled.own",
        "Drives.ReadWrite.all",
        "Accounts.ReadWrite.all",
        "EmailSendingInterval.ReadWrite.own",
        "Logo.Write.all",
        "Event.SpaceUnshared.ReadWrite.own",
        "Event.PostprocessingStepFinished.ReadWrite.own"
    ]
}

(that example from an admin account)

that returns the level of permissions for the account, no matter which role the user has. Checking the ocis repository, there are some information over that levels in

https://github.com/owncloud/ocis/tree/master/services/settings
https://github.com/owncloud/ocis/tree/master/services/settings/pkg/store/defaults/permissions.go

Instead of saving the role (which permissions could change from an instance to another), the account id could be saved to use it for checking the permissions.

Depending on the backend (oC10/oCIS), a different endpoint should be requested to retrieve user info:

oC10: /ocs/v2.php/cloud/user?format=json
oCIS: /graph/v1.0/me

(when are we getting the difference?)

The current behaviour is checking always /ocs/v2.php/cloud/user?format=json regardless the kind of backend. Here, we have to check which info is retrieved (i guess, the display name) to assure that same info can be obtained from the oCIS endpoint, apart of the account id.

Crazy ideas to polish:

  • Account id to be saved (BD, accounts manager ¿?)
  • Permission list to be saved or requested every time? (iOS gets it after every app restart for all accounts in device, not sure if feasible). Mind performance... - DEFERRED
  • Use case that checks if the user has an specific permission? permission to be stored in data class or enum (or both, given the own and all modifiers? maybe in the future are more relevant). - DEFERRED

The target should be: handle this data, so, the space management operations could be dealt correctly depending on permissions.


18/06/2025

In oCIS, every user has one role. By default, these are the available roles

  • Admin
  • Space admin
  • User
  • User Light

depending on the assigned role, the user will be allowed for a specific set of operations (available in Graph API)

The aim is getting and persisting the user role, that will be useful for Sharing NG and Space management integration.

How to get it:

The following endpoint:

graph/v1.0/me?$expand=appRoleAssignments

will return a json file with some objects and arrays, the relevant is appRoleAssignments that is an array, which unique object (i don't figure out more that one) contains a field appRoleId. That field will help to fetch the name of the role, by sending a POST request to api/v0/settings/roles-list with a payload:

{"bundle_ids":["<appRoleId>"]}

Response's body will include

{
   "bundles" : [
      {
         "displayName" : "User Light",
         "extension" : "ocis-roles",
         "id" : "<appRoleId>",
         "name" : "user-light",
         "resource" : {
            "type" : "TYPE_SYSTEM"
...

for this example, it's a User Light.

Tasks (to review)

  • When a user is logged in, get his/her role and persist it, in case the backed is oCIS, not for oC10.
  • Check where to persist it: database or android system
  • Check somehow if the role changed to keep the value updated (file list?)
  • Optional: adapt the user light detection
  • Optional: some information about the connected user is fetched from ocs/v2.php/cloud/user endpoint, that is an old one coming from oC10. The roles-list endpoint also returns the same info under the new API for oCIS. oC10 should keep the old way.

TASKS

  • Research (if needed)
  • Create branch feature/add_account_id_to_user
  • Development tasks
    • Implement a new use case for getting and saving the account id in the Accounts Manager (GetUserIdAsyncUseCase)
    • Add a new method in the repository (UserRepository)
    • Add a new method in the remote data source (RemoteUserDataSource)
    • Add a new method in the service (UserService)
    • Implement a new operation for getting the account id from backend (GetRemoteUserIdOperation)
    • Add a new method in the local data source (LocalAuthenticationDataSource)
    • Implement unit tests (if needed)
  • Code review and apply changes requested
  • Design test plan
  • QA
  • Merge branch feature/add_account_id_to_user

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions