Add a global json flag to all commands.

If this flag set, we would output data in a json structured format for the extension to parse it.

We need to support update set changing.
The question is how to do this.

A per table setup might be not good enough, we can have mixed entries for one table. What I was thinking of is a per-scope setup.

What would this mean?
Well, simply said, every scope would have an update set defined.
I would not rather not determine update sets for scopes automatically. If update set not changed, servicenow will take the default one as a base.

So if you need a different update set, you will have to set it through the CLI interface or config file manually.

Some sample of the idea right now:

# ....
  update_sets:
    - scope: global
      update_set:
        name: Default
        sys_id: 4fc57611db6450108a1758b3ca9619ef
    - scope: x_321437_snc_node
      update_set:
        name: Default
        sys_id: 4fc57611db6450108a1758b3ca9619ef
# ....

We will need to set the current working scope in our config file.
The default is global, if you would download a script from a different scope, edit and upload it back to the instance, we would need to change the scope and then also send a request to update the update set to the specified one in the config.
Any subsequent uploads, would use this update set. What this means is, that we will only set the update set once per scope change, otherwise we will not touch it.

You are free to change the update set any time during the development.

Binary for testing: sn-edit-darwin-amd64

Make it possible to specify a key, which will be used to save the data into the folder.

Right now this is per-default sys_name, which is fine for Script Includes and Business rules, but might not be the case for other tables.

We strive to support as many options as possible, so if the user will be allowed to setup a key for each table, we can be quite flexible in how to provide this.

Refactor the config file, to have a core part, to make this easily configurable in other extensions.

These core props will be required to be present and configured, otherwise sn-edit will not work properly!

Add a command to execute background scripts.

This would allow anyone to run a script from the file specified as an input to the command.

Example:
sn-edit execute --file myscript

And it prints out the results in a plain way, like the instance would, if you would've run it in the background scripts tab.

We could support scopes here of course depending on the use-cases.

Cache the update sets.
The command updateset loads update sets from the instance, but only in the case that there are no cached entries in the database.

If there are some, sn-edit will query the database instead of requesting data from the instance.

This way the command will be much faster in general and also provides more pleasant experience.
Of course sometimes you want to load new update sets from the instance, this can be achieved by adding the --refresh flag while using the updateset command for listing the update sets.

This will force the app, to load update sets from the instance instead.

Add a way to define a scope for the tables, also download entries into their respective scope folders.

We need a command here, to interface with the Servicenow API to make entering a table name more pleasant than to write out the name like "sys_script", rather search for "Business rules".

Proposal:
This would list all tables (name, label, sys_id, scope)
sn-edit dictionary --tables
This would list all fields for a label (name, label, sys_id, scope), must be used in conjunction with the previous command
sn-edit dictionary --table xy --fields

These would be then cached in the db for fast access in the future.

Add a command to force loading this from the instance. For example a flag --instance, that would then request data from the API regardless.
Or option 2, introduce truncate for this data, that way forcing it to GET it from the API.

Plan is to support a more seamless way of integrating with the platform.

Right now we use simple basic authentication for authorization but we would like to support at least one of the oauth flows on-instance.

To be fully compliant with scope interactions, we need to send the sys_id of the scope with every request to the API appended at the end sysparm_transaction_scope=scope_sys_id

Add support for creating a new entry.

There needs to be a way to create a new entry on the instance.

We could go out from the premise of the table config from the configuration file.

So for example for a table called sys_script with the default configuration, we would require the script itself and the sys_name to create a new entry.

We do not really know except of these details on what should we use further and what not.

The execution of this task will be coupled down to a couple of tasks.

1. Run sn-edit create --template --unique_key Something --table sys_script

The unique_key will be mandatory first to generate the files. The unique_key describes also the folder structure that is used during the generation. The template flag is also required, since this will tell sn-edit that we are just generating a placeholder template.

This command should be not called for entries already existing locally or on the instance, otherwise it could lead to unexpected results.

2. Run sn-edit create --unique_key Something --table sys_script

Running a similar command without the --template flag would result in sn-edit trying to create the entry on the instance.

3. After the previous step, the entry would be re-downloaded from the instance

This is for the reason so we have the correct structure locally also together with the sys_id. We could generate sys_id locally, but we would like to avoid collisions and that is why I would like to offload this to the Servicenow instance so we do not have to worry.

We will need to support some kind of migrations due to the various database structure changes that could happen between versions.

We will be using this one here: https://github.com/golang-migrate/migrate