I have this case where Designers and Managers works on a project with a certain Role.
Is this ER Diagram design correct?
I have doubt in Manager, Designer, Role, and Project relation.
ER Diagram:
Or do I just make it as attribute?
Here is the Database table Representation
The case also states to show that Administrator manages almost everything. Do I have to make a "Manages" relations?
Here is the complete case:
• Administrators can login to manage everything
• Managers can login and can work on Projects
• Designers can also login and can work on Projects
• Customers own Projects
• Managers, Designers and Customers have profile pages listing the projects they are related to. Administrator don't have.
• Managers can have Designers working for them
• Designers only have one Manager at a time and Administrator can change the Manager of the Designer at any time
• Managers and Designers who working on a Project is assigned a Role that the Administrator can manage (e.g. Project Champion, Lead Architect, Safety Engineer, etc)
• Project needs to have rich text as the description
• Project needs to be able to have many photos and PDF files
• Only Managers and Designers who is working on the Project can edit the project (Administrator also can)
Making Role an attribute means a Designer/Manager can only work on a Project in a single Role. Making it an entity with a cardinality of N in the relationship means a Designer/Manager can work on a Project in multiple Roles.
Between those options is the possibility of making it an entity with a cardinality of 1 in the relationship (meaning the PK consists of Manager/Designer and Project). Whether to make it an entity or an attribute depends on whether you have information about Roles or just want to record a value.
Your question about whether to make a Manages relation is unclear - I can't decide for you what "Almost everything" means.
Related
My company has 10 sales persons, and I want that each person can view in my sales cube, only the data linked to this person.
For example Anne MARTIN will only see her sales and not the sales of Patrick DUMONT.
I already created a role that work fine for Anne MARTIN, but if I have 10 sales persons, I have to duplicate this role 10 times and create a new one for each new employee.
Everybody use a Windows credential, for example "domain\amartin" and I want to use this credential in my role to link with my dimension "sales person" and authorize to see only data linked with amartin.
I found some code on the net but I did not obtain anything ...
Is it possible and how to do it ?
thanks.
Damien.
It is common practice to create roles and assign membership to separate operations. Often, the model designer adds roles during the design phase. This way, all role definitions are reflected in the project files that define the model. Role membership is typically rolled out later as the database moves into production, usually by database administrators who create scripts that can be developed, tested, and run as an independent operation.
I have two projects. I need to assign some users to project A and some to project B. Issues of Project A should not be visible to user of Project B and vice versa. Only project manager should be able to access and grant permission to project A,project B,project C etc. users.
JIRA is quite flexible about how you grant permissions. You can put people in a group (such as jira-users or jira-developers) and you can also put people in to roles within projects.
For your requirements you should modify the permission scheme used by your two projects. Do something like this:
For the permission browse project allow project role (Users) and the group Project Managers.
For the permission Administer Projects allow the group Project Managers.
Then, add all your Project Managers to the group Project Managers. Next, for Project A, add the users you want to be on this project to the role of Users for Project A. Similarly for Project B, add the users you want to be on this project to the role of Users for Project B.
This now means that anyone who is a Project Manager can administer projects and can also view them. But only users who have been given a Users role on a project will be able to see them and users that are not Project Managers will not be able to administer anything.
This is just an example of the kind of approach you can take. Experiment with putting users in groups (which you do in the User Management menu) and with adding users to roles (which you do in the projects administration menu). You will also want to add a new custom permission scheme and make sure that scheme is used by each of the projects.
This Atlassian page covers configuring permissions in more detail
I'm trying to setup customer access to some of my BigQuery data. I'll start off with my requirements, then what I think the solution needs to be, though I'm not sure how to execute.
Requirements
Separate billing per customer for queries
I don't want to make my dataset public
Read only access to specific datasets
Accessible via Excel connector
No access rights to my main project
They manage their own access privileges, I don't want to have to add and remove individual users from direct dataset access on behalf of all our clients.
Nice to have - Web UI access
What I've Done
Created a new Google Developer Project
Added a view-only user on that project
Added a service account
Granted access to my BigQuery dataset to the service account
Here are the options for granting dataset access from the documentation:
I imagine that I need to setup some sort of special group, but I can't figure out how to do it.
Thanks in advance!
In BigQuery there are two different concepts:
The first one is billing (for queries and any other billable
activity) that is linked with a Google Cloud Project.
The second one is access to a dataset.
Having said that, to fulfil your requirements you'd create a separate project for each of the customers, and grant access to the datasets in the granularity that you would want.
That way you would have the costs for each of the projects separated but billed to you. Be careful to give them only read access to the project, unless you want them to be able to create other services like VM or deploy GAE apps, as they'd be billed to you as well.
For example dataset [MyDatasetA] to users X and Y in projects Project1 and Project2, but access to [MyDatasetB] to users Y and Z in projects Project2 and Project3.
Thus, each project is accountable for the queries their users run, and you have your access control on each dataset without it being public.
Separate billing per customer for queries. Done with the independent projects.
I don't want to make my dataset public. Done with fine grained control access.
Read only access to specific datasets. Same as above.
Accessible via Excel connector. It should work without problems as they'd be first class BQ users.
No access rights to my main project. Again possible if they are restricted to their own projects.
They manage their own access privileges. This is trickier. I think they'd need more than read access to the datasets or more than read access to the projects to be able to add new users, if you use the project groups as access control.
Nice to have - Web UI access. Check out https://bigquery.cloud.google.com/
The project groups are groups that allow to select members with Viewer, Developer or Owner roles in one click, without the hassle of adding each member manually.
You get already three groups set-up for you to use: Viewers, Editors and Owners of the original project.
But you may create your own Google Groups and give those groups the permission you want.
The hint when doing so, is that new users will usually need to Display your project so that it appears in the BQ online browser. This is done by clicking on the arrow to the side of the project name in the BQ online browser followed by Switch to project then Display project with the project name that the Dataset belongs to.
Edit: Improved the explanation about Group access
Here's a question that I have been wrestling with for a while. We have a situation wherein we have a number of applications that we have created. These have grown organically over a period of time.
All of these applications have permissions code built into them that controls access to various parts of the application depending on whether the currently logged in user has the necessary permissions or not.
Alongside these applications is a utility application which allows an administrator to map users to permissions for all applications - the way it works is that every application has code which reads this external database of the said utility application to check if the currently logged in user has the necessary permission or not.
Now, the question is this. Should the user-permissions mapping information reside in and be owned by the applications themselves, or is it okay to have this information reside within an external entity/DB (as in this case the utility application's database).
Part of me thinks that application permissions are very specific to the application context itself, so shouldn't be separated from the application itself. But I am not sure.
Any comments?
You should read up on federated identity, which is the new trend.
We have for over 10 years maintained a library we used across all applications which centralized user authentication and authorization. It is loosely coupled to AD and has centralized roles and rights that are managed by the user community based on business needs and not the network personnel.
Our design has afforded us the ability to embrace the new trends on federated identity practices along with claims based identity and simply update our library allowing all applications, some of which are written VB6 to use current security requirements.
In a database I am designing I have implemented profile based object level security.
Each user can view, edit, insert, update database tables according to the profiles (roles) he is a member of.
Now there is a need to implement "External Users" who can view only the relevant records and edit some of them (but not the bulk of the database).
I am working on an "record ownership" model.
Are there any ideas on how to restrict the users belonging to an "External Users" profile to see and work with some records of each table, but not all.
You should probably create a VIEW which limits the records and then apply the proper rights on the view.
You could create a VIEW, or you could create select stored procedures and only assign rights to those.
The VIEW is the way to go for a simple security model - if it is complex, go with the stored procedure(s).
I have my first draft. It goes like that:
The app is a Project Management/Issue Tracking/Event Management/Collaboration Web app.
I created a Role "External User". By default a user in that role
can SELECT FROM Persons
can SELECT FROM Units (organizational units-companies-depts etc)
can SELECT Projects assigned to him
can SELECT Tasks assigned to him
can not SELECT any other Projects & Tasks
The administrator can create a user group "External Partner" and assign to that some Projects and Products (with Issues)
The members of this group can SELECT the assigned Objects.
It is a complicated solution, but the only one that solves my customers problem (they don't want external partners to have access to all their project database).