Lets say I have content types of Department and Proposal. A Proposal is submitted from each Department users. There is also User(built-in Drupal user entity) with Super Admin and Authors(Roles).
Department: Id, Name
Proposal: Name, file, Department (node Reference)
User: Name, email, Role(Super Admin, Author), Department (node Reference)
I want to enable an Author user to only add a proposal with in their respective Department, meaning Author A in Department X could only publish proposals for Department X.
Authors can only view/edit (in the admin page) proposal of their department. This can be achieved by only permitting them to only view own content in the Permission page. But I would like to enable Super Admin to create proposal for a given department and only the relevant Authors can see it.
On the front end, all proposals will be publicly available to all user and anonymous user can view it. I only want to force this on the admin page while creating and managing contents.
How do enforce users to follow this workflow by only letting them list proposal only in their departments and add new new proposal?
Implements hook_permission for various actions .
Assign the permission to the user roles from : yoursite/admin/people/permissions
Also you can define access callback functions.
Related
On Account object we have a related list called contact.If we want to add contact we can use Contact related list. then contact related list will created. But on the contact i could n't find the Acccount name in Account related list on Contact. Both Accounts and contacts are m-m relationship
Your question is bit weird. And it's not really programming-related. If my answer doesn't help you - try asking again at https://salesforce.stackexchange.com/
The default setup in Salesforce is that Accounts and Contacts are in 1:n relation. So you have related list of 0,1 or more Contacts under Account. But when you're on Contact there's only 1 Account to choose from. And it's the "Account Name" field, a lookup (foreign key), not a related list with exactly 1 item on it.
You're 1 click away from viewing the Account. If that's not enough, if you really want to display Account data on Contact - there are options such as formula fields or adding "record detail" component to the page and making it use Account Name instead of this Contact. You can see it on the right side in my screenshot:
When you make new Contact you can select existing Account or click "New" in the lookup and create one on the fly. But relation is still 1:n, A contact will have 0 (possible but an edge case and generally bad idea) or 1 account.
Then there's a special table called AccountContactRelation. It's used to model "one guy working in multiple companies, for example being director in company XYZ small local branch and at the same time - head of accounting in company XYZ headquater". If you want that, a real m:n relation - you might have to enable few things in Setup and configure your Salesforce like this training course: https://trailhead.salesforce.com/en/content/learn/modules/admin_intro_accounts_contacts/admin_intro_accounts_contacts_relationships
But on the contact i could n't find the Acccount name in Account
related list
So... if you already have the "Contacts to Multiple Accounts" enabled and added to page layouts and stuff - then perhaps it's as simple as checking the Contact page layout and editing the related list to include Account Name. But I have a feeling you skipped few steps on the way.
My current Cube has two roles:
AdminSec: are for a few users only and refers to a Group of administrators in my Active Directory.
GlobalSec: refers to "Everyone" and gives everyone access to read all data.
We are now planning to incorporate a new department (MinimalDepartment) in our company. This department should not have access to very much of the information in our company, so my plan is to create a third role (DepartmentSec) and assigning a new Active Directory Group (MinimalDepartment) to this role. Also I will limit the access to my dimension data by deselecting all departments and only grant access to the relevant department in the Department dimension.
My question is: If an employee is a member of the Active Directory Group MinimalDepartment will they then only be able to see the data in the cube which the role DepartmentSec allows (which is what I want)? Or will they be able to see all data as they are also part of "everyone" and therefore also the role GlobalSec?
If it is the latter is it then possible somehow to create the role so "everyone" has access except those in AD-group MinimalDepartment?
It seems that I have to create a new group in my AD which contains all the departments which I want to include and then use this instead of "everyone". Fortunately my IT-supports could tell me that we already have this group so for me its not a problem.
I have Owner, admin and user roles.
There's only one owner and that's me.
How can I deny admins from editing or deleting me?
Owner has id 1 so if I'm going to check in isAuthorized() if the admin is not the owner I do this: $user['id'] != 1.
Now how I'm going to check if the user being edited or deleted is the owner. I know how to get the user id with this: $this->request->params['pass'][0] but not the user role.
I don't think I'd have "owner" as a Role. It's much easier to allow someone to be a normal Role-type, then keep an owner_id field in the items table.
That way, you can leave Roles deal with the higher-level authorization, and in the individual items action/method, you can check for ownership (often done with a custom isOwner() function to keep your code DRY).
In your PostsController->edit($id) function as an example, you can do a find() on the Post, then compare it's owner_id against $this->Auth->user('id') to make sure they can only edit if they're the owner.
If you want to retrieve Role and keep it available, you can do so in the AppController's beforeFilter with a normal find on the roles table based on the role_id field of the Auth->user.
I want to make an application where there will be different users and each user will have a set of friends which will be put in categories. There will be some default categories, but the user will be able to add his own. I was wondering which will be the best way to do this.
My idea is to have 3 tables - user, friends and categories.
The user table to have fields (one to many) for friends and categories (but I don't know if the user table will need any information about the friends and the categories at all).
The friends table to have a field for categories (one to many) and a field for the user (many to one).
The category table to have fields for user (many to many?) and friends (many to many?).
I'm not sure about the relations, too. I'm using PHP with MySQL and Symfony2 and Doctrine2. Please help!
EDIT
Maybe I haven't described exactly what I need. When you open the app, you see a login form. If you don't have an account, you should register - the registration creates a new user. This user isn't connected with other users (I'm still new to programming and I want something a little easier so it's something like phonebook). Each user has a list of friends and a firend is a row in a table with fields such as name, addres, phone, email, photo, birthday and so on, but they are added by the current user. The friends are not users. Every user is in fact an account with password and username and when you log in there is just a list of friends. So each user creates categories for himself and he has nothing to do with other users and their categories. The category will have only id and name.
So the idea is that you create an account, then create some categories and add friends to them just to have an organiser when you friends are born or where they live, or which is their phone number, but you create them and add the information about them, they are to users themselves. It's not like a social network. Just a notebook where each user can write info about his friends.
First of all, you need to understand the role of intersection tables: if user A labels user B as a friend (i.e. there is a many-to-many relation from user to itself), and you create a new table to represent that relation (the friends table), any additional information about this "friendship" should be linked to that table. So, if a user categorizes his friends in some way, the category applies to friends, not to user. There's no need for a relation between category and user for this specific purpose.
Update: since friends are not users, the friends table will not be an intersection table (and thus have only one reference back to user, denoting the "owner"), but the rest of the answer still applies.
I'm assuming each category will be a row in the category table. Additional information about the category might be added, but it should be limited to that. For instance, if you want to know which user created a category, you could add a foreign key to user labeled for instance "owner" or "created_by". That might be useful if categories created by one user are not to be seen by others.
Finally, you can relate friends with category. If User A can put user B in at most one category, then a foreign key from friends to category should suffice (i.e. a one to many relation). Otherwise, you might need another many-to-many relation, so an additional intersection table should be created (for instance friend_category).
You could avoid this extra table by employing denormalization, having multiple rows in friends where both users are the same (and in the same order) but the category is different (see also this example). Whether this is advantageous or not is beyond the scope of this answer, but IMHO using an extra table is better for now (it might seem more complicated, but it will be easier to maintain in the long run). (Update: if friends is not an intersection table, denormalizing like this is not really an option, so stick with the friend_category table)
In the end, your layout would look like this:
user friends friend_category category
---- ------- --------------- --------
(user fields) <-- user (owner) <-- friend (category fields)
(friend fields) category --> user (owner) --+
^ |
| |
+--------------------------------------------------------------------+
I can suggest the following table set for this (this scheme applies to the phonebook or social network tasks as well):
Table "Users" that stores all the information about users:
UserId
Name
Phone
Address
... (any other fields)
Table "Categories" that stores information about relationship categories:
CategoryId
Name
Table "Relationships" that stores information about relationships between users:
FirstUserId -> Link to Users table
SecondUserId -> Link to Users table
CategoryId -> Link to Categories table
So, any user is able to add new categories, and then reference them when adding new relationship to another person.
If you need to select all user's friends, you will have to:
select fr.* from Relationships r join Users fr on r.SecondUserId = fr.UserId where r.FirstUserId = <Current user id>
I'm trying my hand at google appengine and using the datastore with php and quercus.
I'm not familiar with Java or Python, so lots of learning going on here. I've got pages rendering, and i'm able to get data in and out of the datastore.
The app I am building has users, groups, topics and comments.
A group has users, and users can belong to multiple groups.
When a user logs in, I display the groups they are members of, and the topics of those groups.
I've got this currently built in MySql, and am now figuring out how to get it into appengine.
The way I see it, a group is a parent which has topics and users as children. Topics have comments as children.
However, I have to get the groups that a user belongs to when the user logs in. Therefore, I was thinking of a separate parent entity which stores the user, contact and login info, and that user would have children containing the group id which each user belongs to, so that I know what groups to fetch.
The users are children of the group so that I can display all the users of a group, but maybe there is a more efficient way to do it.
Like this
Groups(EntityGroup) - GroupName, Owner
↳ Topics - TopicName, Content, Owner
↳ Comments - Comment, Owner
↳ Users - userid
Users(EntityGroup) - userName, email, password
↳ userGroup - groupid
Then, when a user logs in, the logic looks like this
SELECT groupid FROM Users where password=hashofpassword+uniqueusername
foreach(groupid as group){
SELECT users from group;
SELECT topics from group
foreach(topicid as topic){
SELECT comments;
}
}
The reason I'm looking at it like this is because when a user logs in, I can't very well go looking through each group for the user, and I only would want to store the login info in one place.
Please don't recommend me to the code.google.com documentation, as I've gone through that many times already, but am not completely understanding what's going on with appengine.
also, is the way I've outlined above the proper way to visualize the datastore? I think visualizing the data has been a struggle which might be causing some of the challenges.
It looks to me like there is a many-to-many relationship between Users and Groups, yes? A user can belong to many groups, and a Group can have many users who are subscribed to it. The most logical way to represent this is AppEngine to is to give the User entity a ListProperty that holds the Key of the eahc of the groups to which he belongs. In Python, it would look like this:
class User(db.Model):
userName = db.StringProperty()
email = db.EmailProperty()
password = db.StringProperty()
groups = ListProperty(db.Key)
Whenever the User subscribes to the group, you add the Group's key to the groups list.
Likewise, the Group entity will have a ListProperty that contains the Keys of each User who belongs to it.
You wouldn't want to make the Users children of the Group, as that would make it very difficult or impossible for a User to belong to more than one Group.
The difficulty that you will have is that when a User joins a group, you will need to update the Group in a Transaction -- you can only have one User being added to a Group at a time; otherwise, you have the possibility that one write will overwrite another. Presumably, the User can be updated outside of a transaction, as he or she should only be joining one group at a time.