Files
raven/devdocs/specs/core-roles.txt
2019-05-16 19:42:55 +00:00

247 lines
15 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Roles specifications
From case https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1809
RAVEN will replace security rights system of v7 with a role based system instead
I'm using an int flags enum which means a maximum of 32 possible roles unless I bump it up to a long but don't really want to as this number will be thrown around the api a lot
TODO: Fill this out as I code.
**DELETE RIGHTS***
If you can modify an object you can delete an object
**OWNER LIMITED ROLES**
Limited roles in some cases can create an object but can only edit or delete objects they created
?? STILL BEING PLANNED OUT SEE BELOW AT BOTTOM ??
## ROLES
### None
No rights, not settable, just for internal usage in code
### BizAdminLimited
Intended for a business administrator / supervisor who wants to monitor the business, kpi, reporting etc, but doesn't actually get to change anything.
Suitable for the "big boss" who isn't trusted to make actual day to day decisions but can review anything.
**RIGHTS**
- Read only access to everything (except OPS stuff)
- Full access to management reporting, KPI etc, but can't change them substantially, just sort, filter etc.
### BizAdminFull
Basically the v7 manager account stuff with full rights to everything other than OpsAdmin stuff.
**RIGHTS**
- Full access to all AyaNova objects with the sole exception of OPS related stuff
- ONLY role that can make a user or change a user's roles
- Grants roles to other users
- Licensing
- Business related configuration settings
- Form customization
- Localized text customization
- All management and KPI stuff
- NO Operations rights at all so no setup, or troubleshooting logs or technical details
### DispatchLimited
see roles.odt for more info
- Intended as the junior dispatcher account, where they can help with day to day but not change anything big or see any private data
- Can create workorder
- Can add users to workorder / schedule
- NO create clients
- No areas of workorder that are not directly related to scheduling
### DispatchFull
see roles.odt for more info
- Intended as the role for the person managing a group of techs and scheduling, pre-filling in workorders etc
- Create workorder
- Create clients
- Create vendors
- Can see anything related to scheduling and conveying service
- Not necessarily the service manager who would have multiple roles like InventoryFull and DispatchFull
- Schedule anyone
- View and edit any area of any workorder with possible exception of profit and loss stuff or any strictly BIZ functionality
- Does not have inventory rights to make inventory changes like creating parts
### InventoryLimited
see roles.odt for more info
NO PO functionality except maybe able to receive?? To be determined
View inventory, adjust inventory
creat parts, assign vendors etc (dispatcher comes to them for new parts to be created)
NO dangerous or biz affecting rights
### InventoryFull
see roles.odt for more info
Same as inventory limited but with all the PO related stuff
Also can fully change and create warehouses
Create vendors
### Accounting
see roles.odt for more info
- Create vendors
### TechFull
see roles.odt for more info
- consumes a license
- Can create their own workorders and schedule themselves on them but can't schedule others, that's dispatch job
- Some areas of workorder are still not availble if they are related to other roles such as accounting etc
- Not able to see part costs or % markup or any data not absolutely essential to doing their job
- Can create unit
- Can create client
### TechLimited
see roles.odt for more info
- CONSUMES A LICENSE
- Can make entries into existing workorders, add rows to existing areas in the workorder but can't add a new area or create a new workorder
- Can only see their own workorders, no one elses
- No access to any costs or business data of any kind
### SubContractorLimited
For filling out labor on workorders but not seeing any details of the workorder
Like a tech limited but more limited.
** Essentially the only purpose of this is to allow them to enter labor on a pre-existing workorder but really see almost nothing on the workorder except the bare minimum to enter labor
They can see only where they are scheduled in the schedule form, no client name, nothing of any detail at all, just work and enter it.
see roles.odt for more info
can only add themselves as a labor entry, not much else unless it proves necessary.
For a tech/subcontractor that is not trusted with company information including even client name i.e. just given the work to perform and enter details about that work, but doesn't need access to anything else
Can't select new parts only uses existing ones
### SubContractorFull
Same as limited except can also see the client name and address and can select parts and other things to add to workorder but not see any details about those things outside the wo view
see roles.odt for more info
### ClientLimited
### ClientFull
### OpsAdminLimited
Like ops full but for read only and simle maintenance or watching / observing when issues
A role you'd give an office person with no tech background but who is tasked with backup or looking at logs when things go wrong
### OpsAdminFull
Any major db change like restore, importing etc.
backup, troubleshoot, dashboard of throughput, db administration, all the stuff needed to keep RAVEN up and running and monitor any issues in operations of it,
nothing to do with business stuff or actual business data
************************************************************************************************************************************************************
=-=-=-=- HOW TO HANDLE EDIT OWN PLANNING =-=-=-=-=-
- EDIT_OWN: HOW TO HANDLE PROPERLY??
- PROPOSED SOLUTION: 5/16
- Edit own is actually unnecessary, it's more about a specific business rule applicable to a single scenario of a techlimited or subcontractor or client user
- NOTES FROM 5/14/2019
- Here are the most important characteristics to consider:
- EditOwn is really not about editown it's about supporting a user who is not supposed to see any data other than the bare minimum in order to fill out workorders
- EditOwn is originally intended to deal with limited rights users who are not supposed to see other workorders but the ones they are supposed to work on.
- Original intention is they can create items necessary to fill out their own workorders
- It means a workaround on every single object and list coming from the server to check if they own an object in addition to their basic rights.
- Does it? Or is this just about workorders.
- Workorder selection lists don't need to check rights, everyone has rights to them
- If they are editing an existing workorder they can't see a list of clients so that is kept private
- Parts and bits to fill in a workorder are not private data if you need them to fill it out so
- People are most concerned with hiding profits and private competitve data from subcontractors
- Is this the best way to handle the intended use-case which is to have a tech user with limited rights to only see their shit and fill out workorders?
- Is this also a way to handle client users?
- Widgets and TechFull user should be edit own widget but can't navigate to inventory form to test when not going directly from a link ?!
- Same issue with BizAdminLimited and read only, can't go to inventory at all to view list
- rights must be set for only full access to even view the inventory page.
- RETEST RIGHTS after this because could not test with this issue
- this is the code block affected: if (
roles.hasRole(roles.AUTHORIZATION_ROLES.InventoryLimited) ||
roles.hasRole(roles.AUTHORIZATION_ROLES.InventoryFull)
) {
addNavItem(locale.get("Inventory"), "dolly", "/inventory");
}
- This is all an issue with EditOwn rights, maybe I should consider zapping that entirely as a feature, why do I need it again????
- relevant info:
- C:\temp\xfer\v8 research stuff\JoyceAyaNova8stuff\1_REVISIT_2014-06\1_User_Roles_records\1_Roles.odt
- See "TechLimited" role for deets
- Tech-Limited
• suggested use:
• for tech that can view all views except Profit/Loss
• access to Info, To Do, Completed, Materials & Service, Quote if there, Invoice if there
• can not generate quote, can not generate invoice
• can not edit their Scheduled item fields (who scheduled, when, est), but can add the labor with it
• can add workorder components (i.e. parts, loans, etc) but can not view costs
• can create new client, can create new unit
• can only edit client or unit that they themselves created
• Can view service history, PMs, of client/unit
• Can only edit Open workorders where they themselves are scheduled.
• What can edit, refer to WorkorderRoles doc ???
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1782
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1809
- EditOwn is originally intended to deal with limited rights users who are not supposed to see other workorders but the ones they are supposed to work on.
- ISSUE: if they can only edit own widgets but not create or change others, do they still see the list of widgets?
- How do they create one, are they allowed to?
- What role allows create but not edit or is that a thing?
- WTF?
- This is to support users that are limited to their own records in order to privatize general things as people have requested.
- They want users to only be able to see some limited things
- The plan was to allow edit own, but that seems to be a can of worms because
- How to show a list
- Can they just create without the list?
- Can they view their own in a list?
- Is this above roles in some way or part of them?
- Can the server just show a list of self-owned?
- Can the client check a right and decide that since they can edit own they are allowed to see that feature section but it might be empty?
- This seems wonky to me right now but maybe it isn't, it's been an idea for some time but maybe not really questioned in reality scenarios.
- Edit own is only about workorders? Or everything?
- Issue is that this means every possible way of viewing widgets for example needs to have exceptions for people of limited roles who are only supposed to see their own widgets that they created.
- Does this mean every list fetcher needs to check rights first then add an additional filter if they are only allowed to editown restricted to owner=currentuserid?
- Would that solve this problem?
- Is this only about workorders or other types of records??
- Maybe it's as simple as adding an automatic filter to the getmany routes in bizobjects that add if editown and filters on ownerid=currentuserID
- Plan calls for limited users to be able to create a client for example to fill out a workorder even if they are a subcontractor with limited client rights but this seems bogus, the requested feature is probably more to do with they can fill it out but not create major new objects, only select from them.
- POTENTIAL SOLUTIONS
- NAIVE SOLUTION
- Just add more code to show the editown able stuff in addition to the full or limited rights
- Add more code for all getmany lists to auto-filter on own if that's the only right.
- A new right for does the user have ANY access to an object for the client to quickly check and show sections / lists?
- GetMany list object checks if only right to that list is editown and then adds a filter automatically to only show ownerID=currentuserID
- Client checks not only full and limited but also edit own and if there is any editown then allows to continue
- Potential issue here: do we show all of inventory if user only has editown rights to widgets and not parts (for hypothetical example)
- Re-think the editown system, what exactly is it solving and is there another way to accomplish that?
- For example if it's only about workorders then
- Can we stick to the Change and Modify rights and just have the ability to assign workorders to lesser rights users user by user?
- Does edit own even work?
- For example, this means that a user needs to OWN a workorder to be able to edit it if they are subcontractor, that's NOT how it would happen in reality dispatcher would make it
- The roles source docs say the user must appear on the workorder to see it.
- Maybe it's more of a right thing that has nothing to do with editown and more to do with relevancy, so...
- A service workorder is relevant to a non roled user if they appear on it even if they are a subcontractor
- However they only see the bare minimum they need and nothing else.
- Limited rights user can only select existing items to fill out a workorder? Not create new?
- STEPS TO RESOLVE THIS:
- PLAN: Is this an impedence mismatch between roles and sections in the UI?
- For example a role can have the ability to see a section of the UI but in that section some might not appear
- I.E. Widget is under Inventory section which is nebulous and not defined anywhere formally so cant' check in code
- But also parts are inventory but user may have no rights to parts so that's a sub part of the inventory section to be checked
- UI needs to know does user have *any* rights to this area and then show it and then each sub item checks the roles to see if a list of parts (for example) should show?
- So need a quick checker to see if any part of a section is showable maybe that is a separate system from roles
- READ: Go through plans and docs and look for roles related stuff and also subcontractor stuff to get a feel for what needs to be supported first before getting any deeper into this
- Maybe I don't have the full idea of what this is about
- Is this mostly subcontractors or is this also limited techs with limited rights?
- Maybe I can have full techs do anything and limited techs only fill out forms, not create?
- REQUEST: What is actually being requested by users to fulfil this feature that is different from v7?
- SCOPE: Figure out what objects this would even affect, maybe it's only the workorder
- TTM: We don't want to hold up all of AyaNova 8 over this, the default mode is to do what was there before in v7, is this worth holding everything up?
- Can it be a future feature or does it need to be in v8? Probably needs to be in v8
- Can this be worked without any editown features?
- Why does a user with limited rights get to "own" anything?
- Aren't they just a "filler outer" of forms and not a creator of anything?