I have a Role Hierarchy Setup with the following
CEO
-- Finance
----Department A Managers
------ Department A Users
----Department B Managers
------ Department B Users
I then only have 2 objects configured to Private
The problem is, we have certain people (Project Managers) that need to be able to view data from these two objects from different users in both Department A Users or Department B Users.
They should not be able to view data from either Department A Managers or Department B Managers.
Does anyone know how I can set this up to work with the above scenario ?
I've spent a lot of time on this and I am not sure the best approach.
Not sure if it possible, perhaps a trigger can be created (or workflow) to update the sharing rules of the record with the Project Manger? If that is the only solution then it might work.
Also I looked at creating a Sharing Rule but you can only share with a Role or Public Group, not an individual user.
Thank you
I think grouping and sharing is prob your best bet. So group dept.A&B users and group the PMs then share. Or you could add a field to your custom objects and share based on criteria, using the field as a flag, and share to the group of PMs. Maybe I've missed something.
Related
I am working on a database schema for a Laravel project and am unsure of how to design it properly. I have mocked up the majority of the schema, but am unsure of how to make the last leap to properly include users.
There are 8 tables, and the business model is meant to keep track of medical practices, the doctors assigned to them, their patients, the RXs that are written on those patients and what Meds are written in the prescriptions.
Where I come into the issue is that our users table will include our business' staff, representatives, sometimes the distributors of those representatives, and a select few doctors that will want to view their own production. So the users is a mixed bag of people spread across the Distributors, Reps, and Doctors tables with a few of our staff thrown on top of it. Thus far, I have created a 'UserRole' column in the Users table to reflect what the user's capacity is, but that is all.
Can someone assist me with how this should be reflected in the schema, and any thoughts on how to optimize the schema overall if they have any ideas? I am very, very new to both database design and Laravel. Thank you!
There are usually a number of ways to go about this but I followed an approach recently that provided a lot of flexibility for me.
So my simple approach is to keep the Users table as a base. With the minimum required user data like name, username, password, email, phone number, created_at etc and the User ID (user_id) would serve as foreign key to be used anywhere else that actually apply to all users.
From there, when creating a doctor profile, or a distributor etc, you follow the same user structure.
Hope this helps.
Sales representatives at Universal Containers need assistance from product managers when selling certain products. Product managers do not have access to opportunities, but need to gain access when they are assisting with a specific deal. How can a system administrator accomplish this?
A. Notify the product manager using opportunity update reminders.
B. Enable opportunity teams and allow users to add the product manager.
C. Use similar opportunities to show opportunities related to the product manager.
D. Enable account teams and allow users to add the product manager.
This is the question from the sample paper. I'm a newbie, i couldn't understand how the answer is B.
what does 'Enable opportunity teams' mean ? && how to 'allow users to add the product manager'
Opportunity Teams are a feature of salesforce. They allow you to modify the default sharing model (which might be set to private for Opportunities), and when you add users to an opportunity team, those users are given read and/or read/write access to that opportunity. I believe this is managed automatically behind the scenes by Salesforce via a sharing rule.
I have an ASP.NET MVC + SQL Server application with 250 simultaneous users daily which uses AD/NTLM SSO to do all the authorization using a custom authorization security class that control access to controllers & Actions based on users & groups.
A dilemma recently came up where the 50K+ account records of the database are going to be managed by different groups to varying degree's:
All users will be able to view most records certain records can only
be edited by certain users/groups of specific departments There will
be an admin & support groups that will be able to edit any group owned records
etc.
This is not a problem of who has access to what features/forms/etc. in the controllers, but instead a dilemma of data ownership restrictions that must be imposed. I am guessing this means I need some additional layer of security for row level security.
I am looking for a pragmatic & robust way to tackle data ownership within the current application framework with minimal performance hits since it is likely the same thing will need to be imposed on other much larger tables of data. Initially there will be about 5 ownership groups, but creeping up to 25 to 100 in the near future.
Sadly there are no cut and dry business rules that are hard and fast that can be implemented here.. there is no rhyme or reason make sense of who owns what except the record primary key id.
To try to fix it I was thinking of creating a table of owner_roles and map it to the users table then create another table called accounts_ownership that looks something like:
tbl(PK),row(PK),owner(PK),view,create,modify,delete
accounts,1,hr,1,1,1,1
accounts,1,it,1,0,0,0
accounts,2,hr,1,1,1,1
accounts,2,it,1,1,1,1
accounts,3,it,1,0,0,0
But in doing so that would create a table that was 250K lines and could easily get some crappy performance. Looking at sites like Facebook and others this must be a common thing that has to be implemented, but I am hesitant to introduce a table like that since it could create serious performance issues.
The other way I thought this may be implemented is by adding an extra column to the accounts table that is a compound field that is comma separated that would contain the owner(s) with a coded set of rights ie.:
id owners
1 ,hr,
2 ,hr,
3 ,hr,it,
4 ,it,
And then add a custom class to search using the 'like' statement.. provided the logged in users role was "it" and the comma's were reserved and not allowed in owners names:
SELECT * FROM accounts WHERE owners LIKE '%,it,%'
... however this really just feels wrong from a DBA perspective (ugly as hell) and a maintenance nightmare.
Any practical approaches on how I could implement this without destroying my site?
Start with Role-based access control, you can possibly skip the roles from the pure definition but should be able to implement it like this:
Every user can be in one or more groups like admin, support, it, hr
Every data row has an owner like it, hr
On Access, check the access: an admin can see and edit all rows. Support+it sees every row and can edit those from it etc. This way you need only (user-groups + row-access) new rows in your database, not (user-groups * row-access).
User groups in your scenario should be possible to hardcode in your application, in a CMS there is generally a table defining what rights to assign to each user group - complicating the coding but very flexible.
Roles in the original concept allow a user to select what rights he/she wants to use, there would be a "Unlock with admin rights" or the like in your interface.
Primarily for performance reasons, I went with the less elegant approach listed. It took some doing, but there are careful application controls that had to be created to enforce things like no comma's in the id's.
This is a design question.
I need to come up with a Data Model for a small app and I'm looking for the best approach.
A simplified version of the business I'm trying to model has the following entities:
Assignments: These are like projects, they have a start date, end date and a team of people associated
Workers: These are the people that execute assignments. A given worker can only be associated to one assignment at a time. Many workers can be associated to the same assignment at the same time (for big projects).
Manager: There's basically few managers in this business, who are in charge of allocating workers into new assignments as they come.
Then, there's the Web app that the Manager will use to manage who does what, i.e. which worker gets assigned to which assignment. The Workers will also use this app to register expenses associated to their assignments.
So in the context of the Web app, there will also be the User entity, and both workers and the manager will have their users to access the app.
My question is:
What's the best data model to support this (simple) system?
I picture this model:
USER (id, username, password, ...)
PERSON (inherits from user + name, email, etc...)
MANAGER (inherits from person + extra fields for manager only)
WORKER (inherits from person + extra fields for worker only)
What I don't like about this model is that every person must have a user. Maybe that happens today with workers and managers, but i will then add "customers" to this system, which will also have people associated that won't access the site, so they won't have a user.
Is there a better approach? Is there a standard approach without inheritance maybe?
Update
Ok, based on the model suggested above and completing with some extra info about this particular business, here's the (basic) model.
PERSON
id
email
passmd5
role_id
firstname
lastname
...
ROLE
id
description
PERMISSION
id
description
ROLE_PERMISSION
role_id
permission_id
COMPANY
id
name
contact_name
contact_email
ASSIGNMENT
id
customer_company_id
start_date
end_date
location_lat
location_lng
location_description
MACHINE
id
brand
model
description
PERSON_MACHINE_EXPERTISE
person_id
machine_id
Here's some extra information about the business to help understand the whole diagram:
The business consists on sending people who are experts in some kind of machinery to different locations around the world, to give service to a given customer.
There are people who are the "experts".
There are people who are the "managers" (probably just one, but there could be more).
There are assignments (a job, basically, which requires expert people to complete the job, sometimes more than one expert).
There are customers, who are basically companies, not people.
There are machines.
There's information about which person is an expert on which machine.
Makes sense? Any ideas that may improve this?
To approach this problem without inheritance you could perhaps define a Person class and a Role class, with every Person having a list of Roles (or a single one based on the needs of the domain).
The Manager and Worker concepts will then fall under a Role class, with some people having the Manager role (the managers) and others the Worker role. This will simplify the management of all Person objects as modifying their status, permissions and such being reduced to updating the role in the system. It will also give you the flexibility of adding new Roles without having to modify the source: simple create a new instance of Role, say Customer and assign it to whoever Person is needed.
Lastly, you could create a another concept, call it Permission that defines what can a Person do, with Worker and Manager roles having a CanAccessWebApp permission (and the Customer not). This will offer you a lot of flexibility in the long run while keeping the overall relationship design rather simple.
For a possible solution using Active Directory and Exchange see my post below.
We would like to create a training database in SQL which we can use for our internal training sessions of our employees. Unfortunately I do not have any experience in database design and did not have a chance to buy and read a proper book about this topic.
I have just started to create a database after reading a few tutorials online and would like you to review my design and provide me with some feedback if I have started more or less correct.
The courses table will store our training courses with their duration, capacity and a small description of what you will learn on this course. The training session table will be used to link a course with a specific training and a date when the training will be done. The trainers are colleagues who provide the internal courses.
The attendance table stores the training session id and if an employee attended the session or if he could not.
Please find below our database diagram:
alt text http://img8.imageshack.us/img8/2464/trainingdb.jpg
Later on we would also like to store the job position a training course is relevant for.
For example our network introduction course is relevant for a Level 1 Analysts, a Level 2 Analysts and Team Leaders. Our ITIL course is relevant only for a team leader.
How would you store this information? Would you use a separate table with the positions and use a many to many relationship for this?
Many thanks,
Mathias
The structure seems fine. I'd suggest adding one more foreign key relationship, though: Attendance.EmployeeID should reference the Employee table.
Attendance doesn't need its own primary key. The combination of employee and session uniquely identifies it (a given employee can't attend a given session more than once, can they?). You should probably use the two ID columns for those as a composite primary key.
Do courses really have a capacity, or is it a session which has a capacity?
What's the UpdateTime column for?
A bit simplified, does not account for enrolment, but may help you with ideas.
Below an explanation of the tables
We use the module category, module type, course, programme, training method and post work tables to categorize the training module using dropdown lists. The relationships are 1:n.
The module <-> employee relationship is m:n. As you can see from the model, the intersection table is Trainer where we define the additional property of Priority to allow us to define trainer priorities for a module.
The training module <-> role relationship is a many-to-many relationship as a module can be relevant to many job roles. The intersection table is RoleRelevance and we define for each role required, recommended, probation and hide properties.
The training request table keeps a record of each training request that has been requested. We also have new starter requests were we do not have a domain profile / SAM we can link the request to.
The employee table is being populated from our domain controllers with AD queries while employees are requesting a training or trainers are being defined for a module. The table includes the employee smtp address used to send invitations. See my other stackoverflow posts for a code sample how to get this data.
We create meeting invitation with managed EWS for the employee, line manager, trainer and resource/room. The invitation id and status (accept/decline/unknown) are stored in the EmployeeInvitation, TrainerInvitation and ResourceInvitation tables.
Training sessions we create are being inserted into the training session table.