[
https://issues.apache.org/jira/browse/OFBIZ-12380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443367#comment-17443367
]
Pierre Smits edited comment on OFBIZ-12380 at 11/14/21, 3:35 PM:
-----------------------------------------------------------------
Bon après-midi Jacques,
Good question. There is a long story and a short one as an answer to the first
question. Keep in mind: the auditor userloginID is an example of a user with
generic view permissions.
The short one is: no, not to add and edit forms.
The longer: If all is well, the overview screen should present all the data
from the various (related and applicable entities) as information.
The various edit forms show editable fields (including those triggering ajax
requests), and buttons and such to trigger other requests. Each of these
triggered requests (when only having a view permission) will show an error:
# to the user, which is the first annoyance (it may lead to that user
burdening others in the organisation in order to get the permission not
allowed under a policy);
# in the log, which (hopefully) trigger the devops team to investigate. In
this case, a waste of (precious) time, because a user with only the view
permission should not be able to trigger such.
Answer to the second (are there other profiles - as in permission groups?? -
having access to this resource):
Yes, have a look at seed and demo datasets. But the minimum: those with create
and update permissions regarding the accounting component.
Answer to the third question (are there other profiles having access to other
resources: for sure, see seed and demo datasets.
Answer to implied question (should an auditor have more higher - as in
create/update permissions than users with view permissions):
That is a policy question, and I would say, based on a contract between the
internal organisation and the organisation of the user with the auditor
role/view permissions. But, based on personal experiences (as an intern at a
CPA firm, and as a financial controller later on, and as a customer of a CPA),
I have never experienced a moment where the 'auditor' would need to have access
to create/edit functions - screens/forms/etc - to have changes persisted. The
report their findings (often with suggested corrections) and someone in the
internal organisation implement those changes. Which are then checked by the
'auditor'.
was (Author: pfm.smits):
Bon après-midi Jacques,
Good question. There is a long story and a short one as an answer to the first
question. Keep in mind: the auditor userloginID is an example of a user with
generic view permissions.
The short one is: no, not to edit screens.
The longer: the various edit screens show editable fields (including those
triggering ajax requests), and buttons and such to trigger other requests. Each
of these triggered requests (when only having a view permission) will show an
error:
# to the user, which is the first annoyance (it may lead to that user
burdening others in the organisation in order to get the permission not
allowed under a policy);
# in the log, which (hopefully) trigger the devops team to investigate. In
this case, a waste of (precious) time, because a user with only the view
permission should not be able to trigger such.
Answer to the second (are there other profiles - as in permission groups?? -
having access to this resource):
Yes, have a look at seed and demo datasets. But the minimum: those with create
and update permissions regarding the accounting component.
Answer to the third question (are there other profiles having access to other
resources: for sure, see seed and demo datasets.
Answer to implied question (should an auditor have more higher - as in
create/update permissions than users with view permissions):
That is a policy question, and I would say, based on a contract between the
internal organisation and the organisation of the user with the auditor
role/view permissions. But, based on personal experiences (as an intern at a
CPA firm, and as a financial controller later on, and as a customer of a CPA),
I have never experienced a moment where the 'auditor' would need to have access
to create/edit functions - screens/forms/etc - to have changes persisted. The
report their findings (often with suggested corrections) and someone in the
internal organisation implement those changes. Which are then checked by the
'auditor'.
> User with only VIEW permission should not see 'editInvoice' screen/form
> -----------------------------------------------------------------------
>
> Key: OFBIZ-12380
> URL: https://issues.apache.org/jira/browse/OFBIZ-12380
> Project: OFBiz
> Issue Type: Improvement
> Components: accounting
> Affects Versions: Trunk
> Reporter: Pierre Smits
> Assignee: Pierre Smits
> Priority: Major
> Labels: permissions
>
> Currently, when a user has only view permissions, as demonstrated in trunk
> demo with userId = auditor, he/she/they can access the header of an invoice.
> This shows a form with edit capabilities.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
