Inherited user permissions after importing from cli

[WadeBenz]

What you have does work. There is a difference between what you have and my scenario. I do not have a userA. Since this would be a development machine without user permissions turned on. The other part is when I do my import I do not have folderB->folderA->templateA. I would have folderB ->templateA.

Dev machine:

1. TemplateA

Deployed Machine :

1. ParentFolder ->FolderB
2. User has permissions on FolderB.

After Deploy:

1. ParentFolder->FolderB -> TemplateA

I have moved the permission up to ParentFolder and that seems to have kept them after deploy.

[admin]

Hm... Still can't replicate it. The dev machine has disabled authentication as yours. I have there just template which I export.

On the other machine, there is a folder and a user that has read permissions there.

{
  "folder": null,
  "name": "folder",
  "creationDate": "2024-05-20T15:00:08.459Z",
  "modificationDate": "2024-05-20T15:00:26.719Z",
  "shortid": "U1so8YY",
  "inheritedReadPermissions": [],
  "inheritedEditPermissions": [],
  "_id": "H1nz2ZuHCnGbo8vF",
  "visibilityPermissions": [
    "Jn7avbeAW1Yi7d0i"
  ],
  "readPermissions": [
    "Jn7avbeAW1Yi7d0i"
  ]
}

I import it to this folder logged as administrator, and the template gets proper inherited permissions.

{
  "name": "template",
  "engine": "handlebars",
  "recipe": "chrome-pdf",
  "shortid": "ioVgBh9qmh",
  "chrome": {
    "printBackground": true
  },
  "creationDate": "2024-05-20T15:00:26.711Z",
  "modificationDate": "2024-05-20T15:00:26.711Z",
  "_id": "TeNTFPCLekOAMOjI",
  "inheritedReadPermissions": [
    "Jn7avbeAW1Yi7d0i"
  ],
  "inheritedEditPermissions": [],
  "content": "aa",
  "folder": {
    "shortid": "U1so8YY"
  }
}

I've tried also with structure ParentFolder->Folder and import there. Still seems to work properly.

[WadeBenz]

I upgraded to 4.3.1 today, I was not able to do it last week. It seems like it is working correctly now. Thank you for the work on trying to track this down. I will monitor it and reply back if there is any change.

[WadeBenz]

After monitoring this for some time, the issue is still present. I have been able to track down more information. I can repo this at will when my pipelines run but have not been able to repo it when it run each step manually. I am not sure if there is a timing issue of some process running when calling the APIs.

1. This is what the folders look like when the process starts.
   
   Parent Folder Definition
   {
   "folder": null,
   "name": "P……….S",
   "creationDate": "2024-05-31T16:09:25.262Z",
   "modificationDate": "2024-06-03T17:40:02.397Z",
   "shortid": "R8-Qj3S",
   "inheritedReadPermissions": [
   "BOuTIw0qUIo6RDI3",
   "kL3nPyPITvqilhZF",
   "jsRcTiQwKehsi1UJ",
   "ybl2OzOqfL7mDykq",
   "IqTLGBw8uiwR6L6C"
   ],
   "inheritedEditPermissions": [],
   "_id": "MYNBxmfiDJhMoGqi",
   "visibilityPermissions": [
   "BOuTIw0qUIo6RDI3",
   "kL3nPyPITvqilhZF",
   "jsRcTiQwKehsi1UJ",
   "ybl2OzOqfL7mDykq",
   "IqTLGBw8uiwR6L6C",
   "6LzYz76iKY3GbBKI",
   "655647240e547f0c8ce4ad55"
   ],
   "readPermissionsGroup": [
   "BOuTIw0qUIo6RDI3",
   "IqTLGBw8uiwR6L6C"
   ]
   }
   de.json definition:
   {
   "folder": {
   "shortid": "bw1qJQu"
   },
   "content": "ogIH0KfQ==",
   "name": "de.json",
   "creationDate": "2024-06-03T17:35:29.079Z",
   "modificationDate": "2024-06-03T17:40:33.969Z",
   "shortid": "_14zYG8",
   "readPermissions": [
   "6LzYz76iKY3GbBKI"
   ],
   "editPermissions": [
   "6LzYz76iKY3GbBKI"
   ],
   "inheritedReadPermissions": [
   "655647240e547f0c8ce4ad55",
   "BOuTIw0qUIo6RDI3",
   "kL3nPyPITvqilhZF",
   "jsRcTiQwKehsi1UJ",
   "ybl2OzOqfL7mDykq",
   "IqTLGBw8uiwR6L6C"
   ],
   "inheritedEditPermissions": [
   "655647240e547f0c8ce4ad55"
   ],
   "_id": "cKAUECqiRbDChiDM"
   }

