VSCode-HC3 Virtual filesystem extension

[jgab 2,647]

31 minutes ago, Brors94 said:

Still get the same error when saving:

Please login or register to see this link.

Still on the admin user With set credentials with the:
>HC3:configure credentials

on v0.4.3 of the extension

Another thing to look for. The extension first looks for .env and ~/.env and if not found takes the settings.json credentials set with HC3:configure credentials
Do you have some other (non admin) credentials in .env ?

Edit: just saw that you had discovered that...  

 

 

 

So, how useful is this extension?
Some ideas for improvements to make it easier or more useful?

Edited March 29 by jgab

[Brors94 115]

24 minutes ago, jgab said:

Another thing to look for. The extension first looks for .env and ~/.env and if not found takes the settings.json credentials set with HC3:configure credentials
Do you have some other (non admin) credentials in .env ?

Edit: just saw that you had discovered that...  

 

 

 

So, how useful is this extension?
Some ideas for improvements to make it easier or more useful?

Be able to set 2 or more hc3 for me would be nice  
So I can work on both at the same time  

 

[jgab 2,647]

4 minutes ago, Brors94 said:

Be able to set 2 or more hc3 for me would be nice  
So I can work on both at the same time  

Will think about that.


v0.4.5 pushed with a QA inspector view. Under the QA there is a file (QuickApp).hc3qa with some editable info. Can be improved.

[jgab 2,647]

1 hour ago, Brors94 said:

Be able to set 2 or more hc3 for me would be nice  
So I can work on both at the same time  

Ok, I have a plan for implementing multiple HC3's... but it's a quite a lot of code. So, I'm waiting a bit with that.
But already now you can have separate workspaces with their own local .env with credentials pointing to different HC3s

[Brors94 115]

3 minutes ago, jgab said:

Ok, I have a plan for implementing multiple HC3's... but it's a quite a lot of code. So, I'm waiting a bit with that.
But already now you can have separate workspaces with their own local .env with credentials pointing to different HC3s

I will try that
Didnt think of that 😅

[jgab 2,647]

11 minutes ago, Brors94 said:

I will try that
Didnt think of that 😅

Yes, but it will have to run one extension per workspace, duplicate polling the HC3, logging etc.
A single extension handling multiple HC3s would be more efficient - so I have it still on my todo.

[Brors94 115]

6 minutes ago, jgab said:

Yes, but it will have to run one extension per workspace, duplicate polling the HC3, logging etc.
A single extension handling multiple HC3s would be more efficient - so I have it still on my todo.

I have tried it now, Created 2 workspaces, Plua and Plua2.
Made Plua2.code-workspace files for the settings and .env files a placed inside the folders. And renamed the .env file in the user folder so it dosent us that 1. 
The Plua folder still works.
But the new Plua2 gives me 401. And I am 100% sure it is the right IP, Username and Password. Even checked with login out and in again in the browser on that ip to confirm 🤔
Any suggestions? 


 

[jgab 2,647]

Make sure you have added a HC3_PASSWORD=xxxxx to each workspace's .env file. All three env vars must be present for this to work correctly with separate workspaces.
Otherwise you may inherit from the wrong .env file

[Brors94 115]

11 minutes ago, jgab said:

Make sure you have added a HC3_PASSWORD=xxxxx to each workspace's .env file. All three env vars must be present for this to work correctly with separate workspaces.
Otherwise you may inherit from the wrong .env file

Did plua support HC3_HOST=192.168....? xD

Because the extension needs the HC3_URL 🤣
So now it works 😅
 

[jgab 2,647]

I have updated the extension  0.4.7 and also updated the agent skills I posted in another thread so it has skills about the hc3-vfs.
This means that the agent can more easily treat the virtual QA files as normal files for, edit, create, delete, and search and help out when asked.

Edited March 30 by jgab

[jgab 2,647]

