-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
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
ownandallmodifiers? 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/userendpoint, that is an old one coming from oC10. Theroles-listendpoint 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)
- Implement a new use case for getting and saving the account id in the Accounts Manager (
- Code review and apply changes requested
- Design test plan
- QA
- Merge branch feature/add_account_id_to_user