Out-of-the-Box Security - Needs Work?

[VortecCPI]

I was thinking about reconstructing the entire ACL. My first thought is to create Tokens in line with each Module and Context. That would make it very easy to see and visualize since each Token would exactly match each area of each web page. For example:

Sales - Transactions
Sales - Inquiries
Sales - Maintenance
...
Vendors - Transactions
Vendors - Inquiries
Vendors - Maintenance
Etc...

That would yield an awful lot of Tokens (>36) so I think it might be too complex and tedious for some users. It also does not necessarily align with context of usage from a user's needs and/or perspective.

Surely somebody else has already addressed this issue...

---

After looking at the FrontAccounting fork I see they have done pretty much what my initial thought was. It uses 23 Tokens; one for each Module/Section:

Banking & GL analytics:
Banking & GL configuration:
Banking & GL transactions:
Company setup:
Dimensions configuration:
Dimensions:
Fixed Assets analytics:
Fixed Assets configuration:
Fixed Assets operations:
Inventory analytics:
Inventory configuration:
Inventory operations:
Manufacturing analytics:
Manufacturing configuration:
Manufacturing transactions:
Purchase analytics:
Purchase configuration:
Purchase transactions:
Sales configuration:
Sales related reports:
Sales transactions:
Special maintenance:
System administration:

   

Just some food for thought...

---

Complete ACL structure looks like this:

System administration:
Install/update companies
Install/update languages
Install/upgrade modules
Software upgrades

Company setup:
Company parameters
Access levels edition
Users setup
Point of sales definitions
Printers configuration
Print profiles
Payment terms
Shipping ways
Credit status definitions changes
Inventory locations changes
Inventory movement types
Manufacture work centres
Forms setup
Contact categories

Special maintenance:
Voiding transactions
Database backup/restore
Common view/print transactions interface
Attaching documents
Display preferences
Password changes
Edit other users transactions

Sales configuration:
Sales types
Sales prices edition
Sales staff maintenance
Sales areas maintenance
Sales groups changes
Sales templates
Recurrent invoices definitions

Sales transactions:
Sales transactions view
Sales customer and branches changes
Sales quotations
Sales orders edition
Sales deliveries edition
Sales invoices edition
Sales credit notes against invoice
Sales freehand credit notes
Customer payments entry
Customer payments allocation

Sales related reports:
Sales analytical reports
Sales document bulk reports
Sales prices listing
Sales staff listing
Customer bulk listing
Customer status report
Customer payments report

Purchase configuration:
Purchase price changes

Purchase transactions:
Supplier transactions view
Suppliers changes
Purchase order entry
Purchase receive
Supplier invoices
Deleting GRN items during invoice entry
Supplier credit notes
Supplier payments
Supplier payments allocations

Purchase analytics:
Supplier analytical reports
Supplier document bulk reports
Supplier payments report

Inventory configuration:
Stock items add/edit
Sales kits
Item categories
Units of measure

Inventory operations:
Stock status view
Stock transactions view
Foreign item codes entry
Inventory location transfers
Inventory adjustments

Inventory analytics:
Reorder levels
Items analytical reports and inquiries
Inventory valuation report

Fixed Assets configuration:
Fixed Asset items add/edit
Fixed Asset categories
Fixed Asset classes

Fixed Assets operations:
Fixed Asset transactions view
Fixed Asset location transfers
Fixed Asset disposals
Depreciation

Fixed Assets analytics:
Fixed Asset analytical reports and inquiries

Manufacturing configuration:
Bill of Materials

Manufacturing transactions:
Manufacturing operations view
Work order entry
Material issues entry
Final product receive
Work order releases

Manufacturing analytics:
Work order analytical reports and inquiries
Manufacturing cost inquiry
Work order bulk reports
Bill of materials reports

Dimensions configuration:
Dimension tags

Dimensions:
Dimension view
Dimension entry
Dimension reports

