8
 Followers
53
 Likes

Entity/Action Visibility as Friend

Backend
On our radar
Allow 3rd option on Entities, Actions as "Friend" which will make entities and actions visible to all modules within the Espaces Application, but not to other applications.  This will simplify having to keep entities as read-only and then creating actions to do the CRUD operations of the entity.  It will also improve security so that espaces that shouldn't be using these entities won't have visibility of them.
Created on 28 Aug 2014
Comments (26)
Should be merged with: http://www.outsystems.com/ideas/1333/more-granularity-of-public-exposure-of-elements/

J.Ja
The fact that entities expodes via a xif are public to everyone.. *shivers*

Voting for this. This would be very good for unit testing - so you can make actions/entities available in the eSpace of tests, but not to other applications.
Merged this idea with 'Inheritance improvement (Protected)' (created on 2018-04-03 13:05:13 by Patrick Baanvinger)

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.




Merged from 'Inheritance improvement (Protected)' (idea created on 2018-04-03 13:05:13 by Patrick Baanvinger), on 2018-04-05 08:45:35 by Vasco Pessanha

Simliar to
https://www.outsystems.com/ideas/1695/Entity%2fAction+Visibility+as+Friend



Merged from 'Inheritance improvement (Protected)' (idea created on 2018-04-03 13:05:13 by Patrick Baanvinger), on 2018-04-05 08:45:35 by Vasco Pessanha
Merged this idea with 'Add protected access state to actions/entities/etc' (created on 2016-02-25 08:37:24 by Hans Bruins)
Merged this idea with 'Restricted exposition actions.' (created on 2017-11-10 13:54:06 by João Oliveira)

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
Hi,

If you follow the 4 layer architecture (or another approach) then you will have several espaces/modules in 1 application. 
The communication between the layers is done via Public actions/entities.

But everything public is also available outside your application. Sometimes you want this but most of the time not. There are ways to prevent this but they are not 'clean' solutions.

So I propose: a new access state called 'Protected' which means that the action/entity/etc is only vissible in your Application.
After this you will have the states private, public (currently used) and protected (newly added). This will give you more control and now you can build your security critical application in the 4 layer architecture without worrying about 'unwanted reuse' :)

Regards,
Hans



Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha

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.



Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha

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.



Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
Hi,

Complex environments have lots of espaces, extensions. Some extensions are used exclusively by a certain part of the applications. some extension.espaces like richwidgets are used *everywhere*.
Especially with the proposed 4-layer architecture. There is a lot of manual maintenane and checking how espaces and extensions are referred to each other.

The public/private is not really up to par with such environments.

I like to see much improvement in that department.

"Protected" state
==============
Element in protected state is only available to refer in the package/espace it belongs to.
This would benefit extensions you need to have, but only accessable via the espace-wrapper.
other applications need to use the wrapper instead of accessing the extension by themself.
this is per element.

more fine-grained would be
"Selected" state
============
You can choose which espaces are allowed to refer your selected-state elements.
Not sure if this set espace-wide or per element.
per element is really heavy on the outsystems-housekeeping


Merged from 'more granularity of public exposure of elements' (idea created on 2013-03-13 13:04:28 by J.), on 2017-11-10 14:00:20 by Daniel Martins

Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
One of our biggest challenges is that our business objects layer has gotten absolutely massive. We would love to split this into multiple eSpaces so that two developers can work on it at the same time without merging so often or requiring many republishes of consumers. However, to do so would require us to make every entity public + not read only, so that the different eSpaces can all work together. We really need a way to make an entity public + not read only, but only for certain eSpaces, and make it public + read only for the rest.

Basically, I need an equivalent of "protected" or "friends".

J.Ja


Merged from 'Entities - Need protection between "Public" and "Private"' (idea created on 2013-08-18 16:57:02 by Justin James), on 2014-01-24 11:40:04 by Gonçalo Borrêga

