[ADD] connector_sftp: SFTP connections for Odoo

[lasley]

Bringing this one over from LasLabs/odoo-base/connector_sftp for the V10 migration

SFTP Connector

This module allows you to connect & interact with remote SFTP hosts.

This module does not provide functionality on its own, it is meant to provide
an abstract SFTP core to be utilized by other business logic.

Installation

To install this module, you need to:

• Install paramiko
  pip install paramiko

Configuration

SFTP Connectors are configured at the company level, and are available in the
res.company form inside of the SFTP Connectors page.

Usage

Read Remote File

# sftp is a ``connector.sftp`` singleton.
with sftp.open('path/to/remote/file') as file_handler:
    data = file_handler.read()

Write Remote File

# sftp is a ``connector.sftp`` singleton.
with sftp.open('path/to/remote/file', 'w') as file_handler:
    file_handler.write('Some data')

[bealdav]

Hi @lasley
Thanks for your work but have you seen this module https://github.com/OCA/server-tools/tree/9.0/external_file_location ?

It seems features are close but external_file_location seems more generic.

Not sure it's a good thing to duplicate effort ?

porting is there #926

ping @florian-dacosta

[lasley]

Hi @bealdav - I did see that one, albeit after I submitted this one.

While external_file_location does provide a nice Interface/Adapter mechanism and does already include SFTP, I feel it is significantly more than what I need in my use case. It also doesn't do nearly enough, or I just don't understand how to use it well enough.

In my case, I do not have a cron. I require direct programmatic access to a server, with actions being triggered based on specific events. I also need knowledge of the remote directory hierarchy in a few instances.

[lasley]

Oh and TBH the real kicker for me is that I require LGPL. I can't use AGPL in this instance, because I am not releasing the proprietary business logic that the module is used for.

[bealdav]

Thanks for your contribution.

If you think there is too much features in external_file_location it make sense to extract logic (FTP, SFTP and local filestore) with unified api their model data no other features in a separate module. Then external_file_location could depends on it in v10

So you could have the better of the 2 world: low level module but with different solutions (polymorphic) to connect by reusing existing approved modules

Otherwise it'll duplicate contributions on the same topic : which make difficult for users to choose modules.

Concerning license then you could choose LGPL if you want

But if you have a specific needs, may be it must not be put in oca.

I don't want block any contributions, but this ask questions.

my 2 cents

[lasley]

@bealdav - I agree we should use a unified model interface. I will submit a base module to do this within the next day or two.

I think our two implementations can complement each other though. One major difference between our two implementations is that you are using PyFilesystem2, but I am using direct Paramiko. I'll look into additional overhead, but I think I would prefer to keep with just Paramiko instead. I think a lot of other developers would make this choice, and I think we should leave them free to do so.

[bealdav]

Nice, thanks a lot

[yajo]

Dumb question: can't you mount an sftp volume in the host via gvfs, sshfs or whatever, and forget about adding this to Odoo?

[lasley]

Mounting as a file system means that the module I create to interact with that file system is going to be very specific to the way I setup the servers, with authentication bound to the server itself. I don't think this is really scaleable when the EDI connections start getting numerous.

A bit about my use case - we're setting up EDI with a distributed set of partners. Specific files need to be delivered via specific pathways based on specific actions. Sometimes they also need to be received, such as in the instance of an RFQ EDI process that receives responses. Sort of like a mini-MFT platform with built-in workflows basically.

Another interesting thing about adding a base implementation for remote file system interaction-
systems that are not compatible with FUSE would also be supported. An example would be the Red October connector, which uses a strategy interestingly similar to the external_file_location module.

[lasley]

External system interface/adapter submitted in #993

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.