New System App Module for easy file systems access

[IceOnly]

Migration of microsoft/ALAppExtensions#23225

Now that we have made several clients Universal code ready.
One of the main problems turned out to be the replacement of the file record and the file object (File.Create, File.Exists).
Some of our customers now use Azure Blob Service from the System app. Others don't have a good internet and now use a local microservice with REST API, others use Azure File Shares.
The problem is that every integration is different. I think many other partners will have the same problem.
To simplify access I have adopted the email module and created new file accounts.
With just one codeunit, a developer can now connect to various file services without having to know how they actually work. The code unit "File System" delviers everything taht is needed.

An additional PR contains three connector apps:
microsoft/ALAppExtensions#23225

This Apps will conenct:

• Azure Blob Storage
• Azure File Share
• SharePoint Online

All three service can be access over one unified interface!

New provider in the future could be:

• a OneDrive Provider
• Third Party file services

An example that shows how simple it is to use the new modules can be found here:
https://github.com/IceOnly/BC_FileSystem_Example

But before I go round the whole thing, I'm interested in whether there is any interest in the module at all.

Here are some Screenshots:

I have decided in favour of some restrictions. Paths must not start with a /. The only supported path separator is /. If services that require a \ are to be connected, this must be translated by the connector app.

These restrictions should ensure that the file service can be exchanged without upgrading data.

Assigned Workitems:
Fixes #2418
Fixes AB#559148

[JesperSchulz]

This PR needs some work before the real code review can conducted.

[IceOnly]

@StefanMaron I fixed the most of your findings. Thank you!
Regarding the source table temporary, I would leave it as it is in the email module for now.

[StefanMaron]

• Temporary Property for a TableType = Temorary; Table
  • I can see that this can increase readability so I dont mind it being specified "twice" but in that case it should be done that way everywhere, on all variables and all pages that use those tables.
• There where a few typos and a few other smaller things I missed the first time
• Tested the runmodal with temp tables, seems like its not needed
• Tagged @JesperSchulz twice to get his view as well

But dont get me wrong, those are just minor things :) looks really great!

[JesperSchulz]

A little bit of work on the terminology (will get back with suggestions) and a bug fix, and I think we can merge. Will do some more testing Tuesday, get back to you, and we'll wrap it up 🥳

[JesperSchulz]

Ideally I think all of these objects should have been called "Storage Account" etc., but the renaming will be extensive, so let's settle for File Account. It's not like it's wrong...

[JesperSchulz]

I'm happy with the state of this PR. Now we just need one more from the product group to be happy 😊

[darjoo]

Just the permission fix, otherwise all good.

[darjoo]

Add the following codeunits here and remove their inherent entitlement/permissions.

"External File Storage"
"File Account"
"File Pagination Data"
"File Scenario"

Reason for this is because they're the facade layers and should still be controlled via permissions.
The File Storage permission sets also need to be added to the following, otherwise we will get permission issues when we get a SaaS deployment.
The "File Storage - Read" should be added to src/System Application/App/Permissions/SystemApplicationRead.PermissionSet.al
The "File Storage - Edit" should be added to src/System Application/App/Permissions/SystemApplicationEdit.PermissionSet.al
The "File Storage - View" should be added to src/System Application/App/Permissions/SystemApplicationView.PermissionSet.al
The "File Storage - Objects" should be added to src/System Application/App/Permissions/SystemApplicationObjects.PermissionSet.al

[pri-kise]

@darjoo while you're looking at permissions.
What about entitlements.
a delegated admin has the entitlement for e-mail admin.
Wouldn't it be logical to add the File Storage Admin there, too?

https://github.com/microsoft/BCApps/blob/main/src/System%20Application/App/Entitlements/DelegatedAdminagentPartner.Entitlement.al

[IceOnly]

@darjoo I changed the permissions as mentiod, but i have no "File Storage - View". Do we need one? What is the difference between View and Read? I also added the admin permission to the delegated admin entitelment.

[JesperSchulz]

You PR is strongly inspired by the Email module, which also doesn't have a view permission set. It's fine not to have it.

If you're curious about the intended structure, look at e.g. https://github.com/microsoft/BCApps/tree/main/src/System%20Application/App/Guided%20Experience/permissions

The idea was to have the following permission set hierarchy:

objects (execute permissions for all the objects in the module)
 |
    read (read permissions to tables in module)
     |
        view (permission needed to view the data of the module, which might include other permissions than read)
         |
            edit (permission needed to edit data of the module)
             |
                admin (permissions needed to setup the module)

[StefanMaron]

Sorry to do nit picking here, but there is one last thing I want to bring up once more.

Usage of temporary in variable declarations. I dont care if its used or not if a table has TableType = temporary but if its used, it should be done on all variable declarations, in this PR its not

IMHO its just inconsistent coding.

[IceOnly]

Sorry to do nit picking here, but there is one last thing I want to bring up once more.

Usage of temporary in variable declarations. I dont care if its used or not if a table has TableType = temporary but if its used, it should be done on all variable declarations, in this PR its not

IMHO its just inconsistent coding.

As long as the record is passed via var, temp or not doesn't matter anyway. I added it only to the fascade to make it clear in the Module Fascade Documentation. @JesperSchulz, @darjoo how should I proceed?

[JesperSchulz]

. I dont care if its used or not if a table has TableType = temporary

I don't have a definite answer here. I'm all for consistency, and I definitely prefer to see in the parameter list and parameter name, when a record is temporary - it just makes it easier to understand what's going on, without having to peek on the actual table object to see if it happens to be a temporary one.

Temporary on object level was added a small handful years ago to allow us to have a table object which won't result in breaking schema changes, when changed. We for instance had buffer tables in the system, which only ever were used as temporary tables, but which we couldn't change as the schema was synchronized. That was annoying and hence the temp property was added to help the compiler understand what kind of table we're dealing with here.

Long story short: In my opinion, you should "double specify" temporary. The property simply ensures, that you won't ever store the table in the DB.

However, we do not have firm rules around that (yet). The property was introduced quietly and we never got around to create rules for it.

But I agree with Stefan, that we at least must be consistent - if not everywhere, then at least in the module. So go for being explicit about the temp property in the procedure parameters and parameter names.

[IceOnly]

. I dont care if its used or not if a table has TableType = temporary

I don't have a definite answer here. I'm all for consistency, and I definitely prefer to see in the parameter list and parameter name, when a record is temporary - it just makes it easier to understand what's going on, without having to peek on the actual table object to see if it happens to be a temporary one.

Temporary on object level was added a small handful years ago to allow us to have a table object which won't result in breaking schema changes, when changed. We for instance had buffer tables in the system, which only ever were used as temporary tables, but which we couldn't change as the schema was synchronized. That was annoying and hence the temp property was added to help the compiler understand what kind of table we're dealing with here.

Long story short: In my opinion, you should "double specify" temporary. The property simply ensures, that you won't ever store the table in the DB.

However, we do not have firm rules around that (yet). The property was introduced quietly and we never got around to create rules for it.

But I agree with Stefan, that we at least must be consistent - if not everywhere, then at least in the module. So go for being explicit about the temp property in the procedure parameters and parameter names.

Done.