It appears that a view-only permitted cloud user can modify the email content (addressee, title, message body) of a document (invoice, payment, receipt, …) that has the email button as a communication option.
Is this a bug or am I overlooking something?
Your question is not clear because you have not completely described the situation. You have several different permissions possibly involved here. Can you post a screen shot of the user’s permissions? Also, describe more precisely where this email content is being modified and under what circumstances.
A Cloud user has only one permission: Sales Invoices ‘View’.
All other menu options for this user are configured a ‘No access’. See screenshot below
The user selects an invoice from the Sales Invoices list and clicks on the View button on the left of the invoice.
The user clicks on the ‘Email’ button at the top of the displayed invoice.
The user gets a display of the email message with the Cancel and Send buttons enabled.
The mail message could be blank (if no email template has been created for this particular function) or ‘pre-composed’ (if an email template is associated with this function).
In any caae, at present, the user - even with only view permission - can compose a new message or modify a templated message (including modifying the html code) and send it out.
Conclusion: when a cloud user has a View only permission for a particular function, the ‘Send’ button should be disabled so that no message can be send.
One may argue that if a cloud user has the View, Create or View, Create, Delete permission, the user should not be allowed to modify a message resulting from a pre-defined email template. Personally, I think this would be too restrictive as it could be useful or even necessary to apply a ad-hoc change to the pre-defined message for just this particular email.
The functional buttons at the top of a View screen for any transaction are divided into two groups. Those to the left of the vertical separator bar are controlled by permissions. So a user with view-only access cannot edit or clone a transaction. (Cloning would create a transaction.)
Functions to the right of the separator bar apply to the transaction being viewed. There would be no point in disabling the Print button, because the user could simply use a screen capture capability and print the captured image. Likewise, restricting PDF functionality would be just as pointless, because the user could create a PDF of the captured image. And eliminating the ability to Email would not stop the user from sending the same image via email outside the Manager program, using a regular email client.
Your comments about the Email function also contain a misconception. The user you describe is not editing the email template. They are editing content of a new email created from an existing template, which they cannot modify. As stated above, there is no point in limiting their ability to do that, because they can simply send a regular email, attaching a PDF of the image. The only way to prevent a view-only user from taking the actions you are concerned about is to restrict their access to the program to a machine without screen capture or email capability.
Thank you Tut for your clarifying reply.
Indeed there are many ways that a user could ‘bypass’ the built-in communication mechanisms (print, pdf, email) of Manager and it is not - nor can it be - the responsibility of the application to prevent or control the use of alternative means.
However, from a functional point within the application, I do consider that the composition and the dispatch of an email, using the SMTP Credentials from the SMTP Server defined in the application, is a ‘Create’ function beyond what I consider as a mere ‘View-only’ permission.
While I can understand your viewpoint, @EridDK, permissions apply only to specified accounting functional tabs, reports, and settings. They do not apply to methods of communicating or duplicating displays being viewed. (And don’t forget, all access levels include the View option.) Generating an email does not entail creating (or enabling) a new functional tab, a report, or a new setting. Nor does it involve updating or deleting any of those.
It seems the worst thing that could happen is that a view-only user could resend an email with a modified message. But they could do that even if the Send button were disabled. How many customers do you suppose examine message headers in detail to determine whether the SMTP server is correct? For that matter, how is a customer to know what SMTP credentials you have specified. A user could still easily send a modified email message from a valid company domain, attaching a PDF of a captured image. Who would be the wiser? Still worse, if truly determined, they could easily forge modifications of an invoice itself. That is trivial with the simplest PDF editor.
The fact is, permissions protect the company’s business records from unauthorized viewing or modification by restricted users. Nothing can really prevent spurious external communication.
Thank you for your topic-closing comments.
Rather though-provoking thread. Maybe not as closed as it seemed.
IT Security-wise, a number of security control doctrines list security controls that touch on this sort of “Role Based Access Control” (RBAC). Having worked for TLAs (three letter agencies) for years, I can tell you that IT security is about to heat up. NIST 800.53 rev 5 already has a new family of “Supply Chain Verification” controls. This means that IT Security audits and the outcomes will trickle down the entire chain, and NO ONE wants to deal with a supplier who’s software borks their accreditation.
Therefore, would it not be in Manager.IO’s interest to add one or more communications roles for users? I.e., View Messaging Logs, Create Messaging, Publish Templates, Configure Messaging, etc.,
Tut made a valid, sensible point that any user or customer could capture a screen or manipulate a PDF. On the other hand, the system’s security controls, logs and user policies/procedures can save a company’s bacon in court/audits. There are layers of controls, accountability and verification that banks, insurance companies, customers, suppliers, cops, courts and contractors all take into account – and not just after a problem, but for trustworthiness.
I can’t overstate the value of keeping one’s 5h1t coded up TIGHT! I encourage Manager.IO to keep an open mind about security related questions, when users are kind enough to tell you about them for free, instead of having to face down an audit and hire consultants.
1 Like