Make CP role aware
andreiashu - February 17, 2009 - 02:22
| Project: | Content Profile |
| Version: | 6.x-1.x-dev |
| Component: | Base module |
| Category: | task |
| Priority: | normal |
| Assigned: | andreiashu |
| Status: | closed |
Description
I know that there are issues related with this one but they are for content_registration(#313341: setting up various content types for different roles) or are too old and not fixed.
So I'm opening this issue where we can add patches so that CP can become role aware.
Here is what I think we should accomplish:
1. when you mark a content type as CP you should be able to select the roles to which this is available
2. for every user show only the tabs with content types that apply for its role
3. anything else that i forgot ?
What do you think ?
#1
hmm this is how it works for me... check in permissions. i have 4 roles and 4 different content types and you can specify what roles are allowed to create, update, delete each of the various content types.
#2
Yes, but for ex. the admin (or a user that has permissions to create) can see/create all of the content types. Is there a solution for this too ?
#3
Here is a simple patch that does what i needed.
I'm thinking that it would better if we removed the "Use this content type as a content profile for users" checkbox and use the roles selection to determine if the content_type is content profile aware. If we do this then there will be many places where we need to modify the code so i opted to not make those changes before someone more experienced reviews this patch/method.
I think this method could better integrate with AAR module.
Also, based on this, maybe in the future we can add a feature that auto-configures the permissions for that content type + fields in respect with the selected roles (will be optional).
I updated the status as needs review even if this patch needs work, but I need it first to be reviewed by someone more experienced that can give me some directions whether this is a good approach.
#4
The patch failed. Patch applied to latest, beta3 version. Wrong version perhaps?
# ls
LICENSE.txt
README.txt
content_profile-display-view.tpl.php
content_profile.css
content_profile.info
content_profile.install
content_profile.module
content_profile.panels.inc
content_profile.rules.inc
content_profile.rules_defaults.inc
content_profile.theme.inc
content_profile.theme_vars.inc
modules
tests
views
cp_roles_aware_1.patch
# patch <cp_roles_aware_1.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git content_profile.module content_profile.module
|index 5095ddb..575c041 100644
|--- content_profile.module
|+++ content_profile.module
--------------------------
Patching file content_profile.module using Plan A...
Hunk #1 failed at 78.
Hunk #2 failed at 267.
Hunk #3 succeeded at 602 with fuzz 2.
2 out of 3 hunks failed--saving rejects to content_profile.module.rej
done
#5
@dejamuse: thanks, i'll put one for beta 3. that one was for the dev snapshot.
#6
The patch applies to Beta3 too. Please verify if you really have the Beta3 version (maybe you did some code changes ?).
# tar xzf content_profile-6.x-1.0-beta3.tar.gz# cd content_profile
# wget http://drupal.org/files/issues/cp_roles_aware_1.patch
# patch <cp_roles_aware_1.patch
(Stripping trailing CRs from patch.)
patching file content_profile.module
Hunk #3 succeeded at 606 (offset 4 lines).
#7
No matter what I try it fails to patch with exactly the same error message.
I downloaded a fresh copy of content_profile-6.x-1.0-beta3.tar.gz and the patch file too.
I attached the .rej file (renamed to .txt) if that helps.
I did this on FreeBSD 6.3, but that shouldn't matter.
#8
Edit: Rename it into tar.gz instead of tar_.gz
#9
I see that the bug with the attach still exists on d.o.
anyway, here is what i was saying in #8:
"I attached the archive that contains CP beta 3 with this patch. See if you can test it out. Thanks"
#10
I finally got around to testing the patched module, but it doesn't seem to work.
When I create a new content type and look in the content profile section of the form it shows the check boxes for roles to associate with.
When I create a new user (logged in as admin) and then open the user's account, it still has choices for creating a content profile for all the roles.
If I log in as the user without permissions, there are of course no choices. If I give the role the permission to create a content profile for his role, than only that choice shows up, but I think that's the way the unpatched module works.
Am I missing something (drank an awful lot of beer last night...)?
#11
More:
If I create a new content profile type and a new user with the corresponding role, as admin I see the old content profile types listed, but NOT the new one that's associated with the user's role, so it seems to be doing the opposite of what's it's supposed to do.
#12
There are two other modules that create similar functionality for information added to a standard profile that might help with understanding how to accomplish the same for the content profile module:
Profile
Profile Role
#13
I've just committed some significant improvements to the registration integration. Now this should be easier to do.
-> I think the setting of CPR itself, can stay and be interprated as "add to the default registration page". For other non-default pages I think we would just need a separate option to turn it additionally on by path.
edit: or by role depending on how AAR works.
#14
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
HI All,
the last few post are a little unclear. Is it now possible to restrict content profiles to roles with the patch provided in this thread or not?
#17
@hixster: it looks that this problem is still unresolved... :-(
#18
I took a look at the patch in #3 and made the same changes to the content_profile.module from Content Profile 6.x-1-0-BETA4
It seemed to work, but had some unwanted side effects, so I am going back through it to see if I can figure it out.
Our use case is as follows:
2 content profile types:
- staff profile
- member profile
3 roles that concern this:
- webmaster role (able to add/edit staff profiles or member profiles)
- staff role (able to add/edit own staff profile or add/edit/delete member profiles)
- member role (able to edit own member profile)
Currently, when a user with the 'staff' role edits a user with the 'member' role, they can see the tab to create a 'staff profile' - when this 'member' should never have a 'staff' profile.
So it sounds like we are looking for the same functionality - namely the ability to restrict the user profile tabs and "Create user's profile" links to display only on user profiles who's role is associated with the profile type.
If anyone else has made progress with this, do let us know.
#19
#18 : I'm in a similar situation, I'm trying a lot of user/role modules, but it looks that this particular use case is not solvable with the current modules and core status.
Look at:
- http://drupal.org/node/673732
- http://drupal.org/node/673760
for some ideas I've had.