Proposed change - Users ACL (access rights) management

[TarasFilatov]

"ACL management" is a very powerful and flexible feature allowing to assign Users with access to Apps and various resources.

Unlike in many other platforms where there is only a limited selection of user roles and access privileges, in Ethora platform maximum flexibility is offered allowing literally to assign any User on the Net (Server) any access privileges as granularly as required, subject to your own account having enough ACL privileges to do so.

Only downside is that currently ACL management interface looks very technical and confusing. 

We are now making it easier to use and understand as explained below.

 

CURRENT LOOK (OLD DESIGN):

1. In Admin -> Apps, select an App with at least one User:

2. You will see the list of Users below.

3. In the list of Users, click the kebab menu on the right and choose "Edit ACL":

 

4. A modal window for ACL Management will appear:

 

This means you can now assign certain access rights to the User you have selected, in the context of the currently selected App (or in the context of the whole server under Networks section - more on this below). 

On the left you can see the list of App entities you will be assigning the rights to.

For example the row "appUsers" allows your to assign Create, Read, Update, Delete or Administration rights to all of the App Users.

Columns "Create, Read, Update, Delete and Admin" follow the CRUD pattern which is popular in software development, especially in relation to database and API operations:

Quote

CRUD is an acronym for Create, Read, Update, and Delete, which are the four fundamental functions of a database in software development:

• Create: Adds a new record to a database
• Read: Returns records from a database table
• Update: Modifies existing records in the database
• Delete: Removes records from the database 

Respectively, when you tick the box in the intersection of "appUsers" and "Create", this means you are allowing this selected User to Create (or add) other Users under your App. 

Now, this might make sense for some projects, and for some this would be irrelevant as all Users will either "create themselves" by signing up via Login/Sign-up screen or will be programmatically created via API. But in the Admin panel, if "Create" privilege is given, this User will be able to manually add new Users into your App. 

Similarly, Read allows to view the list of Users of the App. You may want to assign this privilege to certain analyst in your team who only needs a read-only access to the list of Users. They will be able to view User accounts and export them via CSV, but will not be able to edit or delete them unless you give them those privileges too.

Update means editing, in this case a certain User's record.

Delete is self-explanatory, 

Remember, these privilege are all given at an Application Level, so if you give your analyst "Read" rights to Users of "MyFirstApp" and then create "MySecondApp", they will not be able to read the list of Users of "MySecondApp" until you provide them with that access.

As an Owner of your Apps you have full ACL privileges to your created Apps automatically, but this is not the case for all other Users.
 

"Admin" privilege

This is a special privilege we have added to CRUD pattern, so in our case it's a "CRUDA" pattern. 

What this means is by giving this privilege, you provide the User with a right to give the same privilege to other Users, or remove it from other Users.

Naturally, be careful with whom you trust with "Admin" access right.

 

Non-applicable privileges

Now, you will notice that certain privileges checkboxes are "greyed out" and disabled. 

This is because they have no utility i.e. non-applicable.

For example, "appSettings" allows you to provide other Users with access to your Admin -> Settings screens of your App. "Create" and "Delete" don't make sense here since you cannot create new Settings screens for an App and you cannot delete them. However you may want to provide another User with either a read-only access to Settings (tick "Read") or both read & write (tick "Read" and "Update"). 

 

Further we are going to go over the new design style and the proposed usability improvements.

[TarasFilatov]

NETWORKS

Another thing we should have explained is the "Networks" section which is probably the most confusing here.

You can think of Network as a server where Ethora Platform is hosted.

Each instance of Ethora Platform is hosted on a server. Technically, there are multiple servers (at least three virtual or physical machines) which form a "Network" to run each instance of Ethora Platform. This is because Ethora uses certain web3 features where a ledger of transactions (e.g. coins, digital collectibles, documents) is tracked on an EVM-compatible (Ethereum) blockchain network, typically a private or L2 network with at least three nodes (for blockchain network resilience and consensus purposes). Technically, it is a good practice to distribute Ethora server infrastructure across different nodes, which could even be hosted by different entities to make the whole system properly distributed and decentralized. You don't have to do that and you don't need to understand all that, but this was a long way to explain why in Ethora we call our backend (or server) infrastructure a "Network".

Now, most projects especially when starting will be working with Ethora Cloud so your "Network" is the standard default infrastructure managed by Ethora/Dappros where potentially hundreds of other Apps by other entities are also running. In this case normally as an App Owner you will have limited to no access to the Network-level (i.e. server-level) ACL settings so that all Apps and projects are protected from network-wide (server-level) actions of others. 

However Enterprise Plan or AWS Marketplace version of Ethora supports a "dedicated" setup where effectively you will have the whole "Network" (or server infra) just to your project(s) without sharing it with others. In such case you will be able to assign your users with Network level ACL privileges. 

 

"

[TarasFilatov]

NEW DESIGN STYLE

The new design style created by our designer Yuliia looks like this below:

 

This is a great improvement style wise. Further below we discuss is there a way to also increase understanding and usability with minor changes to the content here.

 

 

 

 

[TarasFilatov]

Proposed changes are illustrated in the image attached:

1. Window title. Make the title informative, confirm the name of the User to whom settings are applied and confirm in which App context we are applying this. Example: 'John Doe’s access privileges for “Ethora”'

2. Replace "Applications" subtitle with "App level". Add explanation "Here you can assign or remove User’s access rights to certain objects within the current App." under subtitle.

3. Replace "Networks" subtitle with "Server level". Using "Network" is technically more accurate but "Server level" will faster communicate the purpose to the user which is what UI is for. Add explanation: "Here you can assign or remove User’s access to infrastructure level objects, above the context of any Apps. Available for Enterprise Plan." 

4. Rename names of the ACL privileges / objects like so:

App level

• appCreate -> Create apps
• appSettings -> Settings
• appUsers -> Users
• appTokens -> Tokens
• appPush -> Push Notifications
• appStats -> Statistics

Server level

• netStats -> Statistics