2. After import of file, but before the removing and adding of language assets. Since the parent folder for de.json is temporary gone while it is importing the compressed file. The assets that were assigned to folder “localization” (“bw1qJQU”) are at the root because the parent is gone until the import finishes.
   
   This is the definition of the language file. But to get it I have to be logged in as an admin. I think this happens because the limited user, although they have access to the asset they do not have access to the “now root folder” because the “localization” folder is being imported.
   cmd that is run: curl --location 'https://serverurl/api/import?targetFolder=CcnQjoV' --header 'Authorization: Basic **==' --form 'files=@"/home/vsts/work/r1/a///export.jsrexport"'
   {
   "folder": {
   "shortid": "bw1qJQu"
   },
   "content": "fQ==",
   "name": "de.json",
   "creationDate": "2024-06-03T17:35:29.079Z",
   "modificationDate": "2024-06-03T17:40:33.969Z",
   "shortid": "_14zYG8",
   "readPermissions": [
   "6LzYz76iKY3GbBKI"
   ],
   "editPermissions": [
   "6LzYz76iKY3GbBKI"
   ],
   "inheritedReadPermissions": [
   "655647240e547f0c8ce4ad55",
   "BOuTIw0qUIo6RDI3",
   "kL3nPyPITvqilhZF",
   "jsRcTiQwKehsi1UJ",
   "ybl2OzOqfL7mDykq",
   "IqTLGBw8uiwR6L6C"
   ],
   "inheritedEditPermissions": [
   "655647240e547f0c8ce4ad55"
   ],
   "_id": "cKAUECqiRbDChiDM"
   }

3. After delete and adding of assets.
   CMD to delete Assets: https://serverurl/odata/assets(cKAUECqiRbDChiDM)
   CMD to Import Asset:
   This is the response I get from the odata/assets call to add the language asset file. I would have thought that the permission would be correct. When I run this manually the permission have the correct arrary.
   {
   2024-06-03T18:41:06.0771117Z '@odata.context': 'https://wa**********.azurewebsites.net/odata/$metadata#assets/$entity',
   2024-06-03T18:41:06.0771685Z '@odata.editLink': "https://wa********.azurewebsites.net/odata/assets('DvveNNhEolza6vuB')",
   2024-06-03T18:41:06.0772027Z '@odata.id': "https://wa************.azurewebsites.net/odata/assets('DvveNNhEolza6vuB')",
   2024-06-03T18:41:06.0772304Z folder: { shortid: 'bw1qJQu' },
   2024-06-03T18:41:06.0778404Z content: "H0KfQ==',
   2024-06-03T18:41:06.0782143Z name: 'de.json',
   2024-06-03T18:41:06.0782376Z creationDate: '2024-06-03T18:41:03.756Z',
   2024-06-03T18:41:06.0782634Z modificationDate: '2024-06-03T18:41:03.756Z',
   2024-06-03T18:41:06.0782845Z shortid: 'XNXjza4',
   2024-06-03T18:41:06.0783042Z readPermissions: [ '6LzYz76iKY3GbBKI' ],
   2024-06-03T18:41:06.0783253Z editPermissions: [ '6LzYz76iKY3GbBKI' ],
   2024-06-03T18:41:06.0783518Z inheritedReadPermissions: [ '655647240e547f0c8ce4ad55' ],
   2024-06-03T18:41:06.0783771Z inheritedEditPermissions: [ '655647240e547f0c8ce4ad55' ],
   2024-06-03T18:41:06.0783987Z _id: 'DvveNNhEolza6vuB'
   2024-06-03T18:41:06.0784089Z
   }

Limited user.

Admin User

Permissions using Admin:
{
"folder": {
"shortid": "bw1qJQu"
},
"content": "gIH0KfQ==",
"name": "de.json",
"creationDate": "2024-06-03T17:54:00.296Z",
"modificationDate": "2024-06-03T17:54:00.296Z",
"shortid": "jN2XNTu",
"readPermissions": [
"6LzYz76iKY3GbBKI"
],
"editPermissions": [
"6LzYz76iKY3GbBKI"
],
"inheritedReadPermissions": [
"655647240e547f0c8ce4ad55"
],
"inheritedEditPermissions": [
"655647240e547f0c8ce4ad55"
],
"_id": "Zgj2zpf3hvATfcLa"
}

4. Add a different group so I can save and permission are back to correct for the limited user
   

[admin]

Thank you for the verbose description.
I understand there is some bad permission propagation happening. Unfortunately, I am afraid I won't be able to figure it out from these steps. The replication is too complicated just for the text description. I've tried to implement it into some script that I could run, but I am not 100% sure what you do already at point 2.

I guess you are too busy to take time and minimize the problem into some runnable repo, right?

[WadeBenz]

I was able to put more time into this. I believe I did find the issue. There was one report that had a read permissions group id coming from the development environment. That group id did not exist on the prod environment. Was this group was removed off of the report it no longer failed when the deployment ran.