Banking & GL configuration:
Item tax type definitions
GL accounts edition
GL account groups
GL account classes
Quick GL entry definitions
Currencies
Bank accounts
Tax rates
Tax groups
Fiscal years maintenance
Company GL setup
GL Account tags
Closing GL transactions
Allow entry on non closed Fiscal years

Banking & GL transactions:
Bank transactions view
GL postings view
Exchange rate table changes
Bank payments
Bank deposits
Bank account transfers
Bank reconciliation
Manual journal entries
Journal entries to bank related accounts
Budget edition
Item standard costs
Revenue / Cost Accruals

Banking & GL analytics:
GL analytical reports and inquiries
Tax reports and inquiries
Bank reports and inquiries
GL reports and inquiries

[falkoner]

Personally I would be against this. Take GL transactions as an example. I have worked in and managed many accounts departments over more than 35 years, and it is very common to have entering of Payments and Receipts done by different members of staff, likewise with journals and statement matching. One token for all these options would mean all those users had access to all the transactions.

Collections of tokens should represent a job role within the company. We have created some common roles, and allocated tokens to these roles to match an "average company", though I am not sure such a thing exists. Where we have come unstuck, is as you point out, that a number of scripts have the wrong token attached to it. But if that were corrected I would still believe we were on the right lines.

As I said before whenever I am doing a new implementation for somebody I sit down and create a custom ACL for that company. No two of these are the same, though I often use an existing one as a starting point. This isn't a trivial exercise for a company with more than a handful of employees, but as I tell my customers, that is why they need to pay an expert to help them This does mean that I tend to ignore any oddities in the default, when perhaps I should be fixing it.

Tim

[VortecCPI]

(12-06-2017 12:33 AM)falkoner Wrote:  Personally I would be against this. Take GL transactions as an example. I have worked in and managed many accounts departments over more than 35 years, and it is very common to have entering of Payments and Receipts done by different members of staff, likewise with journals and statement matching. One token for all these options would mean all those users had access to all the transactions.

Collections of tokens should represent a job role within the company. We have created some common roles, and allocated tokens to these roles to match an "average company", though I am not sure such a thing exists. Where we have come unstuck, is as you point out, that a number of scripts have the wrong token attached to it. But if that were corrected I would still believe we were on the right lines.

As I said before whenever I am doing a new implementation for somebody I sit down and create a custom ACL for that company. No two of these are the same, though I often use an existing one as a starting point. This isn't a trivial exercise for a company with more than a handful of employees, but as I tell my customers, that is why they need to pay an expert to help them This does mean that I tend to ignore any oddities in the default, when perhaps I should be fixing it.

Tim

Tim,

After more thought and seeing it all laid out I agree with you. User context and rights often has little to do with Module/Section page layouts, just as DB schema often does not coincide with real-world objects. In our case we don't need a lot to get started as our business is run by owners and divided between Procurement/Production and Accounting (AP+AR). We may not even let our salesman owner have access to webERP, though it would be nice if the ACL was tight. He spends all his time in SuiteCRM, which is where he belongs. We may end up updating SuiteCRM from webERP once the integrations are under way.

Again I am out of my comfort zone because I just don't have intimate knowledge of all the page names and how they play and relate in context to Tokens and Roles.

I think the Tokens out of the box are good, as are the Roles, but we just need to get them tightened up.

Thank you for all your help and insight into this issue.

Paul

[VortecCPI]

More observations... We have two Tokens not used anywhere:

   

Should these Tokens be removed from the base install?

Also... Token 14 -- "Unknown" -- Is only assigned to FormDesigner.php and this does not seem correct.

[VortecCPI]

UPDATE...

I have some work to accommodate the Accountant and Inquiries/Order Entry Security Roles. As these are the only Security Roles we require besides System Administrator I am going to stop there and post the results of what I have come up with so others can review and use what I have done. If somebody far more intimate with webERP than I can verify my work perhaps we can incorporate the changes into the trunk prior to the next release.