We need a UI for the users in the vscode extension called with a command, that would allow them to search entries on the instance.

Some kind of autocomplete functionality must be workable I think from the extension. Needs some research.

A cli command will be needed too, that will return dataset in json format and this could be then feeded to the extension.

Flow:

• User chooses the download command
• Display an autocomplete box or whatever vscode provides for this
• User first picks the table (Pending changes of sn-edit/sn-edit#19)
• Only display tables pre-existing in our config table (Up for discussion)
• Then after picking a table, call a different command that would then list all the entries (We will need some kind of limit on what to display at first and then an infinity scroll like stuff, lets talk about our options here)
• After picking one of the entries, run sn-edit download with the table and sys_id to download an entry more here

Blocking PR #12

We need to use something that can escape user input, implementing it ourselves will not be ideal, there can be a lot of edge-cases which we are not able to think about all of them.

The config generation should be done in multiple steps.

• Someone runs command, generate config
• The extension downloads the sample yaml file from here: https://github.com/sn-edit/sn-edit/blob/master/_config/sn-edit.sample.yaml
• After download, we parse the yaml into some kind of object and display choices based on the yaml file
• Everything under the core key is mandatory, so users have to fill out through the UI the following details

  core:
    log_level: info
    rate_limit: 2
    db:
      path: /path/to/db/file
      initialised: false
    rest:
      masked: false
      password: password
      url: https://dev111.service-now.com
      user: admin
      xor_key: randomxorkey
    root_directory: /path/to/scripts/folder/tmp

• Ask the user for each input separately, so first he would set the log level. That can be one of these:
  https://github.com/sn-edit/sn-edit/blob/f0a64fd5ced9f2c9850527f66e0ffcff3032e149/conf/conf.go#L31-L47
  See the strings there. (debug, info etc.)
  The user should pick one in Vscode and this would be written to that value
• Rate limit is a historical option, leave it at 2, optinally it will disappear
• Db path is a path to the database file locally, it should be a valid path.
  If you can pick files in vscode, then we should use that, if not, default of this option is the current workspace path.
  Let the user write the whole path. Only a full path is allowed here.
• After submission, validate if the db path is valid. The folder described should exist, but the file will be automatically created by sn-edit if nonexistent.
• Another bigger topic here are the rest credentials. The user provides a username and password for these so please request that from them through the UI.
  • Show input for username and password
  • Ask for the xor_key, this is used for masking the password so we do not store plaintext values
• The root_directory is also mandatory, ask for it and after submission validate if the directory exists.

We need at least two binaries to be existent on the target platform.

• node
• sn-edit

The second one sn-edit, has to be installed beforehand. Node should be present due to the nature of the vscode.

To avoid repetitive calls to determine the currently edited filename and also to have some generics lets make a core function that would be used throughout the app.

This would also allow us for more flexibility in the future if we would decide to change this at some point.

Functions that we need in core:

• Get the current field name
  If someone is editing script.js which is a script field in some table, then we should have a simple function lets call it getFieldName that would based on the vscode objects determine the current file)
• Get table name
  Detect the current table based on the path we are in, there is some template code available, reuse that with some checks
• Get the scope for current file
  The same as above, from the file path we should be able to determine this without an issue.
  Get sys_id for fields
  This should do something similar, we should be able to read sys_id.txt in our currently edited files folder, which should be present always but introduce some checks for this. The function should return the sys_id or some error if none found.

Implement a feature that would allow users to open the file they are currently editing on their instance.

Also find a suitable keyboard shortcut to make this more easily usable!

Uploading an entry should be possible with a command but also with the option to listen on the "onsave" event of a file that is currently opened and has a valid path to tour workspace.

Two flows here:
Uploading with a command
* Run upload command
* The extension identifies sys_id and table from path and sys_id.txt file
* Calls the sn-edit upload --table tablename --sys_id sys_id command which will upload the entry
* Display a notification about success/failure

One flow in this case

• Upload on save
  • The extension identifies sys_id and table from path and sys_id.txt file
  • Calls the sn-edit upload --table tablename --sys_id sys_id command which will upload the entry
  • Display a notification about success/failure

On the right bottom side we will display the current update set based on the opened file that is currently open in the editor.

If there is no valid update set found, we will not display update set information (like for the config file which makes no apparent sense right?)

• Onclick on this statusbar item, we have a command bound
• After clicking, display a list of other update sets other than the current one and let the user choose a different one
• After the user chooses a different update set, use the sn-edit updateset --set flag to set this new update set as the session default more info here
• Display success/error if update set was set or not and update the bottom right corner display with the newly selected update set (since that would be our new default)

• Display the currently selected default update set for the scope that we are working in.

The scope is always added to the path of the files/entries. This means that if a file is open in the editor, we can determine the scope from the filepath.

Based on this we can call the command sn-edit updateset --list --scope scopename, this will first request the data from the instance and then cache it in the database.

After subsequent calls, the data will be only returned from the database, which is quite instant. The update set name should be displayed in a notification bar or somewhere in the UI where appropiate.

• Update update set based on file changes

If the currently opened file changes (someone switches to a new file), we should check if this new file is in a different scope, if yes, update the update set as described above by calling the command again.

While gathering information, please display some loading bar if technically possible in place of an empty update set name or something that would show the users that we are detecting the current update set.

• Clear update set cache command

Also add a command that would truncate the local cache.
Call it "Clear update set cache", this will be a seaparate command that would call sn-edit updateset --truncate in the background and clear all update set data.

• Set default update set per scope
  Please add a command that would allow users to set a default update set for subsequent entry uploads.

After calling this vscode command, please display a text field, where they could write update set names. After submission, call sn-edit updateset --list --scope scopename --json which gets us a list of currently available update sets for that scope.

After the listing, display these to the user, so they can choose one update set to set as default. If they did choose one, run sn-edit updateset --set --scope scopename --update_set sysidofupdateset, this will set the update set if run.

Display some notification to the user about success/failure.

Check if workspacepath is existent and print out an error if not.

const workspacePath = vscode.workspace.workspaceFolders[0].uri.path;

This path specifically