3
 Followers
43
 Likes

Entity/Action Visibility as Friend

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 (16)
29 Aug 2014
Should be merged with: http://www.outsystems.com/ideas/1333/more-granularity-of-public-exposure-of-elements/

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

18 Feb 2015
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.
5 Apr (3 weeks ago)
Merged this idea with 'Inheritance improvement (Protected)' (created on 2018-04-03 13:05:13 by Patrick Baanvinger)
13 Mar 2013
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
18 Aug 2013
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
20 Aug 2013
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
4 Aug 2015
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
5 Aug 2015
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
25 Feb 2016
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
4 Jan 2017

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
10 Nov 2017

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
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
3 Apr (3 weeks ago)

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
4 Apr (3 weeks ago)

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
5 Apr (3 weeks ago)
Merged this idea with 'Add protected access state to actions/entities/etc' (created on 2016-02-25 08:37:24 by Hans Bruins)
views
112
Followers
3