On my website, users have the possibility to upload different kinds of content (theme1, theme2, theme3,...). I also have different kind of user roles (author1, author2, author3,...). Every user role has only permissions to make, edit and delete one specific kind of content. I can do it the rough way and adding 8 different kinds of content types and 8 different user roles and make myself a complete mess while composing all the right roles.
I was wondering if there was a more easier way to do this in Drupal 7. The old D6-supported Upload Permissions per Content Type would have been ideal, but unfortunately, there was never a D7 version released.
Does anyone have an idea how to do this so I can just configure some kind of matrix to define all the user-roles and their permissions?
The "Content Type: Extras" module looks like it might help.
http://drupal.org/project/content_type_extras
Related
So, I have to build a website with 20 different languages, each language will have custom domain name. The Website will display products with details, some of the products will be available in two under tow different domains(language/ region), the others will be only for one. Accounts on the website will be available for people from the company to put translation and manage their own content based on their own language, BUT we need some users can have ability to access all of the translation with one login.
Now, by default I was thinking about One website with multi language, then I thought about having multisites installation since that make it easy for the people who have to translate their own content without dealing with seeing the other content or hit 'Translation button'.
Pros and Cons I came up with:
it would be easier to have for the people from different countries to
deal with their own content and have full customization to their own
instance, While for one instance site it will be complicated since I
have over 50,000 products.
it would be hard in the future to add new functionality for the
Multisites since we have to add it for the 20 instance. (not sure if
thats correct), while if we use One website it will be one change for
all.
What about one login?? not sure if there is a module support that.
But yeah this is my situation, Please help me from your experience to decide which one would be the best choice and why. Take in mind all of the will share same look and feel. But they will be 20 languages with 20 custom domains and 10s of thousands products and nodes. Should I go with D7 or D8?
Thank you, I appreciated.
Multi language is your solution here because you are sharing product and administrators/webmasters.
The module domain access (https://www.drupal.org/project/domain) will give you what you need in term of domain name management.
Multisite does not share configuration so if you want to add something to all domain you will have to configure it 20 times.
And if you need to add some modules for only 1 domain you can use Context (https://www.drupal.org/project/context) to specify your rules of display.
If I were you I will go with D7 because there is lot more stuff available right now, but the migration will be hard if you think about migrate to D8. And many modules are not develop for D8 right now so it s more secure to use Drupa7.
This is my first time building a site with Drupal (7). I have plenty experience with LAMP, HTML/CSS and javascript, but I want to make sure I am doing things the 'Drupal way' before I start hacking together a custom solution unnecessarily. I've searched forums and modules, but have come up empty.
The site I am building will have different tiers of users: students, teachers, and parents. The difference between these users is:
The information collected during registration, and
The pages the user's have access to.
I think at least part of the solution lies with creating roles for each type of user, but it seems Drupal only has one registration page for all users. How would I create a different registration form for each type of user? What is the 'usual' way of assigning roles to users automatically?
I know this is late the game here but I thought I might refer people to the "Rules" module... Instead of thinking about this from the "user-specific" registration form perspective, think of it instead from the perspective that you still have only 1 form but with additional / optional inputs, whereby subsequent actions (rules) are then enacted upon depending on the values of said additional / optional fields.
You might also check this out, too:
how do i make diffrent registration form in drupal?
I'm just updating my answer as I see it didn't apply for D7.
I've just begun developing a D7 site with a similar request.
There seems to be a module which should fit perfectly, although I still have to try it:
http://drupal.org/project/profile2
Good luck with it.
I just want some opinions on what's the best way to go about meeting the following requirements.
I have
One main Drupal Installation
It is a typical "listings" site where users can list items
One user can have how many ever "listings" that are linked to his account
I want to be able to create sub-accounts, that use the same base site. However, for each subsite:
Only the users listings must appear on his site
It must have a completely different theme.
It must have its own menu items
The site must run off it's own domain OR subdomain
I need some answers:
Is this possible, or will each user need a completely new Drupal installation and just use a web service or something to get its listings from the main site?
What modules / components will make my life easier?
Any other suggestions to make this as simple as possible?
The problem description is not detailed enough to give a fully sound advice (and - additionally - it looks like you could probably get better advice on a drupal specific forum, as the question seems more related to installation and configuration than to programming), however - from what I understand - it looks to me that your solution could give in either of the two directions:
Tweaking a single installation to appear as different sites
Creating multiple sites that shares the same codebase and part of the data
The tweaking solution has the advantage that you have only one DB to mantain, but there is no actual real separation between the subsites. You could implement this by:
SUBSITES: mapping various subdomains on the same IP
CONTENT: using the native permission system to filter which list items to display (for example: each logged user can display only nodes created by himself, or set to be visible to its role, or having as associated taxonomy term its username...)
THEMES : if subsites will be used only by logged-in users, use the same mechanism that you would use for filtering content [each user can natively pick a different theme if you allow them to], if they must appear with a different look also to anonymous users, then use the URI to pick up the appropriate theme (if visitor X reaches the site via user1.example.com the site will have the blue theme, whilst if the URI is user2.example.com the theme will be pink).
The multiple sites solution has the advantage that you have a real separation between subsites (with even a different DB). But you would then have to either sync or transfer "on the fly" data between the main site and the subsites. If you go for this solution, you should probably take a look at the following links:
the services module, which allows to easy set up webservices
this page explaining how to connect drupal to different databases (surely faster than using webservices... reasonable solution if you for example have sites and subsites running on the same server)
I didn't want to stick this in a small comment but I am in agreement with mac on many of his points (upvote!).
The best way would be to create your subdomains and have them be symbolic links in the site folder to the default / main-domain folder.
Given what you have told us, you are much better off creating a module that creates its own node types (or even just CCK) and use a combination of the permission system (CCK offers this as well through content_permission), Views, etc. No need for separate sites, just need users to look at their own content.
The beauty of this approach is you can use Flag to allow user's to friend each other, use Views to allow them to see friend's lists, etc.
Theme's can be set on the account level, so no issues there.
"Have their own men" - does this mean have their own block on the sidebar or header than has customized links or a completely different menu SYSTEM? Will need clarification before I can answer that.
I know I can set up a role to allow user's to only edit their own pages, then go mark the appropriate pages to be authored by the appropriate user. But then I run into multiple users per page problems.
Is there any way that you can explicitly only allow a user to edit certain (perhaps multiple) pages, while accounting for overlap in the case that more than one user may be allowed to edit the same page?
Thank you
This would be fairly complex to do programmatically, but a fairly easy solution is to create a vocabulary to apply to the pages and then use the taxonomy access control module: http://drupal.org/project/taxonomy_access to set the permissions based on terms.
I answered a similar question a few months ago, with an overview of implementing a few different access scenarios:
How do I give a specific user editing rights to a specific node?
If you just need a module that set the access permissions of a user to a node of a specific content type, then use http://drupal.org/project/content_access; if the content type is a book, then you can also try http://drupal.org/project/book_access.
Remember that installing different modules for access control should be avoided, as they tend to conflict each with the other.
If you have patience, then you can create your own custom module, and implement hook_node_access_records() and hook_node_grants() as suggested by Jeremy.
try http://drupal.org/project/coherent_access
or http://drupal.org/project/content_access
this ish is crazy!#!!!#!#!
This is also possible to do programatically using hook_nod_access_records() and hook_node_grants().
With hook node_access_record create a relm with the UIDs of the users you wish to allow. and in hook grants create a grant with the users uid in the same relm. It is not that scary and very flexable.
I want to allow only one type of user to access a certain content type. It's simple and I've done it before, but today I can't figure it out.
Generally this requires an access control module like Node Access. Using a module like that, you can completely hide certain kinds of content from users who aren't allowed to view them.
If you mean "read" access, you'll indeed need some form of access control module, as Eaton suggested. OG, for instance, is one access control module although quite often people don't think of it that way due to its other features.
If you mean edit/delete access, OTOH, you have these by node type vs role at admin/user/permissions.
And, of course, if you only want to hide nodes from non-admins, you can just unpublish them: only admins will see them.