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

When you have a top level folder that has children and grandchildren folders. The visibilityPermissions get removed on the top folder when you do something to on of their grandchild folders.

Repo.

1. Create this structure
   
2. Assign permisssions
   You give app1_user read permission to app1 folder, app2_user read permission to app2 and app3_user to app3.
3. Verify Applications folder definition
   If you look at the definition of Applications you will see something like this were all three users are listed in the visibilityPermissions permissions.
   
4. Add a folder to one of the grand childs
   
5. Verify Applications folder definition
   
   Now you only see 1 of the users in the visibilityPermissions.

Now if you would log into the studio or call the api as app2_user or app3_user you will receive an error.

It seem that when adding the folder or any item the entire folder structure is being recreated. When this happens it only traverses the current path for permission and does not look at sibling path to preserve.

Lastly, Remove the folder you added and verify applications visibilityPermissions. There are none.

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

I am trying to use handlebar syntax in an xlsx file. I have a nested object and would like to use

{{#each collection1 as |_myItem|}} so later I can refer to _myItem. When I enter this into xlsx i get the error

This is very easy to replicate the error if you use your invoice xlsx project in the playground. All you have to do is change this cell
to use the reference.

JSReport Forum,

I have a excel workbook that is uploaded to jsreport hosted env. That workbook uses handlebar notation to populated rows of data. One of the cells calls a shared function that is located in a shared asset file.

Issue: If the shared asset scope is set to folder the function is not called in the workbook. It only calls the function if the assets scope is global.

Playground link: https://playground.jsreport.net/w/WadeBenz/q2rvuKWn

Other Notes: If I export this and then import onto a local instance of jsreport that does not have authentication running. It will work if the asset is not in a subfolder (directly in the data folder). When looking at the log files this is the error that is entered. At the time of running the report I was logged in as an Admin.

{"_id":"sisL7wX5780zeXRB","timestamp":{"$$date":1725454559501},"state":"error","mode":"standard","creationDate":{"$$date":1725454559510},"modificationDate":{"$$date":1725454561313},"shortid":"wh6DlsE","inheritedReadPermissions":[],"inheritedEditPermissions":[],"$entitySet":"profiles","timeout":180000,"templateShortid":"o9IHrco_s","finishedOn":{"$$date":1725454561245},"error":"Error: Error while executing xlsx recipe\n(because) error when evaluating engine handlebars for template anonymous\n(because) "xlsxSData" helper call failed\n(because) "xlsxSData" helper call failed\n(because) "xlsxSData" helper call failed\n(because) missing helper: "getDateText"\n\n(system-helpers.js line 2006:33)\n\n 2004 | newData.currentCellRef = null\n 2005 |\n> 2006 | const result = optionsToUse.fn(this, { data: newData })\n | ^\n 2007 |\n 2008 | return result\n 2009 | }\n\n(system-helpers.js line 1571:25)\n\n 1569 | newData.outOfLoopTemplates = Object.create(null)\n 1570 |\n> 1571 | return optionsToUse.fn(this, { data: newData })\n | ^\n 1572 | }\n 1573 |\n 1574 | const getLoopItemById = (byTarget, loopItems) => {\n\n","blobName":"path*****/file_ExcelFile/fh79ixtwgaxcdqv.log"}

I need to have folder scope on the asset, since there are several applications that publish reports to this server.

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.

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.

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
   

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.

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.