[admin]

Now I am not sure what this means for us. Is it a problem we should fix?

[WadeBenz]

I know what fixed the issue, but I cannot reproduce it to. When coming from the development repo we had this in the config.json file for one of of the reports that was going to be imported.
"tenantId": "avisonyoung",
"readPermissions": [
"655647240e547f0c8ce4ad55"
],
"editPermissions": [
"655647240e547f0c8ce4ad55"
],
"inheritedReadPermissions": [
"655647240e547f0c8ce4ad55"
],
"inheritedEditPermissions": [
"655647240e547f0c8ce4ad55"
],
"editPermissionsGroup": [
"65969a2c1b470b8f062b6eaa"
],

The tenantId and user/groupId did not exist on the instance that was being deployed to. As soon as this was removed, the issue not keeping the inherited permissions when away.

Sorry I cannot give more details.

[WadeBenz]

This issue has come up on a daily basis now. I have been able to put more time into figuring out what the actually. There are two things going on.

1. visibilityPermissions change on my top level folder
2. readPermissions, editPermissions and visibilityPermissions are added to each folder/template/asset/ etc from the top level folder down through the path to witch i did the import for the user that the import call was made with.

For item 1 I have this folder structure

Each parent folder has a user account created for it and only has permissions to that folder and its children.

The top level "Applications" folder has this for it definition (config.json) before deployments.
{
"name": "Applications",
"creationDate": {
"$$date": 1715777736383
},
"modificationDate": {
"$$date": 1726115939002
},
"shortid": "Qx9MCxv",
"inheritedReadPermissions": [],
"inheritedEditPermissions": [],
"_id": "XvGvDOEqscuCogy6",
"visibilityPermissions": [
"6LzYz76iKY3GbBKI",
"fTtTHISOtmlBCzeu",
"ZxAV8c66fJ8r9dw6",
"kL3nPyPITvqilhZF"
],
"readPermissions": [
],
"$entitySet": "folders"
}

The users map this way.
fTtTHISOtmlBCzeu - user_parentA
ZxAV8c66fJ8r9dw6 - user_parentB
kL3nPyPITvqilhZF - user_parentC
6LzYz76iKY3GbBKI - Is the Admin user that is doing the deploy. This is issue 2 below. Not sure it matters here.

Now when I run the import command for any of the deploy folders from curl and authenticate by using basic auth. (Please note, this does not happen if I run the import from the studio, more details on that in Item 2 below) Things change for the top level "Applications" folder. Lets say I run it for ParentA/DeployFolder1. When the import is finished my top level Applications folder has this now for its config.
{
"name": "Applications",
"creationDate": {
"$$date": 1715777736383
},
"modificationDate": {
"$$date": 1726115939002
},
"shortid": "Qx9MCxv",
"inheritedReadPermissions": [],
"inheritedEditPermissions": [],
"_id": "XvGvDOEqscuCogy6",
"visibilityPermissions": [
"6LzYz76iKY3GbBKI",
"fTtTHISOtmlBCzeu",
],
"readPermissions": [
],
"$entitySet": "folders"
}

It has removed the visibilityPermssions for the other 2 users of ZxAV8c66fJ8r9dw6 - user_parentB and kL3nPyPITvqilhZF - user_parentC. Now when either of those users log into the studio instead of seeing
They see this

When they click on a report they get a blank page or there is this error when calling the report api. but this seems misleading.

I can fix the error issues 1 of 2 ways.

1. In the studio, add any permission to any of the deployfolders and save. This Adds all the visibilityPermissions back.
2. Open the "Applications" config file in blob storage and add the 2 user ids back to the visibilityPermissions collection. But then I have to restart the server.

This is a huge issue right now. Every time my build/release pipelines run, all applications stop working except for the one being deployed. This happens in every environment and is becoming more and more of an issue for each new application we add. As developers are committing multiple times a day for multiple projects.

For Item 2. When the import is run from the studio, it looks like the user is authenticated by a cookie because a authorization header is not passed. But when called by using a curl command you have to pass Authorization header. When you do this, the user that is being authenticated is getting added to all three of the permission groups listed above( readPermissions, editPermissions and visibilityPermissions). Even though the user is a an admin. It does not seem correct that the admin user should be assigned to these. Why is this happening? It seems like some object in the code is getting setup differently if you are using basic auth or being authorized by a cookie. And then that object is being used to assign or not assign permissions to these groups. I could work around this and not care if the admin user has access to each folder/asset/template individually. But if I was to remove the user as an admin, the account would still have access to all templates. Now it would be an issue

[WadeBenz]

This is now the same issue as https://forum.jsreport.net/topic/3297/visibilitypermissions-permission-on-folder-not-preserved-if-changes-are-made-to-grandchildren-folders