Is there a feature request for the plugin? i want ...
# sdf
c
Is there a feature request for the plugin? i want to upload files like my older plugin does where I don't have to start at the root of the file cabinet. I just dont have the time to maintain mine so looking to get it implemented within the current plugin. You can even take my code on github as the work is done for you.
s
I'd echo this and also request that single file upload be made faster. Old tools I used to use could upload a script file in around 1-2 second. Somehow both the CLI and Webstorm are still much slower than that.
c
It could be logging in every time vs keeping you logged in. My plugin had the same issue and netsuite's own people submitted a pull request with the updates so they def know how
s
I vaguely recall the plugin doing some sort of file cabinet search [to find folder id?] before doing the upload as being a big reason for the slowdown?
I'd really like to see the system cache the folder ids used in a project. Posting a file directly to a folder when you already have the internal id results in that 1-2 second response time, methinks.
c
Since they limit to the root of the file cabinet, there shouldn't be that much searching going on. Can't see their code so no idea for certain.
Thats what I did. I cache the ID and use it so it doesn't have to do a ton of work
s
That sounds like a much more performant approach! Go steal @creece’s code @Ali Syed (NS DevTools QA) šŸ™‚
šŸ˜… 2
c
The searching should also be recursive as its a directory structure so the code is probably not the easiest to follow but thats how you traverse the file directory system.
I wish the actual plugin was open source. I'd just do this myself.
šŸ’Æ 1
a
@creece Which plugin version are you using? File upload performance was improved in the latest one.
c
I don't use it at all (right now) because I need specific folder upload capability and not starting at the root FIle Cabinet folder.
I need the ability to set my project root to anywhere I want and then it'll use that root as reference to upload. What is happening now is the root is ALWAYS set to File Cabinet. While honestly, this is probably the best approach, "legacy" clients don't always follow this structure.
The risk of moving the files to the FIle Cabinet root involves a lot of extra work as there could be some broken paths in scripts.
a
Can you give an example? For example with SDF. ACP's files are uploaded under /SuiteScripts Suiteapps - Suiteapp/com.xxxxx.xxx/ And there are other templates folders where user can upload. Trying to understand your use case
c
Lets say I don't want to use suitescripts
I have some random folder somewhere w/ code in it
SDF file upload is not going to work because it goes back to File Cabinet / Suite Scripts.. yes, people SHOULD follow that, but legacy clients and some rebels don't. In that scenario (which is quite often), the SDF File upload will not be able to perform its task due to the directory structure.
s
not to hijack things, but a related feature I've love to see is the ability to map files from source folder locally to some target folder in NS FileCabinet. For example I may want to have something under
node_modules
that I want to upload, but want it to appear in some path other than
node_modules/blahblah/etc/
in the FileCabinet.
c
You aren't hijacking that sounds like exactly what Im after
a
Yes, i understand. Well what i can do is convey this to the relevant people. They can analyse the workflow and decide what to do. File upload follows the same restriction as deploy. As a suitecloud project expects some files under some specific directories. If you try to create a new folder at the same level of /SuiteScripts, the deploy will fail as its against SDF deploy rules. Thats why file upload behaves same. Just out of curiosity, if file upload lets you create and upload files at same directoy level as /SuiteScripts, but deploy doesn't allow that. will that work for you?
šŸŗ 1
c
Right. You (NS) are telling us (the devs) that certain things are against these "new" rules. That is fine for new projects/clients. Older clients didn't always follow this and files need to uploaded elsewhere. So its like you left older clients in the dust for this tool when this feature would solve that completely.
So my claim is there is no need restrict like you're doing. Security by obscurity is not security. If I want to upload or deploy into whatever folder I want I should be able to do that. Whether or not that follows the "best practices" would be on the client I'd think
My plugin did this and has like 15k+ downloads. I've not 1 time ever seen feedback that not restricting a folder was a problem. Thats actually why people use it to this day so I am just trying to get it built into the official one.
a
I have conveyed these concerns, and will update you whenever there is news. Or maybe will setup a meeting with you to understand better the needs.
šŸŗ 1
šŸ‘ 1
s
I think you can feature request for the CLI at least, via the open github repo?