Menu
▾
▴
web-erp-developers — Discussion on development of webERP
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(20) |
Aug
(21) |
Sep
(12) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(3) |
Feb
(46) |
Mar
(65) |
Apr
(49) |
May
(33) |
Jun
(5) |
Jul
(79) |
Aug
(228) |
Sep
(347) |
Oct
(272) |
Nov
(270) |
Dec
(424) |
| 2005 |
Jan
(549) |
Feb
(232) |
Mar
(134) |
Apr
(103) |
May
(57) |
Jun
(74) |
Jul
(67) |
Aug
(45) |
Sep
(99) |
Oct
(187) |
Nov
(238) |
Dec
(127) |
| 2006 |
Jan
(81) |
Feb
(137) |
Mar
(46) |
Apr
(55) |
May
(62) |
Jun
(152) |
Jul
(137) |
Aug
(154) |
Sep
(176) |
Oct
(104) |
Nov
(65) |
Dec
(64) |
| 2007 |
Jan
(56) |
Feb
(303) |
Mar
(88) |
Apr
(80) |
May
(72) |
Jun
(20) |
Jul
(47) |
Aug
(28) |
Sep
(113) |
Oct
(49) |
Nov
(89) |
Dec
(24) |
| 2008 |
Jan
(24) |
Feb
(61) |
Mar
(43) |
Apr
(51) |
May
(12) |
Jun
(10) |
Jul
(49) |
Aug
(26) |
Sep
(7) |
Oct
(50) |
Nov
(19) |
Dec
(15) |
| 2009 |
Jan
(87) |
Feb
(144) |
Mar
(54) |
Apr
(72) |
May
(32) |
Jun
(23) |
Jul
(27) |
Aug
(90) |
Sep
(349) |
Oct
(174) |
Nov
(320) |
Dec
(110) |
| 2010 |
Jan
(162) |
Feb
(39) |
Mar
(80) |
Apr
(126) |
May
(45) |
Jun
(44) |
Jul
(75) |
Aug
(32) |
Sep
(100) |
Oct
(57) |
Nov
(49) |
Dec
(125) |
| 2011 |
Jan
(72) |
Feb
(41) |
Mar
(63) |
Apr
(18) |
May
(123) |
Jun
(100) |
Jul
(96) |
Aug
(84) |
Sep
(83) |
Oct
(39) |
Nov
(166) |
Dec
(103) |
| 2012 |
Jan
(158) |
Feb
(148) |
Mar
(77) |
Apr
(43) |
May
(126) |
Jun
(82) |
Jul
(67) |
Aug
(28) |
Sep
(109) |
Oct
(30) |
Nov
(23) |
Dec
(34) |
| 2013 |
Jan
(14) |
Feb
(16) |
Mar
(7) |
Apr
(79) |
May
(76) |
Jun
(13) |
Jul
(76) |
Aug
(36) |
Sep
(22) |
Oct
(35) |
Nov
(167) |
Dec
(93) |
| 2014 |
Jan
(64) |
Feb
(14) |
Mar
(57) |
Apr
(63) |
May
(60) |
Jun
(15) |
Jul
(24) |
Aug
(19) |
Sep
(56) |
Oct
(70) |
Nov
(45) |
Dec
(52) |
| 2015 |
Jan
(56) |
Feb
(73) |
Mar
(34) |
Apr
(11) |
May
(24) |
Jun
(19) |
Jul
(11) |
Aug
(8) |
Sep
(25) |
Oct
(22) |
Nov
(38) |
Dec
(7) |
| 2016 |
Jan
(7) |
Feb
(34) |
Mar
(17) |
Apr
(10) |
May
(17) |
Jun
(7) |
Jul
(17) |
Aug
(31) |
Sep
(3) |
Oct
(34) |
Nov
(5) |
Dec
(2) |
| 2017 |
Jan
|
Feb
(4) |
Mar
(18) |
Apr
(6) |
May
(10) |
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(10) |
May
(5) |
Jun
|
Jul
(7) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2022 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(30) |
Nov
|
Dec
(2) |
|
From: Phil D. <ph...@lo...> - 2013-12-10 19:24:50
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/> <style type="text/css">.mceResizeHandle {position: absolute;border: 1px solid black;background: #FFF;width: 5px;height: 5px;z-index: 10000}.mceResizeHandle:hover {background: #000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: .5;z-index: 10000} </style></head><body style=""> <div> I think we need to distinguish between access controls - using our roles system and authorisation levels of authority  - the two are quite different. </div> <div> I have not looked , but I wonder if for different transaction types we could potentially extend the purchase order authorisation table </div> <div> I agree with Tim - we are going to need to look at each transaction type specifically I think </div> <div>   </div> <div> Phil <br/> <br/>> <br/>> Hi Exson, <br/>> <br/>> What I was trying to say was that I don't believe we can make a "one <br/>> size fits all" authorisation system, or if we did it would have to be <br/>> very complex. My suggestion was that we analysed each process <br/>> requiring authorisation (such as the stock location transfer) and <br/>> properly understand how a generalised solution would work for each <br/>> process. <br/>> <br/>> Thanks <br/>> Tim <br/>> <br/>> On 10 December 2013 14:48, Exson Qu <hex...@gm...> wrote: <br/>> > Hi, Tim, <br/>> > <br/>> > Thank you for your details explanation. <br/>> > <br/>> > I just hope to find a more efficient and regular way to solve a <br/>> > more complex authorization need. That's why I suggest to create a another <br/>> > table to hold the authorization tree by processes. <br/>> > <br/>> > Thank you again! <br/>> > <br/>> > Exson <br/>> > <br/>> > <br/>> > 2013/12/10 Tim Schofield <tim...@gm...> <br/>> >> <br/>> >> I think that we first have to understand how all these processes will <br/>> >> work in real life situations, and once we have, then the authorisation <br/>> >> process for those systems will become more obvious. I have no problem <br/>> >> using different authorisation methods for different processes if that <br/>> >> is the best way. <br/>> >> <br/>> >> For instance Jo (cc'd on this mail for info) wrote recently about <br/>> >> having an authorisation system for stock location transfers. I like <br/>> >> this idea very much, but cannot get my head around exactly how that <br/>> >> would work. Should the authoriser be the sender, the receiver, or <br/>> >> someone else entirely? To take two real life examples: <br/>> >> <br/>> >> To transfer a container of electrical goods from the Mombasa warehouse <br/>> >> to the Kampala warehouse is a strategic business decision. The costs <br/>> >> in doing this transfer are high, and so the decision has to be taken <br/>> >> high up in the organisation. <br/>> >> <br/>> >> To transfer two packets of paracetamol tabs from the main pharmacy to <br/>> >> a sub pharmacy in a hospital is a minor procedure, easily reversed if <br/>> >> necessary. Such transfers could happen several times a day, and <br/>> >> require little or no authorisation. <br/>> >> <br/>> >> To webERP both of the above are identical. They are simply stock <br/>> >> location transfers, so how to setup an authorisation system that <br/>> >> covers everything? It cannot be just on stock valuation, as would you <br/>> >> want someone transferring $1 of stock from your Shanghai warehouse to <br/>> >> your Buenos Aires warehouse without authorisation? <br/>> >> <br/>> >> Its an interesting subject and requires a lot of discussion as there <br/>> >> will be many scenarios we have not yet thought of. <br/>> >> <br/>> >> Tim <br/>> >> <br/>> >> On 10/12/2013, Exson Qu <hex...@gm...> wrote: <br/>> >> > *Hi, Tim,* <br/>> >> > <br/>> >> > You've always have great idea about how to implement webERP. <br/>> >> > <br/>> >> > Basically in China, a PR is a special document which used to <br/>> >> > apply material for some orders instead of what webERP used by material. <br/>> >> > So <br/>> >> > the information in Purchasing Request is not coincident with purchasing <br/>> >> > order completely. That's why we should use it. <br/>> >> > <br/>> >> > Currently, we use some authority which not by token without <br/>> >> > any <br/>> >> > rules or guide line. That's why I arose this topic and hope can reach an <br/>> >> > agreement finally. <br/>> >> > <br/>> >> > Thanks and best regards! <br/>> >> > <br/>> >> > Exson <br/>> >> > <br/>> >> > <br/>> >> > 2013/12/10 Tim Schofield <tim...@gm...> <br/>> >> > <br/>> >> >> Hi Exson, <br/>> >> >> <br/>> >> >> I can see the advantage of having departmental authorisers for <br/>> >> >> purchase orders, otherwise I think most things can be done with an <br/>> >> >> imaginative use of the existing functionality. The purchase order <br/>> >> >> request is effectively the initial purchase order input. Maybe this <br/>> >> >> terminology could be changed so that the initial input is called a <br/>> >> >> requisition, and it only becomes an order once authorised? <br/>> >> >> <br/>> >> >> In the end this is an open source project, anybody can develop for it. <br/>> >> >> If you need functionality that is not there go for it and write it. If <br/>> >> >> Phil doesn't want it in his branch then its fine, if I dont want it in <br/>> >> >> mine, then that is also fine, but there maybe others who really want <br/>> >> >> that code in theirs, so if you need code then you should always write <br/>> >> >> it and publish it. <br/>> >> >> <br/>> >> >> Tim <br/>> >> >> <br/>> >> >> On 10/12/2013, Exson Qu <hex...@gm...> wrote: <br/>> >> >> > *Hi, Tim,* <br/>> >> >> > <br/>> >> >> > Thank you for your mails. You're right.That's why we should <br/>> >> >> setup <br/>> >> >> > a approval procedure to control it. What I faced is that the sales <br/>> >> >> > people <br/>> >> >> > should have some flexibility but under control. <br/>> >> >> > For instance, they are authorized to sales a higher price <br/>> >> >> > than <br/>> >> >> > the standard price or less but within a allowed range. Do you think <br/>> >> >> > this <br/>> >> >> > break the account rules? <br/>> >> >> > <br/>> >> >> > I think this also reasonable for purchasing. Some company <br/>> >> >> > has <br/>> >> >> > more one group to be in charge of purchasing. It also should be <br/>> >> >> > reviewed <br/>> >> >> > and approved. In China, webERP current is lack of a purchasing <br/>> >> >> > request <br/>> >> >> > process, so all of them are in paper work. We have to face lots of <br/>> >> >> > request/confirm/approval procedure. Just as petty cash do now. And in <br/>> >> >> petty <br/>> >> >> > cash, there is only one tier(request/approval). And it controlled by <br/>> >> >> users <br/>> >> >> > instead of tokens as you know. <br/>> >> >> > <br/>> >> >> > Thanks and best regards! <br/>> >> >> > <br/>> >> >> > Exson <br/>> >> >> > <br/>> >> >> > <br/>> >> >> > <br/>> >> >> > <br/>> >> >> > 2013/12/10 Tim Schofield <tim...@gm...> <br/>> >> >> > <br/>> >> >> >> Exson, <br/>> >> >> >> <br/>> >> >> >> At the moment salesmen cannot alter prices at all without them being <br/>> >> >> >> given a specific token, and I feel this is the right way. At no <br/>> >> >> >> company where I was ever an accountant would I have wanted sales <br/>> >> >> >> people to alter prices on orders. A fundamental rule of accountancy <br/>> >> >> >> is <br/>> >> >> >> "don't trust the sales team" :-) <br/>> >> >> >> <br/>> >> >> >> Thanks <br/>> >> >> >> Tim <br/>> >> >> >> <br/>> >> >> >> On 10/12/2013, ExsonQu <hex...@gm...> wrote: <br/>> >> >> >> > *Dear all:* <br/>> >> >> >> > <br/>> >> >> >> > Thank you for your opinion! I've quoted Tim's as followed. <br/>> >> >> >> > <br/>> >> >> >> > Although there is different opinion, I think there is one <br/>> >> >> which <br/>> >> >> >> is <br/>> >> >> >> > agreed by most of us: <br/>> >> >> >> > We should create a uniform approval(request/confirm) <br/>> >> >> >> > regular <br/>> >> >> >> > for <br/>> >> >> >> > those business processes. <br/>> >> >> >> > Although Tim think current tokens system is powerful <br/>> >> >> >> > enough, <br/>> >> >> >> > I <br/>> >> >> >> > still <br/>> >> >> >> > have to face the request/approval problem. For instance, we have <br/>> >> >> >> > 20 <br/>> >> >> >> > sales <br/>> >> >> >> > men and they belong to 5 different groups, and each group have one <br/>> >> >> team <br/>> >> >> >> > leader. And all those teams are under an sales manager. When they <br/>> >> >> issue <br/>> >> >> >> SO <br/>> >> >> >> > which is zero cost or price is lower than the normal one, it's <br/>> >> >> >> > must <br/>> >> >> >> > be <br/>> >> >> >> > approved by team lead or manager. And sometime it's should be <br/>> >> >> >> > approved <br/>> >> >> >> > by <br/>> >> >> >> > general manager. <br/>> >> >> >> > <br/>> >> >> >> > Even we can use tokens to control the scripts, at last, <br/>> >> >> >> > we <br/>> >> >> >> > still <br/>> >> >> >> > have to know which group those sales belong to, and what <br/>> >> >> responsibility <br/>> >> >> >> of <br/>> >> >> >> > each of those users. So we have to store and retrieve those <br/>> >> >> information <br/>> >> >> >> in <br/>> >> >> >> > some place. <br/>> >> >> >> > <br/>> >> >> >> > My suggest is to create a table which named <br/>> >> >> >> > organization? <br/>> >> >> >> > It <br/>> >> >> >> > contains fields as business_type which defined the processes <br/>> >> >> >> > involved, <br/>> >> >> >> > userid, superior(user's head), submeber(user's subordinate). It's <br/>> >> >> more <br/>> >> >> >> > like <br/>> >> >> >> > a structure of current BOM. Then we can define each user's <br/>> >> >> >> > business <br/>> >> >> >> > role <br/>> >> >> >> in <br/>> >> >> >> > the organization. We can assign those users to different <br/>> >> >> responsibility <br/>> >> >> >> > according to their position in the business type. <br/>> >> >> >> > <br/>> >> >> >> > Thank you for your great idea. And looking forwarding to <br/>> >> >> >> > more <br/>> >> >> >> > from <br/>> >> >> >> > all of you. <br/>> >> >> >> > <br/>> >> >> >> > Best regards! <br/>> >> >> >> > <br/>> >> >> >> > Exson <br/>> >> >> >> > <br/>> >> >> >> > <br/>> >> >> >> > <br/>> >> >> >> > <br/>> >> >> >> > I think its possible to over complicate this issue, we already <br/>> >> >> >> > have <br/>> >> >> >> > a <br/>> >> >> >> > complex and flexible security model. <br/>> >> >> >> > <br/>> >> >> >> > It is possible to have a per user security system by just creating <br/>> >> >> >> > a <br/>> >> >> >> > separate role per user. Maybe a "duplicate this role" option? <br/>> >> >> >> > <br/>> >> >> >> > Most things have an inquiry as well as an input screen, so there <br/>> >> >> >> > are <br/>> >> >> >> > not many occasions where the read/write becomes an issue. There <br/>> >> >> >> > are <br/>> >> >> >> > a <br/>> >> >> >> > few fields that would be nice to have that option on, not sure if <br/>> >> >> >> > its <br/>> >> >> >> > worth the extra work? <br/>> >> >> >> > <br/>> >> >> >> > Just my couple of pennies :-) <br/>> >> >> >> > <br/>> >> >> >> > Tim <br/>> >> >> >> > <br/> <br/> </div> </body></html> |
|
From: ExsonQu <hex...@gm...> - 2013-12-10 14:31:35
|
*Hi, Tim,*
Thank you for your example.
I think webERP current authorization part is far from perfect.
Or I'm not smart enough to understand the system thoroughly and creatively.
I agree that we should do more discussion and hope to find an
agreement.
Best regards!
Exson
<quotation tim>
I think that we first have to understand how all these processes will
work in real life situations, and once we have, then the authorisation
process for those systems will become more obvious. I have no problem
using different authorisation methods for different processes if that
is the best way.
For instance Jo (cc'd on this mail for info) wrote recently about
having an authorisation system for stock location transfers. I like
this idea very much, but cannot get my head around exactly how that
would work. Should the authoriser be the sender, the receiver, or
someone else entirely? To take two real life examples:
To transfer a container of electrical goods from the Mombasa warehouse
to the Kampala warehouse is a strategic business decision. The costs
in doing this transfer are high, and so the decision has to be taken
high up in the organisation.
To transfer two packets of paracetamol tabs from the main pharmacy to
a sub pharmacy in a hospital is a minor procedure, easily reversed if
necessary. Such transfers could happen several times a day, and
require little or no authorisation.
To webERP both of the above are identical. They are simply stock
location transfers, so how to setup an authorisation system that
covers everything? It cannot be just on stock valuation, as would you
want someone transferring $1 of stock from your Shanghai warehouse to
your Buenos Aires warehouse without authorisation?
Its an interesting subject and requires a lot of discussion as there
will be many scenarios we have not yet thought of.
Tim
</quotation>
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657071.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: ExsonQu <hex...@gm...> - 2013-12-10 10:49:39
|
*Hi, Phil,*
Sorry, I think my point is misunderstood.
The point here is that in some situation, the sales should send
a request to their respective group leader for approval purpose. And some
time the final decision should be made by top level. It's a chain of
authority.
You can get a image from current petty cash module.
Hope it's get a little clear.
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657070.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Phil D. <ph...@lo...> - 2013-12-10 10:15:43
|
Well we have a separate token for altering prices, some senior sales people may have this authority, but there is a clear conflict tof interest where a salexman takes a commission. We can comfigure it either way with different roles ExsonQu <hex...@gm...> wrote: >*Hi, Phil,* > > Thank you for your feedback! > > How to define following role in current system. If there is good >solution, I think it's waste to develop new rule: > >> Although Tim think current tokens system is powerful enough, >I >> still >> have to face the request/approval problem. For instance, we have 20 >sales >> men and they belong to 5 different groups, and each group have one >team >> leader. And all those teams are under an sales manager. When they >issue SO >> which is zero cost or price is lower than the normal one, it's must >be >> approved by team lead or manager. And sometime it's should be >approved by >> general manager. >> > > > Thanks and best regards! > > Exson > > > >-- >View this message in context: >http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657068.html >Sent from the web-ERP-developers mailing list archive at Nabble.com. > >------------------------------------------------------------------------------ >Sponsored by Intel(R) XDK >Develop, test and display web and hybrid apps with a single code base. >Download it for free now! >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >_______________________________________________ >Web-erp-developers mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/web-erp-developers Phil Daintree +64(0)275 567890 skype: daintree |
|
From: ExsonQu <hex...@gm...> - 2013-12-10 10:00:25
|
*Hi, Phil,*
Thank you for your feedback!
How to define following role in current system. If there is good
solution, I think it's waste to develop new rule:
> Although Tim think current tokens system is powerful enough, I
> still
> have to face the request/approval problem. For instance, we have 20 sales
> men and they belong to 5 different groups, and each group have one team
> leader. And all those teams are under an sales manager. When they issue SO
> which is zero cost or price is lower than the normal one, it's must be
> approved by team lead or manager. And sometime it's should be approved by
> general manager.
>
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657068.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Phil D. <ph...@lo...> - 2013-12-10 09:37:37
|
I agree with Tim too on this. I am not sure I want more complexity around the user definition unless we have a very clear idea about why. Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 10/12/13 16:58, ExsonQu wrote: > *Dear all:* > > Thank you for your opinion! I've quoted Tim's as followed. > > Although there is different opinion, I think there is one which is > agreed by most of us: > We should create a uniform approval(request/confirm) regular for > those business processes. > Although Tim think current tokens system is powerful enough, I still > have to face the request/approval problem. For instance, we have 20 sales > men and they belong to 5 different groups, and each group have one team > leader. And all those teams are under an sales manager. When they issue SO > which is zero cost or price is lower than the normal one, it's must be > approved by team lead or manager. And sometime it's should be approved by > general manager. > > Even we can use tokens to control the scripts, at last, we still > have to know which group those sales belong to, and what responsibility of > each of those users. So we have to store and retrieve those information in > some place. > > My suggest is to create a table which named organization? It > contains fields as business_type which defined the processes involved, > userid, superior(user's head), submeber(user's subordinate). It's more like > a structure of current BOM. Then we can define each user's business role in > the organization. We can assign those users to different responsibility > according to their position in the business type. > > Thank you for your great idea. And looking forwarding to more from > all of you. > > Best regards! > > Exson > > > > > I think its possible to over complicate this issue, we already have a > complex and flexible security model. > > It is possible to have a per user security system by just creating a > separate role per user. Maybe a "duplicate this role" option? > > Most things have an inquiry as well as an input screen, so there are > not many occasions where the read/write becomes an issue. There are a > few fields that would be nice to have that option on, not sure if its > worth the extra work? > > Just my couple of pennies :-) > > Tim > > > > -- > View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657065.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Pak R. <pak...@gm...> - 2013-12-10 04:39:45
|
Hi Tim: Yes, I'm doing 3 transctions in one payment. I think it is not important (for us at least) if in banktrans there should be 3 lines or just 1, but if there's 3 lines, each line should have its own value, not the sum. On the other side if it should be just one line in banktrans with the total sum of the payment, not show it N times. The problem as it is now is that's a mix of the 2 solutions. Solution A is good, solution 2 is good, but the mix is wrong. Then, as it is now I guess it's probably easier just to keep the 3 lines but correct the value of each line Regards, Ricard 2013/12/9 Tim Schofield <tim...@gm...> > Hi Ricard, are you doing three transactions as one payment? > > We have never really got straight if you do 3 lines of one payment > whether that should show s 3 lines in banktrans or just 1. The code > has alternated over the years. I think Phil's code was changed to > three transactions fairly recently and that must be when the error > crept in. Had a quick look, but not sure which commit it was. > > Tim > > On 9 December 2013 02:30, Pak Ricard <pak...@gm...> wrote: > > Hi all: > > > > Using latest Payments.php in SVN with a bank account in non-functional > > currency I found it does not record the correct amounts in banktrans > table. > > > > Example: > > > > Functional currency IDR > > Bank account in USD: Initial balance 10.000 USD > > Go to Payments.php and do the following payments from this USD bank > account > > (currency of payment USD as well) > > Payment 1 = 100 USD > > Payment 2 = 200 USD > > Payment 3 = 300 USD > > > > > > We should expect 3 new rows in banktrans with -100, -200 and -300 USD > but we > > get 3 rows with - 600 USD . > > > > Also the bank reconciliation, gets wrong info as well, initial balance > gets > > wrong, and quantities to reconcile get wrong as well. > > > > Not sure when this problem showed up. It's a quite tricky script, so I > would > > prefer if one of the webERP masters could fix it. > > > > I also posted this bug on the forum, as I could attach 4 screenshots > easily. > > > > Regards, > > Ricard > > > > > ------------------------------------------------------------------------------ > > Sponsored by Intel(R) XDK > > Develop, test and display web and hybrid apps with a single code base. > > Download it for free now! > > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > -- > Course View Towers, > Plot 21 Yusuf Lule Road, > Kampala > T +256 (0) 312 314 418 > M +256 (0) 752 963 325 > www.weberpafrica.com > Twitter: @TimSchofield2 > Blog: http://weberpafrica.blogspot.co.uk/ > |
|
From: ExsonQu <hex...@gm...> - 2013-12-10 03:59:14
|
*Dear all:*
Thank you for your opinion! I've quoted Tim's as followed.
Although there is different opinion, I think there is one which is
agreed by most of us:
We should create a uniform approval(request/confirm) regular for
those business processes.
Although Tim think current tokens system is powerful enough, I still
have to face the request/approval problem. For instance, we have 20 sales
men and they belong to 5 different groups, and each group have one team
leader. And all those teams are under an sales manager. When they issue SO
which is zero cost or price is lower than the normal one, it's must be
approved by team lead or manager. And sometime it's should be approved by
general manager.
Even we can use tokens to control the scripts, at last, we still
have to know which group those sales belong to, and what responsibility of
each of those users. So we have to store and retrieve those information in
some place.
My suggest is to create a table which named organization? It
contains fields as business_type which defined the processes involved,
userid, superior(user's head), submeber(user's subordinate). It's more like
a structure of current BOM. Then we can define each user's business role in
the organization. We can assign those users to different responsibility
according to their position in the business type.
Thank you for your great idea. And looking forwarding to more from
all of you.
Best regards!
Exson
I think its possible to over complicate this issue, we already have a
complex and flexible security model.
It is possible to have a per user security system by just creating a
separate role per user. Maybe a "duplicate this role" option?
Most things have an inquiry as well as an input screen, so there are
not many occasions where the read/write becomes an issue. There are a
few fields that would be nice to have that option on, not sure if its
worth the extra work?
Just my couple of pennies :-)
Tim
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657065.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: icedlava <ice...@gm...> - 2013-12-09 17:15:11
|
E-Groupware or Joomla are not my preferred example for access. I prefer to have Roles managed quite separately to groups/users which makes it easier/possible when trying to apply to real life situations. User 'john' might be assigned to Branch Dispatch group. He might have role of 'Dispatch Clerk' which may have different access to roles of Dispatch Clerk that is in Main Dispatch Group. Do we want to be so complex with access rights? What happens if a user might be allowed to be assigned to one or more roles or groups, and those roles /groups have different access rights for a specific function/action. What if a group or subgroup has different access to a user? Should the user inherit rights or allowed to retain the rights specifically given to them? Which level is used/inherited? What is the one that takes precedence. Does 'No rights' override 'Read rights' - or 'All rights' override 'Read only' - which is safer way to go? Should Read rights be inherited if the user has already been given 'no read rights'? It could get very complex and hard to manage without clear rules in code. I agree with Rafael that we need a way to implement whatever access rights we define, consistently across all 'scripts'. But this is not granular enough I think, just the same as we have now. We need more granularity in access levels - whether it be decided at Module, function, action, link level with some agreed defined access rights (create, modify, read, delete, config/admin?) I also agree with Exson, that on top of all this there is a need for approval control for a process (config/admin level access?). This could be applied for example to the request/approval process I need for inventory transfers. But this is access rights at process level - as distinct to module/function/action level. Maybe in some cases the script/function we have might be able to equate roughly to process. I see so far raised: 1. Roles, groups, users and their relationship 2. Granularity of access - module, function/script, action, link 3. Type of access - create, modify, read, delete, admin/config 4. Request/Approval for a process 5. Definitions and rules for all that might be decided to use above Thanks for the opportunity to discuss, On 10 Dec 2013, at 2:46, Rafael Chacón wrote: > Hallo, > > My two cents: > > I have seen in other projects: > > 1. Group-access, sub-group-access, sub-sub-group-access --from general > access to specific access--. The sub-groups inherit the attributes of > groups; The sub-sub-groups inherit the attributes of sub-groups. It is > a > kind of pyramid of access rights. E.g. Joomla! > > 2. Group-access and individual-access --general access for groups, > specific > access for individuals--. The individuals inherit the attributes of > the > groups to which they belong. E.g. EGroupware. > > Personally, I like the EGroupware way. > > In both cases, I used the group-access as the Department attributes > (general access rights for all the people who belong to a department). > > I think we could use the current structure, with little modifications, > to > adapt to any of them. What is critical is to distribute access-rights > variables by all scripts, and then to fill an array of access rights. > > Regards, Rafael. > > > 2013/12/5 ExsonQu <hex...@gm...> > >> *Hi, Jo,* >> >> You're right that we should have a convent for access >> control. >> And granularity is just one point of the discussion, another one is >> the >> approval control or approval processes management. I hope we can set >> a rule >> for that. >> >> Thanks and best regards! >> >> Exson >> >> >> >> -- >> View this message in context: >> http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657052.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code >> base. >> Download it for free now! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Rafael C. <raf...@gm...> - 2013-12-09 16:16:46
|
Hallo, My two cents: I have seen in other projects: 1. Group-access, sub-group-access, sub-sub-group-access --from general access to specific access--. The sub-groups inherit the attributes of groups; The sub-sub-groups inherit the attributes of sub-groups. It is a kind of pyramid of access rights. E.g. Joomla! 2. Group-access and individual-access --general access for groups, specific access for individuals--. The individuals inherit the attributes of the groups to which they belong. E.g. EGroupware. Personally, I like the EGroupware way. In both cases, I used the group-access as the Department attributes (general access rights for all the people who belong to a department). I think we could use the current structure, with little modifications, to adapt to any of them. What is critical is to distribute access-rights variables by all scripts, and then to fill an array of access rights. Regards, Rafael. 2013/12/5 ExsonQu <hex...@gm...> > *Hi, Jo,* > > You're right that we should have a convent for access control. > And granularity is just one point of the discussion, another one is the > approval control or approval processes management. I hope we can set a rule > for that. > > Thanks and best regards! > > Exson > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657052.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Pak R. <pak...@gm...> - 2013-12-09 02:31:11
|
Hi all: Using latest Payments.php in SVN with a bank account in non-functional currency I found it does not record the correct amounts in banktrans table. Example: - Functional currency IDR - Bank account in USD: Initial balance 10.000 USD - Go to Payments.php and do the following payments from this USD bank account (currency of payment USD as well) - Payment 1 = 100 USD - Payment 2 = 200 USD - Payment 3 = 300 USD We should expect 3 new rows in banktrans with -100, -200 and -300 USD but we get 3 rows with - 600 USD . Also the bank reconciliation, gets wrong info as well, initial balance gets wrong, and quantities to reconcile get wrong as well. Not sure when this problem showed up. It's a quite tricky script, so I would prefer if one of the webERP masters could fix it. I also posted this bug on the forum, as I could attach 4 screenshots easily. Regards, Ricard |
|
From: Rafael C. <raf...@gm...> - 2013-12-07 21:53:42
|
Hi Tim,
That was the origin of my confusion. At the begging, I marked this line
(UserSettings.php line 96) with "/*" and "*/", and tested. It works.
When I was documenting that, I realized that it was "LanguageSetup.php", not
"LanguagesArray.php". As I understand, this script is to (a) setup gettext
and (b) load LanguagesArray.php... But LanguagesArray.php do not need to be
re-loaded, and (I think) gettext must be setup once.
Unfortunately, we still do not understand very well the operation of
LanguageSetup.php and UserSettings.php, so I prefer someone more experienced to
review it.
Best regards, Rafael.
>
>
> 2013/12/7 Tim Schofield <tim...@gm...>
>
>> Hi,
>>
>> includes/LanguageSetup.php is the script that actually sets up the
>> languages for gettext to use in the translations, which is why it
>> needs to be included when the language gets changed.
>>
>> I think you may be mixing it up with includes/LanguagesArray.php?
>>
>> Thanks
>> Tim
>>
>> On 7 December 2013 20:08, Rafael Chacón <raf...@gm...>
>> wrote:
>> > Hi,
>> >
>> > I think that "include ('includes/LanguageSetup.php');" was required when
>> > languages names were in different languages, but now they are in their
>> local
>> > language. Therefore, I think it is not necessary to update along with
>> the
>> > rest of the session variables to reflect user changes on-the-fly.
>> >
>> > My tests were successful, but I am not completely sure. I do not want
>> that
>> > delete this line causes an error in the future. This is the reason why
>> I ask
>> > this question.
>> >
>> > Best regards, Rafael.
>> >
>> >
>> > 2013/12/7 Tim Schofield <tim...@gm...>
>> >>
>> >> Phil, this is the line that Rafael is referring to.
>> >>
>> >> include ('includes/LanguageSetup.php'); // After last changes in
>> >> LanguageSetup.php, is it required to update?
>> >>
>> >> I think its there to update the language when the user changes rather
>> >> than waiting for them to log out and back in.
>> >>
>> >> Tim
>> >>
>> >> On 7 December 2013 19:31, Phil Daintree <ph...@lo...> wrote:
>> >> > Line 96
>> >> >
>> >> > putenv('LANGUAGE=' . $_SESSION['Language']);
>> >> >
>> >> > I think this was to do with different OS windows and linux use
>> different
>> >> > variable names. There was fair bit of trial and error when we first
>> set
>> >> > this up - would be reluctant to change without someone with a
>> selection
>> >> > of
>> >> > OS's trying and proving it was ok to remove it.
>> >> >
>> >> > Phil
>> >> >
>> >> > Phil Daintree
>> >> > Logic Works Ltd - +64 (0)275 567890
>> >> > http://www.logicworks.co.nz
>> >> >
>> >> > On 08/12/13 06:45, Rafael Chacón wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > After the latest changes in LanguageSetup.php, I think the line 96
>> is no
>> >> > longer necessary in UserSettings.php. In my system works fine without
>> >> > this
>> >> > line.
>> >> >
>> >> > Comments?
>> >> >
>> >> > Regards, Rafael.
>> >> >
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > Sponsored by Intel(R) XDK
>> >> > Develop, test and display web and hybrid apps with a single code
>> base.
>> >> > Download it for free now!
>> >> >
>> >> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Web-erp-developers mailing list
>> >> > Web...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > Sponsored by Intel(R) XDK
>> >> > Develop, test and display web and hybrid apps with a single code
>> base.
>> >> > Download it for free now!
>> >> >
>> >> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Web-erp-developers mailing list
>> >> > Web...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Course View Towers,
>> >> Plot 21 Yusuf Lule Road,
>> >> Kampala
>> >> T +256 (0) 312 314 418
>> >> M +256 (0) 752 963 325
>> >> www.weberpafrica.com
>> >> Twitter: @TimSchofield2
>> >> Blog: http://weberpafrica.blogspot.co.uk/
>> >
>> >
>>
>>
>>
>> --
>> Course View Towers,
>> Plot 21 Yusuf Lule Road,
>> Kampala
>> T +256 (0) 312 314 418
>> M +256 (0) 752 963 325
>> www.weberpafrica.com
>> Twitter: @TimSchofield2
>> Blog: http://weberpafrica.blogspot.co.uk/
>>
>
>
|
|
From: Phil D. <ph...@lo...> - 2013-12-07 20:06:17
|
Sorry Rafael ... UserSettings.php line 96!
Actually I am no longer able to change the language settings and see the
new language on my install - without first logging out and then back in
again now? We need to go back through the changes made here to see what
caused it to break - it is a very sensitive area.
Previously it was possible to change the language and it instantly
displayed in the newly selected language.
Having this line:
include ('includes/LanguageSetup.php');
makes no difference in my installation - (Mint Olivia)
Phil
Phil, this is the line that Rafael is referring to.
include ('includes/LanguageSetup.php'); // After last changes in
LanguageSetup.php, is it required to update?
I think its there to update the language when the user changes rather
than waiting for them to log out and back in.
Tim
On 7 December 2013 19:31, Phil Daintree <ph...@lo...> wrote:
> Line 96
>
> putenv('LANGUAGE=' . $_SESSION['Language']);
>
> I think this was to do with different OS windows and linux use different
> variable names. There was fair bit of trial and error when we first set
> this up - would be reluctant to change without someone with a selection of
> OS's trying and proving it was ok to remove it.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
> On 08/12/13 06:45, Rafael Chacón wrote:
>
> Hi,
>
> After the latest changes in LanguageSetup.php, I think the line 96 is no
> longer necessary in UserSettings.php. In my system works fine without this
> line.
>
> Comments?
>
> Regards, Rafael.
>
|
|
From: Phil D. <ph...@lo...> - 2013-12-07 19:32:11
|
Line 96
putenv('LANGUAGE=' . $_SESSION['Language']);
I think this was to do with different OS windows and linux use different
variable names. There was fair bit of trial and error when we first set
this up - would be reluctant to change without someone with a selection
of OS's trying and proving it was ok to remove it.
Phil
Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz
On 08/12/13 06:45, Rafael Chacón wrote:
> Hi,
>
> After the latest changes in LanguageSetup.php, I think the line 96 is
> no longer necessary in UserSettings.php. In my system works fine
> without this line.
>
> Comments?
>
> Regards, Rafael.
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
|
|
From: Rafael C. <raf...@gm...> - 2013-12-07 17:45:16
|
Hi, After the latest changes in LanguageSetup.php, I think the line 96 is no longer necessary in UserSettings.php. In my system works fine without this line. Comments? Regards, Rafael. |
|
From: rfthomas <rf...@as...> - 2013-12-06 17:00:08
|
Our users have requested that the top menu bar always be visible on the screen and when the information displayed by a request, e.g. an inventory listing that could be very long that such scroll below the top menu bar. We are using the default theme. Many of our users are trying to use the software from tablets and cell phones. Such would make the software easier to use. They have also asked for less wasted space and when such does not compromise legibility smaller font sizes. We are two releases behind due to the amount of editing and testing that we must do reinsert changes that we make to the look of Quotations, Invoices and Shipping papers as well as the operation of the invoice screen using a simple one line change in the cart made by Exson. Such forces the quantity shipped to 0 at all times so that we must enter a quantity since we rarely ship complete orders rather shipments occur over the life of the order. Bob Thomas -- View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Change-in-GUI-and-other-items-tp4657053.html Sent from the web-ERP-developers mailing list archive at Nabble.com. |
|
From: ExsonQu <hex...@gm...> - 2013-12-06 00:40:34
|
*Hi, Jo,*
You're right that we should have a convent for access control.
And granularity is just one point of the discussion, another one is the
approval control or approval processes management. I hope we can set a rule
for that.
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657052.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: icedlava <ice...@gm...> - 2013-12-05 13:21:30
|
Hi Phil, Yes I agree with you. I think it could get messy if we continue to distribute the access around about the code in different areas. It is more difficult to maintain this unless - if we really want to do this - we don't have it located in one 'access' area so we can see - this userid, or this role, has this type of access. Otherwise we have to travel all over the code base and user interface to find out. I still think this discussion is looking for ways to increase the granularity of access allowed. The discussion on whether to use userid or role based is not the real problem for solving. Maybe I am overlooking something tho. Cheers, On 5 Dec 2013, at 17:15, Phil Daintree wrote: > Yes we are kind of doing authentication in a number of different ways > - the salesman specific stuff - the user specific stuff for bank > accounts and the wider generalised role stuff. > Perhaps we are complicating things more than we need to? > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > > On 05/12/13 17:45, iced lava wrote: >> Hi Exson, >> >> Thank you for your interesting post. >> >> Personally I have always found it a little more time consuming to set >> up access using roles, but well worth it when it comes to maintenance >> of user access. Even in businesses with smaller numbers of people I >> find it a chore to remember who has what access when applied at a >> user level (depending on the application), and if some leaves the >> business or new people come in, then we have to remember again what >> all the setups are or have them documented somewhere, and similarly >> remove all the user based access for those that leave. Error creeps >> in. >> >> In this respect it is easier for me to add the user or remove the >> user to a defined role that has all the required access defined in >> one pace. >> >> If user based access is located in one user interface area dedicated >> to user access, rather than distributed across various areas of the >> application it might be a bit more easier to maintain. >> >> In this discussion however I think we are talking about the >> granularity of the access, not a role or user access. I think >> granularity or how fine the access is is not the same as if it is by >> role or user id. Here i mean granularity in terms of detail of >> access to some particular part of a page, a link, a transaction type. >> And of course the granularity of access required may differ across >> organisations. >> >> Maybe we should think about access levels and how they can be applied >> at role, [group] or user level at more granular levels than a page. >> For example only - maybe we need to define access levels at 'module' >> or page or transaction type (view, create, modify, delete) or menu >> type link (transaction, report,inquiry etc) >> >> Thanks for the opportunity to discuss this! >> >> Cheers, >> >> >> >> >> >> >> >> On Thu, Dec 5, 2013 at 11:30 AM, ExsonQu <hex...@gm... >> <mailto:hex...@gm...>> wrote: >> >> *Dear all:* >> >> I think we're facing more and more chance to add >> control not >> based on scripts, as we did now. We need more precision control >> such as >> recently Richard has added bank account constraint and salesman >> control etc. >> >> It'll time consuming to develop control method case >> by case, >> and it'll be difficult for users to master it. >> >> Does it make sense to develop an extra regular >> control way for >> this? If so, which one is better? >> >> Any comments are highly appreciated! >> >> Thanks and best regards! >> >> Exson >> >> >> >> -- >> View this message in context: >> http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code >> base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> <mailto:Web...@li...> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code >> base. >> Download it for free now! >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: ExsonQu <hex...@gm...> - 2013-12-05 07:27:32
|
*
Dear all,*
Thank you for your great feedback.
There are several kind of authority method exists such as:
1. Tokens for page authority.
2. Tokens for special item such as token 12 for price.
3. Control by roles and person together. Such as salesman and
petty cash.
4. Control by person, such as bank transaction accounts control.
If we use tokens as the unique way, we have to face two problem:
1) One token can only provide Yes or No flag. If we have more
than 2 choice, we have to add other limit that set a token range to control
those option.
2) We cannot solve the problem of initiator->Confirm->Approve
management chain. Maybe just because of I'm too stupid to find a way out.
So I think token itself is not enough. We have to another
standard way to solve at least above problem---provide more precision
control method to more than 2 choices and have a simple and powerful
approval chain.
Thank you again. Looking forwarding more advice from you.
Best regards!
Exson
phildaintree wrote
> Hi Ricard/Exson,
>
> I think the token system now has a lot of flexibility in it. Users can
> set up new tokens, new roles, and change the tokens required for each
> script. This is complex, but generally a once only job. It is
> perfectly possible to have one role per person in an organisation if
> that is the way the company wants, so effectively we can now do
> security by role, or by person.
>
> I like the idea of narrowing down the GL codes that a user can see,
> and this is something we get asked for a lot. I like the way Ricard
> approached this with petty cash, and would like to see that extended
> throughout webERP.
>
> Thanks
> Tim
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044p4657048.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Phil D. <ph...@lo...> - 2013-12-05 06:45:25
|
Yes we are kind of doing authentication in a number of different ways - the salesman specific stuff - the user specific stuff for bank accounts and the wider generalised role stuff. Perhaps we are complicating things more than we need to? Phil Phil Daintree Logic Works Ltd - +64 (0)275 567890 http://www.logicworks.co.nz On 05/12/13 17:45, iced lava wrote: > Hi Exson, > > Thank you for your interesting post. > > Personally I have always found it a little more time consuming to set > up access using roles, but well worth it when it comes to maintenance > of user access. Even in businesses with smaller numbers of people I > find it a chore to remember who has what access when applied at a user > level (depending on the application), and if some leaves the business > or new people come in, then we have to remember again what all the > setups are or have them documented somewhere, and similarly remove all > the user based access for those that leave. Error creeps in. > > In this respect it is easier for me to add the user or remove the user > to a defined role that has all the required access defined in one pace. > > If user based access is located in one user interface area dedicated > to user access, rather than distributed across various areas of the > application it might be a bit more easier to maintain. > > In this discussion however I think we are talking about the > granularity of the access, not a role or user access. I think > granularity or how fine the access is is not the same as if it is by > role or user id. Here i mean granularity in terms of detail of access > to some particular part of a page, a link, a transaction type. And of > course the granularity of access required may differ across organisations. > > Maybe we should think about access levels and how they can be applied > at role, [group] or user level at more granular levels than a page. > For example only - maybe we need to define access levels at 'module' > or page or transaction type (view, create, modify, delete) or menu > type link (transaction, report,inquiry etc) > > Thanks for the opportunity to discuss this! > > Cheers, > > > > > > > > On Thu, Dec 5, 2013 at 11:30 AM, ExsonQu <hex...@gm... > <mailto:hex...@gm...>> wrote: > > *Dear all:* > > I think we're facing more and more chance to add > control not > based on scripts, as we did now. We need more precision control > such as > recently Richard has added bank account constraint and salesman > control etc. > > It'll time consuming to develop control method case > by case, > and it'll be difficult for users to master it. > > Does it make sense to develop an extra regular > control way for > this? If so, which one is better? > > Any comments are highly appreciated! > > Thanks and best regards! > > Exson > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > <mailto:Web...@li...> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: iced l. <ice...@gm...> - 2013-12-05 04:45:46
|
Hi Exson, Thank you for your interesting post. Personally I have always found it a little more time consuming to set up access using roles, but well worth it when it comes to maintenance of user access. Even in businesses with smaller numbers of people I find it a chore to remember who has what access when applied at a user level (depending on the application), and if some leaves the business or new people come in, then we have to remember again what all the setups are or have them documented somewhere, and similarly remove all the user based access for those that leave. Error creeps in. In this respect it is easier for me to add the user or remove the user to a defined role that has all the required access defined in one pace. If user based access is located in one user interface area dedicated to user access, rather than distributed across various areas of the application it might be a bit more easier to maintain. In this discussion however I think we are talking about the granularity of the access, not a role or user access. I think granularity or how fine the access is is not the same as if it is by role or user id. Here i mean granularity in terms of detail of access to some particular part of a page, a link, a transaction type. And of course the granularity of access required may differ across organisations. Maybe we should think about access levels and how they can be applied at role, [group] or user level at more granular levels than a page. For example only - maybe we need to define access levels at 'module' or page or transaction type (view, create, modify, delete) or menu type link (transaction, report,inquiry etc) Thanks for the opportunity to discuss this! Cheers, On Thu, Dec 5, 2013 at 11:30 AM, ExsonQu <hex...@gm...> wrote: > *Dear all:* > > I think we're facing more and more chance to add control > not > based on scripts, as we did now. We need more precision control such as > recently Richard has added bank account constraint and salesman control > etc. > > It'll time consuming to develop control method case by case, > and it'll be difficult for users to master it. > > Does it make sense to develop an extra regular control way > for > this? If so, which one is better? > > Any comments are highly appreciated! > > Thanks and best regards! > > Exson > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: Pak R. <pak...@gm...> - 2013-12-05 02:08:34
|
Hi Exson: It's a very interesting topic, Exson! Script tokens work as a general system, but when it's time to fine tuning "who can do what", it's very complex and I think very company-dependant. For some parts, some companys will prefer authority by user, others by user role, etc. As an example, and following with my modification on authority over bank accounts, we would like to be able to restrict GL accounts by user (a user can post GL expenses on a subset of GL accounts only). This can sound OK for some business or control-freak for another. In this case, and following the bank account authorization system, should be done by user, but, won't it be too difficult to maintain? webERP is aimed to SME companies, so there are not a lot of users (by definition of SME). Also, in most SME companies, employees use to have many hats, so restricting by userid instead of role I think makes more sense. The easier to administer an ERP, the better, but when you need fine tuning it's always coming at the cost of more complexity, I'm afraid. Anyway, we are still far far away from SAP set up complexity :-) Regards, Ricard 2013/12/5 ExsonQu <hex...@gm...> > *Dear all:* > > I think we're facing more and more chance to add control > not > based on scripts, as we did now. We need more precision control such as > recently Richard has added bank account constraint and salesman control > etc. > > It'll time consuming to develop control method case by case, > and it'll be difficult for users to master it. > > Does it make sense to develop an extra regular control way > for > this? If so, which one is better? > > Any comments are highly appreciated! > > Thanks and best regards! > > Exson > > > > -- > View this message in context: > http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044.html > Sent from the web-ERP-developers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: ExsonQu <hex...@gm...> - 2013-12-05 01:01:15
|
*Dear all:*
I think we're facing more and more chance to add control not
based on scripts, as we did now. We need more precision control such as
recently Richard has added bank account constraint and salesman control etc.
It'll time consuming to develop control method case by case,
and it'll be difficult for users to master it.
Does it make sense to develop an extra regular control way for
this? If so, which one is better?
Any comments are highly appreciated!
Thanks and best regards!
Exson
--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Shall-we-find-a-another-regular-way-to-manage-authority-tp4657044.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.
|
|
From: Rafael C. <raf...@gm...> - 2013-12-04 16:42:20
|
Hi Tim,
Yes, you are right. I have "$DefaultLanguage = 'en_US.UTF8';" in config.php.
Thank you, very much !!!
Best regards, Rafael.
2013/12/4 Tim Schofield <tim...@gm...>
> Ah, I am guessing your $DefaultLanguage in config.php is set to
> en_US.UTF8? It is set to exclude the default language from that list.
>
> Thanks
> Tim
>
> On 4 December 2013 16:16, Rafael Chacón <raf...@gm...>
> wrote:
> > Comment: In User Settings (UserSettings.php) languages are shown
> correctly.
> > Rafael.
> >
> >
> >
> > 2013/12/4 Rafael Chacón <raf...@gm...>
> >>
> >> Hi Tim,
> >>
> >> "US English" does not appear at the end of the list, between "Svenska"
> >> (Swedish) and "Tiếng Việt" (Vietnamese).
> >>
> >> Also, I changed to "English India", "English UK" and "English US" in
> >> LanguagesArray.php, but problem persists ("English US" does not appear).
> >>
> >> I have no idea why that happens.
> >>
> >> Best regards, Rafael.
> >>
> >>
> >> ----------
> >>
> >> 2013/12/4 Tim Schofield <tim...@gm...>
> >>>
> >>> Hi Rafael,
> >>>
> >>> I think that it is translated into 'US English' and thus appearing at
> >>> the bottom of the list.
> >>>
> >>> I am no longer allowed to help people on the list so if I am right,
> >>> you can post this to the list to stop others being confused.
> >>>
> >>> Thanks
> >>> Tim
> >>>
> >>> On 4 December 2013 15:05, Rafael Chacón <
> raf...@gm...>
> >>> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Any of you had this problem? :
> >>> >
> >>> > On Main Menu > Setup > System Parameters / Languages to Maintain
> >>> > Translations for Item Descriptions,
> >>> > in the select, the option "<option selected="selected"
> >>> > value="en_US.utf8">English US</option>" does not appear
> >>> >
> >>> > Best regards, Rafael.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Sponsored by Intel(R) XDK
> >>> > Develop, test and display web and hybrid apps with a single code
> base.
> >>> > Download it for free now!
> >>> >
> >>> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> >>> > _______________________________________________
> >>> > Web-erp-developers mailing list
> >>> > Web...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Course View Towers,
> >>> Plot 21 Yusuf Lule Road,
> >>> Kampala
> >>> T +256 (0) 312 314 418
> >>> M +256 (0) 752 963 325
> >>> www.weberpafrica.com
> >>> Twitter: @TimSchofield2
> >>> Blog: http://weberpafrica.blogspot.co.uk/
> >>
> >>
> >
>
>
>
> --
> Course View Towers,
> Plot 21 Yusuf Lule Road,
> Kampala
> T +256 (0) 312 314 418
> M +256 (0) 752 963 325
> www.weberpafrica.com
> Twitter: @TimSchofield2
> Blog: http://weberpafrica.blogspot.co.uk/
>
|
|
From: Rafael C. <raf...@gm...> - 2013-12-04 16:16:12
|
Comment: In User Settings (UserSettings.php) languages are shown correctly.
Rafael.
2013/12/4 Rafael Chacón <raf...@gm...>
> Hi Tim,
>
> "US English" does not appear at the end of the list, between "Svenska"
> (Swedish) and "Tiếng Việt" (Vietnamese).
>
> Also, I changed to "English India", "English UK" and "English US" in
> LanguagesArray.php, but problem persists ("English US" does not appear).
>
> I have no idea why that happens.
>
> Best regards, Rafael.
>
>
> ----------
>
> 2013/12/4 Tim Schofield <tim...@gm...>
>
>> Hi Rafael,
>>
>> I think that it is translated into 'US English' and thus appearing at
>> the bottom of the list.
>>
>> I am no longer allowed to help people on the list so if I am right,
>> you can post this to the list to stop others being confused.
>>
>> Thanks
>> Tim
>>
>> On 4 December 2013 15:05, Rafael Chacón <raf...@gm...>
>> wrote:
>> >
>> > Hi,
>> >
>> > Any of you had this problem? :
>> >
>> > On Main Menu > Setup > System Parameters / Languages to Maintain
>> > Translations for Item Descriptions,
>> > in the select, the option "<option selected="selected"
>> > value="en_US.utf8">English US</option>" does not appear
>> >
>> > Best regards, Rafael.
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Sponsored by Intel(R) XDK
>> > Develop, test and display web and hybrid apps with a single code base.
>> > Download it for free now!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Web-erp-developers mailing list
>> > Web...@li...
>> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> >
>>
>>
>>
>> --
>> Course View Towers,
>> Plot 21 Yusuf Lule Road,
>> Kampala
>> T +256 (0) 312 314 418
>> M +256 (0) 752 963 325
>> www.weberpafrica.com
>> Twitter: @TimSchofield2
>> Blog: http://weberpafrica.blogspot.co.uk/
>>
>
>
|
231 messages has been excluded from this view by a project administrator.
