User restrictions - not consistant across selections

User had limited access to specific cashbook


at cash account summary report
user can see other cashbook which already created by another user

image

This does not constitute access to the cash account. The restricted user cannot create, edit, or delete any transaction in the restricted cash account by seeing a report.

If you define a report period that actually includes transactions, the report does not even show individual transactions, only total inflows and outflows.

The question is whether a restricted user can drill down through those totals, see the list of contributing transactions, and edit one of them.

yes, restricted user able to drill down and editable

Your last two screen shots are not conclusive. How did you get the second one? Was that by clicking Edit or View on one of the transactions in the first screen shot? If so, the restricted user has not gained access.

And what happens if the restricted user tries to enter a new receipt? I suspect only the authorized cash account will be available to them.

2nd screen is when click receipt and payment
1st screen comes from report drill down

Then what point are you making with the second screen shot?

there was no transaction under respective cash account

Then there was no access for the restricted user.

one cash account under that user
but no transaction yet

Based on what you say, one little bit at a time, nothing is wrong.


user permission for user ‘b’
cash accounts ‘b’ only

there was only one transaction under cash accounts ‘b’


at ‘cash account summary’ there was report for cash account ‘a’

user ‘b’ can see report for cash account ‘a’
5
able to drill down, able to edit

there was 2 cash accounts and 2 transactions

if you need backup db, i can send you

You have not shown that User B can do anything you have not granted permission for. By granting permission for the Cash Account Summary, you have granted permission for everything related to it. You cannot be as selective as you apparently want.

The problem here is that Manager lacks consistency in that it initially allows selection of restrictions, but fails to continue that restriction selection process through to other choices

Under “Cash Accounts” it allows specific account selections.
Yet under “Cash Account Summary” there is no specific account selections, only global application, hence the cause for this topic.

If Manager was consistent, it would provide the same dropdown account selection under “Cash Account Summary” as it does for “Cash Accounts”.

Currently the User is being inadvertently mislead, in that, by creating a User with a restricted “Cash Account” it is being assumed that that selected restriction would by default flow to other selections, such as “Cash Account Summary”, but that is not the case.

I am going to make this a bug, due to the inconsistent flow of selections.

I think @lubos may consider this an idea rather than a bug. The program currently works as designed. He has mentioned plans for finer-grained user permissions a few times. And he has said he is working on a new permissions module: User with limited access can access restrict pages or sections. (He did categorize that topic as a bug.)

@Brucanna
Thank you for verifying the issue

That argument could be used for all bugs - the programme is working as designed, it just giving the user the wrong results. If the designed is flawed - then it is a bug. To fix a false process - is not an Idea.

2 Likes

@Brucanna, I disagree. The results are not “wrong.” When I said the program works as designed, I mean it produces the intended results. Specifically, View-Create-Update-Delete permission granted for the Cash Account Summary was intended to allow the user to do any- and everything with the Cash Account Summary. And that’s what it does, superseding the designation for access to a specific cash account.

One can certainly argue that permission control should be finer-grained or that the cash account permission should supersede the report permission. But those are issues of design choices, not bugs in the program. The issue here is that a user made an assumption about how the permission feature works that was not correct. The development history is that the Cash Account Summary was added to the program long after other aspects of the permission structure were set. Allowing full access to other reports might not have the same ramifications of allowing full access to the Cash Account Summary. But behavior is, in fact, consistent: full access to a report means full access as the program is designed. Adding the ability to specify different levels of permitted action for different reports, or allowing limitations set for one tab to influence permissions for another tab automatically would be useful features—hence, my remark about this being an idea rather than a bug. But wishing for additional capability does not make the current one a “false process.”

As things stand if it can be exploited by a user it is a “bug”, the crew know about this for sometime.

hi @Tut
if no permission for user, system should not able to view, edit, update, this is basic understanding from user perspective
so, it’s not an idea to improve
it was definitely a bug

You missed the point, @San_Thida_Myo_Latt. You explicitly gave permission for the user to do everything with the Cash Account Summary. You should read my last post more carefully.