I am currently working on a small Drupal contract and part of the work is to allow files to be attached to content that only a particular user can see (User A); the trick is that the person uploading the files (User B) isn't the person that should be allowed to see them.
This technique requires a few settings and modules to work.
Setup Drupal to serve files privately, not through HTTP in admin/settings/file-system
Ensure you have the following modules installed and enabled: CCK, FileField (a CCK file field), ACL (access control lists) and Content Access.
Create a new CCK content type and in the Access Control tab enable "Enable per node access control settings" for that content type
Enable "administer access control" for the user/role of the person uploading the files
Create a new node using the CCK content type and once published change the access permissions on the node to allow only User A to see the files.
Done!
This seems to be working so far but I have more testing to do.
I have been running Drupal since about 2003, thanks to Boris. (Take that either direction you want BMann... ;)) And now that is is starting to "get popular and take over the world" - in quotes because I am sure Boris has said this at some point in the last few months - I am getting slammed by spambots.
I have about 13000 spam posts on my personal blog (it Googles quite highly) and less on this site. I used to use the Spam module when I was running Drupal 4.x but when I moved to 5.x that module was not ready for prime time so I skipped the installation.
Whoops.
Now, I have remediated this fact by putting the more capable (hopefully) Akismet spam module in place. Sure, it required me to get a WordPress.com user account (took all of 30 seconds - good work Lloyd & Co.) to get an API key to use this module but when I had the thing up for a grand total of a minute and the spam blocked count was already at 1, I know I had a winner.
If you run Drupal - use a spam guard of some sort. Or enjoy pressing Delete 260 times, as I will when I finally get around to removing the backlog. I guess I should file a feature request "Ability to purge an entire queue"...
I have just updated/upgraded to the latest Drupal (5.0!).
The upgrade went fairly smoothly on my "work" site but the two version hop on the "personal" site was a little less smooth... I had forgotten to keep that site upgraded as well as I should have. A couple of tries and some manual database checks later; I am golden.
All in all, the response time is much quicker, the re-organized administrative console is great and the new default theme "Garland" offers this truly slick javascript colour picker!
In addition, I have taken advantage of the multi-site support that Drupal has built in and now only have one code base to maintain!! This version really sings and once I get back into the groove of customizing it I think I will invest some quality time making it look a bit less like every other Drupal site with the default theme installed.
Oh, and Greg, I nuked your last comment post ... Sorry!
I just exchanged a quick note with Jeremy Andrews (the maintainer of the KernelTrap.org website and the Drupal spam module) and he has declared the spam module ready for 4.7. (4.7.1 due to a recent security patch update).
I have delayed moving to 4.7 because I can't run a Drupal site without the spam module. I regularly get hundreds of posts a day that I would have to manually delete without the automated wonder that the spam module is. My free time is waaay too valuable to waste on comment herding.
Now I will be able to upgrade this site (and others) to 4.7 and enjoy many of the great new "no programming skills needed" features along with a spam free existance!
Download, install and enjoy!
A follow up to my previous post: getting mercurial 0.8.1 up and going on your intel mac
But I need a better interface than command-line: I use a Mac; I love my mouse; gimme a freakin' GUI with nice shading ...
That aside, I have successfully ported about 70% of the Spam module UI to Drupal 4.7. I punted the .diff off to Jermey Andrews at kerneltrap.org (the fellow who maintains the module) and am awaiting comments on my patch. The remaining screens are Custom Filters and URL Filters. They are going to be annoying. I may have to redesign them to make them work in the 4.7 Forms API world and they do scream for some AJAX-y goodness in some regards. One step at a time however...
Notes on the Forms API in Drupal 4.7:
Very clean design. I like it a lot. The separation of validation from submit is a nice touch that does a lot of magic for you (just call form_set_error and the validation returns to your errored form!). Additionally, the weighting of the form elements in a nice touch to control their position. Congrats to the Forms API crew.
This is more or less my first attempt at making a real Drupal contribution that will see the light of day. I feel giddy and tired. Still have to sleep don't I ...
I received a nice email from a person asking if I had updated the ATOM support I welded into the Aggregator (version 1) for the latest release of Drupal (4.6.6). I wanted to say "Thanks" to the person (Tom) for contacting me and also to let him know the response I sent got eaten by some email forwarding rules on his end.
Since Tom seemed to enjoy the functionality and the fix is quite simple I have patched the 4.6.6 Aggregator (version 1) to support ATOM feeds for those that do not wish to move to Aggregator2. I am confident this works with 4.6.5 as well since there are no differences between the 4.6.5 and 4.6.6 Aggregator (version 1) releases.
I have again gone with a drag and drop replacement method so if you grab the attached file below in your modules directory, overwriting your current Aggregator.module (that you make a back up of first!).
You can now subscribe to Atom feeds as you would subscribe to any RSS/RDF feed in Drupal!
Note: if you download the file and it is named aggregator.module.html then rename it to aggregator.module before copying into your modules folder.
I have just finished the longest install session of Drupal ever. 20 minutes.
As I am still learning Tiger (OS X 10.4.x) and more specifically the Intel release I have had to find/update some of my base utilities used with Drupal. This is also the first time I have used MySQL 5 (5.0.18 in my case) with Drupal and what follows here are the steps I had to follow to get it up and running on my iMac (Intel).
I am assuming that your install is fairly new and that you have installed MySQL at this point. Once installed you will be running MySQL 5.0.18 and the default Apache and PHP installed by 10.4.5.
Step 1: download Drupal 4.6.6 (or 4.7 Beta 6)
Step 2: setup your database, load the schema, configure Drupal
Step 3: update the php.ini file in /etc/ to put the mysql.sock file in the same location as MySQL places it. In my case, this was /tmp/mysql.sock. If you have not already created the php.ini file you can copy the php.ini.default file to php.ini and edit that.
See this Apple Tech Article for more detailed information
Step 4: reload Apache
Step 5: continue Drupal'ing
Now with this out the way I can finally test my changes that add ATOM support to the 4.6.6 Aggregator.
The current released version of Drupal 4.6.x does not support Atom feeds. The attached module is a back-port of the CVS HEAD version of the Aggregator.module.
Note : this fix is tested on 4.6.3 only.
Just drop the attached file below in your modules directory, overwriting your current Aggregator.module (that you back up of course!).
You can now subscribe to Atom feeds as you would subscribe to any RSS/RDF feed in Drupal!
n-joy.
