Question for the group. When is comes to custom extensions and using version upgrades, I constant run into the issue have having to always go back to the service.ss files in the file cabinet and enable permissions manually for the new version. Is there a better way to do this with the ExtentsionDevelopment tools?

Hey @Eric Schultz I always do this manually as well. There is no setting or configuration to set these values from the Dev Tools. Something you could explore is using SDF to deploy it since you can set there the properties of your records, I'm not sure if this allow you to set the permissions of a file. It could be worth asking on #C42JX79UZ

Thanks for the reply @eminero. I thought about the SDF route, but always considered that approach more of a SuiteApp deployment approach and not for a custom extension for SuiteCommerce

Correct, I do not use SDF for SuiteCommerce Customizations and probably neither the NetSuite team uses for that purposes, Anyways here is an article about it: https://developers.suitecommerce.com/get-started-with-the-suitecloud-development-framework-sdf-and-suitecommerce.html

Thanks for the link. At this point I think the SDF route is ultimately more work then the standard custom Extension Deployment process and manually updating permissions

Can you succinctly capture your problem and use case? I can raise an enhancement request

@Steve Goldberg this is related to elevating permissions on a service, whenever you update the version of the extension or you move it from SB to Production, you have to manually look for the service file on the file cabinet and then set the right role. This is something pretty easy, however when you have many extensions with elevated permissions and you are not the original developer, you will just get a permission error on the site because you do not have any clue about that elevated permission. A good enhancement would be having a way to set the

config.json

, if you need to execute a specific service(s) with a specific role, in that way every time you deploy and activate, that would be performed automatically.

You mean manifest.json right?

Oh, that would be a better place, you are right, I was thinking about an entry on a

Configuration/setting.json

but the

manifest.json

is the right one.

"elevatedPermissions": {

"files": [

{path: "Modules/Main/SuiteScript/MyService1.js" role: roleId1},

{path: "Modules/Main/SuiteScript/MyService2.js" role: roleId2},

{path: "Modules/Main/SuiteScript/MyService3.js" role: roleId3},

]

}

Something like the above.

@Steve Goldberg I think @eminero captured the scenario / solution I was looking for very well. Just to reiterate if we could within a custom extensions manifest define the Permissions settings such as "Enabled", "Execute as Role" "Run Script without login" etc for the extension, it would be a huge improvement for extension devs that are taking advantage of versioning our extensions. Any time there is an upgrade, even a hot-fix, if the version number changes, we have to make sure we go back and update permissions for ALL services .ss files with that extension or things could break.

I created the issue 🙂

The only difference from @eminero last solution in the manifest would be a global config instead of a per service one. Because we dont know any of the internal ids for the files in the cabinet yet, it might be more difficult to specify a role for each one. If it was a global setting for the whole extension it could look like this

"assets": {
    "img": {
        "files": []
    },
    "fonts": {
        "files": []
    },
    "services": {
        "files": [
            "services/StudentProgram.Service.ss"
        ]
    }
},
'permissions": {
   "roleid": 15,
   "isenabled": true,
   "runWithoutLogin": false
}
"configuration": { ...

😅 I think we would need specificity if this were to get passed security review

@Steve Goldberg thank you and I appreciate it. If this some how comes to be... I owe you a beer at the next SuiteWorld

And yes I picked up on the fact that not knowing role IDs will be tricky; I suspect the devs might kick this back because of that

I would argue with sec review that this config only applies to the .ss files associated with this version of the extension

But all service files in the extension with the same permissions?

yes.

😬

no dice?

I am not a dev

then i guess back to the drawing board on how to specify each one

I added a separate role per service because by default they are executed as

customer center

role and the ideal scenario is that you create your own role for the specific data you want to access. After the file creation the dev tools should check the path and then see what was the role setup, I'm assuming they will be able to figure it out the file id haha. thanks guys!