Thread Closed 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Purchasing security
12-08-2012, 08:09 PM
Post: #1
Purchasing security
It seems that recently commits are being made that roll back the security systems within the purchasing system. It is now possible to skip through most of the security that Rob implemented a few years ago.

Purchasing is a part of a business where fraud happens a lot, and whilst the added security may be a pain it is worth it to the business.

I do feel that even if we are not entitled to a discussion on this, at the very least an announcement should have been made that this was happening so that people can be prepared. Its very bad (and very worrying) that security measures are removede without a discussion or even an announcement.

Thanks
Tim
Find all posts by this user
12-09-2012, 02:40 PM
Post: #2
RE: Purchasing security
Hi Tim:

As usual when these problems arise, probably the best option is to have a config flag ("Use the purchasing security system (Y/N)") so both approaches are ready to be used.

Probably a one-man operation does not need all the security, but a company implementation does need it (well, it should be a must).

I will not upgrade to latest version if we can't control purchasing as we used to do, but I guess we need more information about these changes. What do you exactly mean by "most of the security system"? Which areas are affected by these changes?

Regards,
Pak Ricard
Find all posts by this user
12-09-2012, 06:16 PM (This post was last modified: 12-09-2012 06:33 PM by phil.)
Post: #3
RE: Purchasing security
I think I understand what you mean Tim - although your explanation is not very clear.

In fact, I have already made some changes to the code (that you may not have seen) that I committed recently that I think you are referring to.

The code in question allows a user who would be entitled to receive goods to click a link at the end of an authorised purchase order entry or update, that automatically receives the whole of the purchase order (to the extent that there are balances still to receive) and automatically populates a supplier invoice with the received GRNs from that order (now received). This short circuits the processing where a users is effectively entering an invoice at the time the goods arrive and where there is no separation of duties between purchasing/receiving goods and invoice entry. The user must have permission to do all three to accomplish this. In smaller businesses this is quite common and was a complaint leveled at webERP.

That complaint is valid no more :-)

I think what I've done - retains all the controls we had for proper separation of duties, but also allows for the small business scenario too.

Of course it is not my intention to undo good work. Had I thought to change or undo some of the controls then of course I would have announced it - but this is not my intention!!

Do let me know if I have introduced a problem! Tim, your careful review of my work is great and I would encourage you to air your views and any potential pitfalls or technical matters on the mailing list (which you do have moderated access to - due to ongoing abuse) - or here.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
12-09-2012, 07:36 PM
Post: #4
RE: Purchasing security
Hi Phil: Thanks for your detailed reply. So, upgrading version should not be a problem, then? Things can be worked with the same workflow?

Regards,
Pak Ricard
Find all posts by this user
12-09-2012, 08:30 PM
Post: #5
RE: Purchasing security
(12-09-2012 06:16 PM)phil Wrote:  I think I understand what you mean Tim - although your explanation is not very clear.

In fact, I have already made some changes to the code (that you may not have seen) that I committed recently that I think you are referring to.
[/quote

You mean hard coding the security token into the script? This doesn't work as can be seen in SelectOrderItems.php. The security schema can and does get changed leaving the hard coded security tokens useless. In fact worse than useless as people may rely on them. Try removing Price security token from a user and then as that user go and change the price in an order.

[quote='phil' pid='1776' dateline='1355040995']
The code in question allows a user who would be entitled to receive goods to click a link at the end of an authorised purchase order entry or update, that automatically receives the whole of the purchase order (to the extent that there are balances still to receive) and automatically populates a supplier invoice with the received GRNs from that order (now received). This short circuits the processing where a users is effectively entering an invoice at the time the goods arrive and where there is no separation of duties between purchasing/receiving goods and invoice entry. The user must have permission to do all three to accomplish this. In smaller businesses this is quite common and was a complaint leveled at webERP.

That complaint is valid no more :-)

Well this really depends on the target audience. Are you now saying that you are changing the target towards the quickbooks end of the market? The SME market would prefer to have the security in the system rather than ease of use. In accountancy ease of use is often the same as ease to defraud. Personally I think we should stick to the traditional SME business, but I know you will do whatever you want. However some announcement so that those who depend on the security could formulate a plane to move would have been good.