Merged from 'more granularity of public exposure of elements' (idea created on 2013-03-13 13:04:28 by J.), on 2017-11-10 14:00:20 by Daniel Martins

Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
100% agreed.




Merged from 'Entities - Need protection between "Public" and "Private"' (idea created on 2013-08-18 16:57:02 by Justin James), on 2014-01-24 11:40:04 by Gonçalo Borrêga

Merged from 'more granularity of public exposure of elements' (idea created on 2013-03-13 13:04:28 by J.), on 2017-11-10 14:00:20 by Daniel Martins

Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
Bump, I need this still :)


Merged from 'more granularity of public exposure of elements' (idea created on 2013-03-13 13:04:28 by J.), on 2017-11-10 14:00:20 by Daniel Martins

Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
I too would love to see this feature.  It is important that Outsystems talk to a number of large customers who have run into this is and gather their input before designing this change.  I would hate to see one or two 'flavors' added (public, private, friends, etc.) without trying to design and implement the best solution for everyone.

Merged from 'more granularity of public exposure of elements' (idea created on 2013-03-13 13:04:28 by J.), on 2017-11-10 14:00:20 by Daniel Martins

Merged from 'Restricted exposition actions.' (idea created on 2017-11-10 13:54:06 by João Oliveira), on 2018-02-26 12:22:12 by Vasco Pessanha

Merged from 'Add protected access state to actions/entities/etc' (idea created on 2016-02-25 08:37:24 by Hans Bruins), on 2018-04-05 08:46:09 by Vasco Pessanha
Merged this idea with 'Restricted Public access entities/functions' (created on 28 May 2018 15:28:18 by Frank Grooten)

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. 



Merged from 'Restricted Public access entities/functions' (idea created on 28 May 2018 15:28:18 by Frank Grooten), on 21 Jun 2018 19:40:53 by Justin James

Changed the category to References




Merged from 'Restricted Public access entities/functions' (idea created on 28 May 2018 15:28:18 by Frank Grooten), on 21 Jun 2018 19:40:53 by Justin James
Merged this idea with 'finegrain "expose as readonly " for the consumers' (created on 17 Jan 2012 10:08:52 by J.)
When setting an entity to public you can only set "expose as readonly" to yes or no.

What I like to see is to be able to grant specifically to espaces wether they can access them as readonly or write also.

for example, you have your datamodel in 1 espace.
the BO-espace is allowed to crud the entity
the FO-moduleX is only allowed to read them
the FO-moduleY is also allowed to crud them



Merged from 'finegrain "expose as readonly " for the consumers' (idea created on 17 Jan 2012 10:08:52 by J.), on 21 Jun 2018 19:42:35 by Justin James
Merged this idea with 'Internal visibility option' (created on 04 Jul 2018 10:33:58 by João Almeida)

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.




This comment was:
- originally posted on idea 'Internal visibility option' (idea created on 04 Jul 2018 10:33:58 by João Almeida)
- merged to idea Entity/Action Visibility as Friend on 02 Aug 2018 10:52:34 by Vasco Pessanha

There is a similar idea floating about for months..




This comment was:
- originally posted on idea 'Internal visibility option' (idea created on 04 Jul 2018 10:33:58 by João Almeida)
- merged to idea Entity/Action Visibility as Friend on 02 Aug 2018 10:52:34 by Vasco Pessanha

* YEARS

J.Ja



This comment was:
- originally posted on idea 'Internal visibility option' (idea created on 04 Jul 2018 10:33:58 by João Almeida)
- merged to idea Entity/Action Visibility as Friend on 02 Aug 2018 10:52:34 by Vasco Pessanha

Changed the category to References




This comment was:
- originally posted on idea 'Internal visibility option' (idea created on 04 Jul 2018 10:33:58 by João Almeida)
- merged to idea Entity/Action Visibility as Friend on 02 Aug 2018 10:52:34 by Vasco Pessanha
views
688
Followers
8