Setup: Wrongly assigned Security Tokens to scripts in PageSecurity.php

[pakricard]

Hi:

I think some default script security token assignation are wrong, or at least probably not quite standard.

BOM and contracts assigned to petty cash:

There is a Security Token 14 = "Unknown" and used by some scripts. Standard webERP should not be delivered with a "unknown" security token, as it is confusing for first time users.

MRP module: should be accessible to external suppliers? Or should it be an internal module open to "Manufacturing officer" only?

Petty Cash: PcClaimExpensesFromTab should probably be token 1 or 2, and the other ones Petty Cash, as probably most employees will have a petty cash account, but only a few will authorize cash or expenses and set them up.

R

[timschofield]

They do appear to be a bit random Ricard. I am more than happy for you to change them. As for the "Unknown" tokens I seem to remember advocating their removal a very long time ago. I think I remember (but it may be a false memory :) ) that Phil wanted them left at that time, but I can't recall the reasons for that. I would be happy to just remove them.

Tim

[dalers]

There is a Security Token 14 = "Unknown" and used by some scripts.

I see FormDesigner.php is assigned token 14 via PageSecurity.php (and only FormDesigner.php according to [Setup > General > Scripts by Security Tokens Report]), Are there others? I searched all .php files in the project for "14" and it seems (to me) there aren't any directly using token 14.

If only FormDesigner.php uses token 14, then how about changing the description for token 14 from "Unknown" to "Form Designer"?

[dalers]

@pakricard

I think some default script security token assignation are wrong, or at least probably not quite standard.

@timschofield

I am more than happy for you to change them.

@pakricard, if it helps, I will volunteer to create and submit the PR if you create a screenshot of the [Settings > General > Page Security Settings] after setting all the Security Levels to what you think would be good defaults.

You don't need to save the changes to your db (or perhaps you will want to?).

Also we could change the wording on the page to agree with your proposed standard syntax at the same time.

[pakricard]

I am installing a brand new webERP for a side hustle, and I was reporting these issues marked as “setup” thinking on the average user trying to install webERP.

The installation process goes OK without issues, but when you start setting up, it can feel intimidating, and if we supply random or mixed-up data to start with, it can add to the confusion. I ieven doubt myself if I clicked the wrong option during setup, as the randomness of data made me doubt. Imagine a person just coming to webERP for the very first time ;-)

Of course, it is impossible to get it right for everybody after installation, but at least data should be kind of logic, to use it as a standard point.

I already resolved these issues for me (as it is just data on the default DB, not code, and most of them will be options not used), but I guess it will make sense to clear these issues for the next person downloading webERP for the first time and giving it a try.

@dalers : Yes, 14 “unknown” is used by just one script.

Also we could change the wording on the page to agree with your proposed standard syntax at the same time.

That would be great!

@timschofield : As I am setting it up during spare time, I will continue to raise issues labelled as "Setup". I will report things that even if I understand the problem and could fix for me, the new user would have issues understanding or setting it up.

Being said that, the installation procedure with all the pages, check-ups, etc works OK, and it is easy to follow. Thanks to all the people involved!

R

[timschofield]

Thanks Ricard,

The v5.0 installer was a complete rewrite, so was always going to have some glitches making it work across all possible environments. @gggeek did a lot of work sorting out those glitches.

Tim

[dalers]

Looking at which security roles have the petty cash token,

the Accountant role stands out as no other user roles (other than sysadmin) have the Petty Cash token. It seem likely that the Petty Cash token was assigned to so many scripts because it was convenient at the time as the user involved themselves had the Accountant security profile.

Iirc @timschofield once said the out-of-box security scheme is likely not suitable for any company and any company implementing webERP must determine its own unique security strategy. (my aplogies tim if I have mis-paraphrased you).

I suspect creating a consistent and simple out-of-the-box security strategy (user security roles, their security tokens and the script token assignment) will not be trivial. Per Tim's comment, I suggest starting with an example company, its employees and their roles, map employee roles to security roles (creating any "missing" roles), and finally adjust script security role assignments. The process may need to be iterated and the "case study" description would make a great addition to the Security Schema chapter of The Manual.

I'm interested in working the process to create a security system for my fictional Swift Construction Company, but I doubt working I would be doing anything before September.

My offer still stands to work the changes into a commit if someone offers a spec, but I suggest closing this issue after:

1. change name of token 14 from "Unknown" to "Form Designer"
2. change page title on WWW_Access.php from "Access Permissions Maintenance" to "User Role Security Token Assignment Maintenance" per Unify wording regarding security #770.

If having an issue in the system for the larger problem that the security schema as-is doesn't reflect a "typical" company, then I suggest creating a new "out-of-box security schema doesn't reflect typical" company" issue. Resolving this issue will require first defining a "typical" company and then working the process (and either including updating The Manual in the scope of the issue, or creating another issue to update The Manual).

[pakricard]

Hi @dalers

the Accountant role stands out as no other user roles (other than sysadmin) have the Petty Cash token. It seem likely that the Petty Cash token was assigned to so many scripts because it was convenient at the time as the user involved themselves had the Accountant security profile.

My point for Petty cash was that some scripts assigned to "Petty Cash" like ContractBOM.php, ContractCosting.php, Contracts.php, SelectContract.php , etc have nothing to do with Petty Cash module. Maybe, they should be assigned to a new token "Contracts".

1. change name of token 14 from "Unknown" to "Form Designer"
2. change page title on WWW_Access.php from "Access Permissions Maintenance" to "User Role Security Token Assignment Maintenance" per Unify wording regarding security #770.

Both seem OK to me.

Regarding security tokens, probably we need to reassign some, or create new tokens. But an important update should be #761, as it will simplify code, and we would be more granular when assigning rights to scripts and users via security tokens.

Thanks!
R

[dalers]

My point for Petty cash was that some scripts assigned to "Petty Cash" like ContractBOM.php, ContractCosting.php, Contracts.php, SelectContract.php , etc have nothing to do with Petty Cash module.

I agree.

Maybe, they should be assigned to a new token "Contracts"

That could be a solution but without understanding the complete security strategy from the scripts to their security tokens through the user security profiles and finally to actual user roles, I can't say if one token is enough, if there need to be more security tokens because the scripts will be executed by users with different roles (and what those tokens should be called), if perhaps some of the Contracts scripts should be assigned to existing user security roles (e.g. AR Clerk or Accountant), or if perhaps the existing security roles need to be re-factored. My point ;-) was that resolving the bigger issue is probably not trivial and the "best" solution for now (until someone wants to tackle the big issue) might be to only change the name of the Unknown security role.

I agree with issue #761 and removing all hard-coded security tokens, but suspect they exist in the first place because the existing security roles were not sufficient, which points back to a non-trivial overhaul.