(12-09-2012 06:16 PM)phil Wrote:  I think what I've done - retains all the controls we had for proper separation of duties, but also allows for the small business scenario too.

Of course it is not my intention to undo good work. Had I thought to change or undo some of the controls then of course I would have announced it - but this is not my intention!!

Well a discussion on it would have shown you that you were removing controls. In webERP users can choose their own security schema, changing the page security settings and the security tokens. You yourself have done it in the setup data supplied with webERP as I described above with price security. Relying on hard coded security tokens is no security at all.

(12-09-2012 06:16 PM)phil Wrote:  Do let me know if I have introduced a problem! Tim, your careful review of my work is great and I would encourage you to air your views and any potential pitfalls or technical matters on the mailing list (which you do have moderated access to - due to ongoing abuse) - or here.

I can't post to the mailing list as all posts are getting immediately rejected so there is no point in trying anymore. If it's your abuse that's worrying it really doesn't matter. I have got used to it and just ignore most of it. In fact it sometimes cheers me up on a cold morning, so please don't stop :-)

Thanks
Tim
Find all posts by this user
12-09-2012, 08:32 PM
Post: #6
RE: Purchasing security
(12-09-2012 07:36 PM)PakRicard Wrote:  Hi Phil: Thanks for your detailed reply. So, upgrading version should not be a problem, then? Things can be worked with the same workflow?

Hi Ricard,

If your business relies on the purchasing security model, then I would not use these new updates for the reasons I said in my reply to Phil. Alternatively you need a manual security system, which is the way most businesses who stay with webERP will need to go.

Thanks
Tim
Find all posts by this user
12-10-2012, 03:27 AM
Post: #7
RE: Purchasing security
Phil seems to have got himself to another one of his states over this and banned my normal login from posting to this forum, and will probably ban this one when he wakes up.

Please note, that I am not saying Phil's code is bad, just that as this is a radical change in direction I think that some discussion should have happened before implementing it. Removing the layers of security from purchase ordering is good for the small or one person business, but is going to put off the SME businesses we have traditionally aimed at.

Hopefully we can have a reasonable technical discussion around this, and not just ban anyone who has a different point of view.

Thanks
Tim
Find all posts by this user
12-10-2012, 05:52 AM (This post was last modified: 12-10-2012 06:21 AM by phil.)
Post: #8
RE: Purchasing security
All existing security remains in place. There is no reliance on hard coded security tokens (correction - there is the price one ... not sure of a way around this though)

Upgrade will be fine Ricard.

Tim does have access to the mailing lists.

I have just improved the work flow for those who can't take advantage of the separation of duties.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
12-10-2012, 06:40 AM (This post was last modified: 12-10-2012 06:52 AM by phil.)
Post: #9
RE: Purchasing security
On the price security issue .. my intention was to have two levels of price security - one that allows changes to the price on the sales order entry and the other level that allows changes to the prices in the Prices.php script - which are permanent price alterations. This does use a hard coded security token... and has done for quite a while.

I was envisaging a senior customer services person having permission to alter a price on a sales order entry, but junior ones not. It is clearly unworkable to have only the pricing administrator with permission to over-ride prices at sales order entry time - unless that person is the same as the order entry clerk! However, our security system is geared around scripts and we don't have a script for this. I think maybe I need to make up a dummy script for "SeniorOrderEntry" and add this to the scripts table - although it doesn't actually exist!! It would solve the problem Tim describes though. Currently if the hard coded PageSecurity token is deleted then this causes problems for the current code.

There was discussion around this on the developers mailing list at the time.

Clearly there are differences between some of the things I am saying and those Tim is saying.... there can be only one explanation of course. It should be noted that Tim now has several forks and I guess his motives might be to discredit webERP or me - I am really not sure. I have documented and put up the full story up at http://www.logicworks.co.nz/TimSchofieldDispute.html which gives the full facts around this ongoing nonsense.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Thread Closed 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)