Inherited user permissions after importing from cli

WadeBenz

In my deployed environment I have a folder structure like Parent1\Child1. I then have a user or a group (does not matter) that is assigned read permission to Parent1. When I save the permission it then propagates the read permission to child1 and also all the templates in child1. This all seems correct.

On my local machine, which I do not have the same folder structure or users setup. I actually have my reports in a git repo. So I pull down the reports and make a change. I commit the changes to the repo, and that kicks of a build that exports the reports in the data folder to a ******.export file. Now there is a release pipeline job that calls the import api and imports (full) the the reports into folder child1. All of this process work fine.

The issue is that user or group that has read permission to folder Parent1 no longer has access to the templates in Child1. When I look at the templates definitions the permissions arrays are empty. I believe this is because these permission are not setup on my local machine, nor will they ever be.

Is there a API call that I can make after the import that will reapply permission to all of the templates in a folder?

This is the reports json definition when the permission are applied.

{
  "_id": "658ee96ded3f8e290fe16f35",
  "name": "XXXXXX_PDF",
  "engine": "handlebars",
  "recipe": "chrome-pdf",
  "data": {
    "shortid": "U8RewqKQC"
  },
  "shortid": "HXspsxMZzL",
  "chrome": {
    "printBackground": true,
    "marginTop": "0.5in",
    "marginBottom": "1in",
    "marginRight": "0.5in",
    "marginLeft": "0.5in",
    "landscape": true
  },
  "scripts": [
    {
      "shortid": "eVA2uyLwt"
    }
  ],
  "pdfOperations": [
    {
      "type": "merge",
      "templateShortid": "401aVyc",
      "mergeWholeDocument": true
    }
  ],
  "creationDate": "2024-03-08T21:11:00.330Z",
  "modificationDate": "2024-05-14T19:21:40.527Z",
  "readPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "editPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "inheritedReadPermissions": [
    "655647240e547f0c8ce4ad55",
    "djYU1HQqwKkVH0pt",
    "1hu3mVzzCOihZD5k",
    "Xug2ImE3flfCQORu",
    "jiYXyoH85oEE66oo",
    "0OPGx5fyhIAqbYjk"
  ],
  "inheritedEditPermissions": [
    "655647240e547f0c8ce4ad55",
    "1hu3mVzzCOihZD5k"
  ],
  "editPermissionsGroup": [
    "65969a2c1b470b8f062b6eaa"
  ],
  "folder": {
    "shortid": "IZvhxOL"
  }
}

This is the report definition after the import.

{
  "_id": "658ee96ded3f8e290fe16f35",
  "name": "Critical_Date_PDF",
  "engine": "handlebars",
  "recipe": "chrome-pdf",
  "data": {
    "shortid": "U8RewqKQC"
  },
  "shortid": "HXspsxMZzL",
  "chrome": {
    "printBackground": true,
    "marginTop": "0.5in",
    "marginBottom": "1in",
    "marginRight": "0.5in",
    "marginLeft": "0.5in",
    "landscape": true
  },
  "scripts": [
    {
      "shortid": "eVA2uyLwt"
    }
  ],
  "pdfOperations": [
    {
      "type": "merge",
      "templateShortid": "401aVyc",
      "mergeWholeDocument": true
    }
  ],
  "creationDate": "2024-03-08T21:11:00.330Z",
  "modificationDate": "2024-05-15T11:53:28.885Z",
  "readPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "editPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "inheritedReadPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "inheritedEditPermissions": [
    "655647240e547f0c8ce4ad55"
  ],
  "editPermissionsGroup": [
    "65969a2c1b470b8f062b6eaa"
  ],
  "folder": {
    "shortid": "IZvhxOL"
  }

The Ids 655647240e547f0c8ce4ad55 and 65969a2c1b470b8f062b6eaa show up on my local machine. I am assuming those are the users my local dev environment is using and created when I added the report. As you can see the inheritedReadPermissions and inheritedEditPermissions are no longer present.

Thanks

admin

I cannot replicate this so far. Let's try together... I am on the jsreport 4.3.1.

I start jsreport and create the following
folderA -> templateA
userA
and add to folderA readPermissions for userA
and export

Then I start clean jsreport and create the following
folderB -> templateB
userB
and add to folderB readPermissions for userB
then I import the previous export to the folderB

Now Iam checking the folderB -> folderA -> templateA and I see in the inheritedReadPermissions

 "inheritedReadPermissions": [
    "<userA>",
    "<userB>"
  ],

Can you try the same using the studio? Does this work for you as well?

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:

TemplateA

Deployed Machine :

ParentFolder ->FolderB
User has permissions on FolderB.

After Deploy:

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.

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"
}
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"
}
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.
0_1717439224835_upload-4cd12143-b696-40d5-ae4d-98a841fe38a0
Admin User
0_1717439235793_upload-defce948-e454-4a0a-af99-b43faf7286a4
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"
}
0_1717439262334_upload-c452f8ac-efba-48ca-b1c4-5d9a9e7cc445

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.

visibilityPermissions change on my top level folder
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
0_1726145173660_upload-139b5055-9aff-45e9-856b-2542e8662c8c

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 0_1726146144696_upload-6bf27c00-dac8-431f-8721-7e52d82beea6
They see this
0_1726146202574_upload-e81117a1-032a-4bf0-871b-c98933f00a7a
When they click on a report they get a blank page or there is this error when calling the report api. 0_1726153755922_upload-8fc1a6cf-cfa7-41db-b0a9-d7d6fd476150 but this seems misleading.

I can fix the error issues 1 of 2 ways.

In the studio, add any permission to any of the deployfolders and save. This Adds all the visibilityPermissions back.
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