Menu
▾
▴
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: 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: 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: 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: 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: 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-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: 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: 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: 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: 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: 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: 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: 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: 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.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X