v0.4.9 pushed.
-Updating the handling of the filesystem to try and avoid the >100000 files scanned warning. It turns out that it was the Lua Language Server (ex. if you run Sumneko) that started to index the vfs, and then seems to got lured into scanning the whole local disk (/). It hopefully behaves better now, but warnings is still not a big issue... Lua Language Server should be better at handling vfs...
-If you have a local .fqa file you can right click and "Open .fqa File", and a "virtual folder" will be opened in the vscode file explorer where the QA files can be edited, like the remote HC3 vfs.

Edited March 30 by jgab

[m.roszak 773]

23 hours ago, Brors94 said:

Actually I cant edit with the advances user  

Please login or register to see this attachment.

It says on the button below xD 
@m.roszak Is this something you guys can allow? so we can use advanced users for this type of things?

It designed that way, edit will mean full access to API which is blocked for advanced users.

[Brors94 115]

5 hours ago, m.roszak said:

It designed that way, edit will mean full access to API which is blocked for advanced users.

wouldnt it be better with a type of user with api access (but not api access for access management) like a "sub admin" for integreation security wise? 🤔

 

[Neo Andersson 230]

Jan this work is amazing. Really. I think this is the best community help we have encountered so far..
May i ask, as this is a virtual file system, probably push to github won't work. Do you think is there any workaround? Maybe some command??

Edited March 30 by Neo Andersson

[jgab 2,647]

9 hours ago, Neo Andersson said:

Jan this work is amazing. Really. I think this is the best community help we have encountered so far..
May i ask, as this is a virtual file system, probably push to github won't work. Do you think is there any workaround? Maybe some command??

I think I understand what you want, but git is another type of workflow.
You are expected to have local repo where you commit files, and when happy, push them to the remote repo (GitHub).
You don't push individual files directly to github (theoretically we can, but it's fragile approach, where we need the path, it can't change, and we don't know what to do if we have conflicts)

My first thinking was to have a lua comment in the QA files pointing to where it comes from (assuming it already comes from a GitHub repo)
but it's still complex:

• Comments can be deleted or misplaced
• Different files in the same QA could point to different repos (confusion)
• Requires managing GitHub tokens + git operations in the extension = significant scope creep
• If the user renames the file on HC3, the path comment is stale

 

...but if you have some ideas how it would/could work with vfs, lets discuss...

Github and vscode works well with plua. There we can create a vscode workspace with a GitHub repo, we can use vscode to commit files and push to GitHub.
We can also create an fqa and push to the HC3 with
>plua -t uploadQA <filename>
or update individual files on the HC3 with
>plua -t updateQA <filename>

Added a chapter in the first post.

 

Edited March 31 by jgab

[Neo Andersson 230]

4 hours ago, jgab said:

I think I understand what you want, but git is another type of workflow.
You are expected to have local repo where you commit files, and when happy, push them to the remote repo (GitHub).
You don't push individual files directly to github (theoretically we can, but it's fragile approach, where we need the path, it can't change, and we don't know what to do if we have conflicts)

My first thinking was to have a lua comment in the QA files pointing to where it comes from (assuming it already comes from a GitHub repo)
but it's still complex:

• Comments can be deleted or misplaced
• Different files in the same QA could point to different repos (confusion)
• Requires managing GitHub tokens + git operations in the extension = significant scope creep
• If the user renames the file on HC3, the path comment is stale

 

...but if you have some ideas how it would/could work with vfs, lets discuss...

Github and vscode works well with plua. There we can create a vscode workspace with a GitHub repo, we can use vscode to commit files and push to GitHub.
We can also create an fqa and push to the HC3 with
>plua -t uploadQA <filename>
or update individual files on the HC3 with
>plua -t updateQA <filename>

Added a chapter in the first post.

 

Cant we just create a command that
1. Saves the fqa file to pc, to a folder where we already have git running. And the rest can be taken care by VS code -> Github itself?? Just thingking loudly...

I dont want to push this..Its not the end of the world if we won't have this. The extension itself has way more benefits than the github auto push has.




 

[m.roszak 773]

17 hours ago, Brors94 said:

wouldnt it be better with a type of user with api access (but not api access for access management) like a "sub admin" for integreation security wise? 🤔

 

Maybe, but this will mean a lot of additional development on our side.

So, if something needs full access to API admin credentials for now are the way to go.