Extend and customize Drupal functionality with contributed modules.
If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.
This module allow administrators of an ubercart store to allow access to view / edit / delete / change status of orders only to certain roles and based on current order status.
View orders by status and role.
(This feature replace 'view all orders' from Ubercart with view orders by status. For example you can now select for "role1" to view only New orders but not Completed ones. Also the user can search only orders that he has view access. Be careful that when you have 'view all orders' selected for that role this function is disabled and the user can see all the orders no matter of order's state.)
Edit order by role and status.
Delete order by role and status.
Change orders status by role and current order status.
This is useful when you are running a store, powered by Ubercart and you have certain users that handle the orders. For example if a group "shipping" only has to put orders in "Processing" or "Shipped" but NOT in "Complete" or "Payment Received" this module allow you to achieve this goal.
Drupal is quite talkative in terms of showing off it's content. Often it makes content accessible which we actually don't want to show. That happens for instance very easily, if you're using nodes as content containers only - never really wanting to show the actual node pages of these containers.
Allows for logging user actions on sensitive/critical administrative pages. Logging is limited to specific users and/or user roles (configurable). Logging only occurs on specific administrative pages (configurable). Features include:
If you want to share and work with your documents online Google Docs, Zoho, iNetWord, Office 365 or Sharepoint are most likely to be - depending on how deep you can dig into your pocket - the solutions of choice. Especially, a large legacy of documents in proprietary formats, such as MS Word or Excel, may discourage from moving to an online editor. Additionnally, legal issues might arise if confidential files are hosted by a third party service provider.
WireDocs is a lightweight remote file editing tool. It takes the best of both worlds: Drupal as a CMS being responsible for hosting files and applications on a operating system (OS) doing the editing part. The approach automatizes a manual process: a file is downloaded, edited by a local editor and uploaded to its original remote location again. WireDocs makes this procedure completely transparent from a user perspective. The user only watches the application opening the demanded file and uploads are processed in the background after the file has been saved. WireDocs integrates with Drupal's content structure, namely the Field API, and currently supports file and image fields.
As a Java applet bridges the gap between Drupal and the OS the client must fulfill some prerequisites:
Gives automatic access to users if they are referenced somehow to this node.
It's scanning automatically for references with unlimited deep path, so you don't need to worry anymore how to configure your permissions correct, because it's checking for references automatically.
User 1 want to edit or delete Node 1, but the owner of this node is User 2.
But Node 1 have node reference (via nodereference) to profile of User 2 and User 2 have another reference (via userreference) to User 1. So that means that User 1 is referenced to that node, so give him access to edit it (you can customized other operations).
See following chart for example: http://drupal.org/node/520062
Using with view_own module, you can disable view permission for users and enable them only through references.
- Just enable the module;)
- http://drupal.org/project/cck module with nodereference and userreference module enabled
- knowledge how references are working and at least one content type with nodereference or userreference field
The Open Semantic Framework (OSF) for Drupal is a middleware layer that allows structured data (RDF) and associated vocabularies (ontologies) to "drive" tailored tools and data displays within Drupal. The basic OSF for Drupal modules provide two types of capabilities. First, there are a series of connector modules such as OSF Entities, OSF SearchAPI, OSF Field Storage and OSF Views to integrate an OSF instance into Drupal's core APIs. Second, there is a series of module tools used to administer all of these capabilities.
By using OSF for Drupal, you may create, read, update and delete any kind of content in a OSF instance. You may also search, browse, import and export structured datasets from an OSF instance.
OSF for Drupal connects to the underlying structured (RDF) data via the separately available OSF Web services. OSF Web Services is a mostly RESTful Web services layer that also allows multiple Drupal installations to share and collaborate structured data with one another via user access rights and privileges to registered datasets. Collaboration networks may be established directly to distributed OSF Web Services servers, also allowing non-Drupal installations to participate in the network.
Node translation access module allows to control access to nodes for selected languages
When using the entity translation module for node translation, all the available languages will inherit source language. In this case, node will be visible on all available languages no matter whether it has translation or not. Using entity translation module you can deny access to nodes of selected language. You can deny access to languages per node. Users will see standard access denied page.
TAC Redirect 403 extends the Taxonomy Access Control module by allowing you to specify a redirect URL for each taxonomy term. When a site visitor navigates to a content page that is restricted by a taxonomy access control rule, instead of Drupal's standard 403 (Access Denied) page being displayed, the visitor is redirected to the URL entered for the restricting term. This can be used to send people to custom "upsell" pages.
For example, if your site has the taxonomy terms Basic and Premium, and these are used to designate content as only available to members at the corresponding membership tier, this module lets you redirect visitors attempting to access restricted content to a signup form for purchasing the necessary membership level.
The Restrict Abusive Words module restrict to use words or phrases in forms all over the site content. The Restriction can be applied on content form, comment form, user profile form, user registration form and webform.Restriction can also be applied based on user roles.
This module allows to authenticate to Drupal using Google+ account.
It includes PHP client library for Google APIs (google-api-php-client).
This module is independent and does not require any other modules or libraries.
This module is sponsored by DrupalSquad
Shield Pages modules allows the administrator to secure any page in your website by password. You just need to go to configuration page of this module and add path, password. After that the added path will be password protected.
This module allow administrator to set global password for all shielded pages.This module allow administer to set multiple passwords for shielded page per path. This module provide bypass password protection of shielded pages permission also. All the shielded pages will be accessible by users having this permission.
This module adds a permission which can be used to allow or disallow certain roles to delete the homepage node. This is useful when some roles such as content administrators need to be able to delete nodes, but you want to prevent them from deleting the homepage node.
At first sight, you may think it's just another fork of already available module on drupal.org like taxonomy_access or tac_lite. First one is a taxonomy control access based on roles, second one is a taxonomy control access based on users. But both of those modules miss the - according to me essential - inheritance notion :
if you have access to one term, you don't automatically have access to the children nodes. My module does take care about inheritance and this way permit a powerfull user access control.
The Custom Listing Pages module provides the ability to create custom pages with data from existing content types.
- Display data from an existing content type with various options including:
- View Mode to display.
- Filter by one or more taxonomy vocabularies linked to the content type selected.
- Filter further by the tags for each selected taxonomy vocabularies.
- Sort by (title, last updated date, created date)
- Sort order (ascending, descending)
- Entries to display per page (pagination)
This module differs from Views as one of its main goals is to allow a content editor to publish listings of content without requiring administrative rights to the Views module. In a larger environment, you may need site builders or delegated site section owners, to create a listing of selected content. Using this module, this can be done and it's as simple as "Create new content" of type Custom Listing .. select the content type "profiles" , filter the output by selecting any assigned taxonomy terms and then select one of the pre-defined view modes. The Site Administrators will have created standard entity view modes for the selected content type, which can be themed with the necessary fields.