When we create applications and modules, we can set if certain items are public of private. The problem is we have no in between.

• When I make a function public, every espace can use the functionality
• When I make a function private, no espace can use the functionality

What I would like is a setting where I can reuse functionality within the application, but not by eSpaces outside of the application boundary. 

Why?

By using a protected inheritance, I can use a seperate business logic layer and reuse the functionality within my application. But from outside of the application, this part is not a shared resource.

Totally agree on this.

In most cases, you don't want other developers/applications to be able to call your code or use your entities.

Action exposition should not be binary (Exposed/Not Exposed).
This suggestion is for a concept similar to private, protected and public.

The aim would be to define actions that can only be consumed by a specific (group of) eSpace(s).

An example would be crud actions, to isolate this and ensure the whole application uses the same entry point to a crud.

Currently an entity can be either non accessible or accessible for all modules and the CRUD rights need to be carefully configured in the model. 

For multiple technical reasons I get that; though this puts a lot of pressure on the developers/testers to ensure no data is exposed to wrong roles (anyone can make a full data retrieve of a public entity in any module; intended or unintented).

That's why I suggest to add anoption to restrict the entity access via service studio for a pre-defined set of modules. Off course you can hack this as a developer; but at least you can prevent unintended mistakes. 

This one I stole from .Net: things in OutSystems either are private/readonly or public, but in .Net you something in between called internal, where a module can give some other modules more visibility to some elements by using the internal keyword and the InternalsVisibleTo attribute.

There is a similar idea floating about for months..

* YEARS

J.Ja

It would be really great if espaces could have companion / friend / partial espaces, from where private actions could be referenced.

Example: 

1. Espace A has a property where espace B is set as friend espace
2. After publishing espace A, private actions/entities/structures from espace A can be referenced through espace B "Add references" dialog
3. Espace B private actions cannot be referenced from espace A
4. Espace C sees only public actions/entities/structures from espace A

There could be one or many friend espaces, but the main idea is to enable unit testing without resorting to web services and/or test related code ending up to production.

Idea summary:

In addition to Public, Public Readonly [Entities only] and Private states possible for Actions, Entities and Structures, additionally include Protected and Protected Readonly [Entities only] as possible states. 

Protected would ensure that the member is able to be referenced only by other modules within the same Application that the member's owning Module is part of. (Equivalent to being Public to same-application Modules, and Private to those outside of that scope).

Basis:

1. Good architectural design will often lead to the identification of members that have no relevance or use outside of the wider application, but yet must still be referenced by other modules within the application to enable encapsulation.
2. As a result of 1, data integrity can be more greatly assured by limiting the public scope to its intended audience.
3. While there may be fixes that lend themselves towards this end (e.g. assessing the GetEntryEspaceId(), using an APIKey or other key/password method for identifying a query source) they do not seem natural, do not entirely resolve the issue and from the developer context are entirely insecure.

I completely concede that if a rogue application did enter an environment, and start abusing the publically available Actions to start inserting objects left-right and centre, it's a simple matter to find the culprit and disable it. Likewise release management should be assessing these risks before it is pushed into a live stage of the environment lifecycle. However, wouldn't this be a great proactive way to systematically drive this proactively and remove a level of risk?