[support] Project Module - Directory Choices

Gary (Lists) listout at accidentaltechie.org
Sat Apr 15 19:48:37 UTC 2006


As an aside (and a chide), I think that no module should receive the right
of distribution if that module does not contain a community-verified set of
documentation.  If the author can't explain, then Drupal shouldn't endorse
it by delivering it.



I have spent 4.5 hours, with 14 open browser tabs to the Drupal site, and I
have finally actually gotten the project module to do something.

Of all the issues reported and requests for help on the site, there are
scant few usable replies, and loads of frustrated folks.  (I recently read a
review where the author said something like "I'd rather use separate
dedicated tools than Drupal's well-meaning but under-delivered modules."
While I don't quite agree, I do understand the perspective and the level of
frustration that can mount when moving from order to chaos...and freedom. ;)


So...now...I've edited the PHP to discover that I can add filetypes (a good
thing) and generally it's working, and I have gotten a few dummy projects in
place for testing

But...I have a few "now I'm working" kinds of questions.


Since each individual recipe of modules leads to wildly varying results, let
me outline my set-up as it is currently (generally) working:


filemanager.module      path = assets/files

+ project.module        release path = releases

        [Yes, gentle reader, you must use trial and error to know that
         this is relative to the above. No documentation exists.]

         This also means that actual release path =  assets/files/releases


                        issue path = issues

        [Yes, here we get some clear information that this directory
         is relative to the 'filemanager' path. A clue that we now must
         rely on trial and error to determine the 'release' path.]


+ attachment.module [See more below.]



Okay, so now when I place dummy "0.0.zip" files in the releases directory,
and update the project releases, the new releases show up appropriately and
all seems well.


BIG QUESTION:

Editing a project shows a list of Attachments, which can be 'hidden'.  But
this is only if items were created by using 'Attachment'.

Is there no similar listing for 'releases' (which were placed manually, and
then auto-updated)?

It seems strange that I should be able to hide any Attachments, but not be
able to hide any Releases.


(Also, attachments and actual releases seem like they should live in the
same place, a project-specific directory...?)


If I use the 'Attachments' button, so that my users can actually upload
files, then the do not get updated in the release auto-update.


I have experimented with setting the Content Type 'Project' to __disallow__
attachments, but then there is no project release upload ability.

So, will I need to provide FTP access to every user, into the same
directory!?

(I am considering using the FTP.php class to build quick upload system.)



Can someone help me reconcile whether I should be using the Attachment (I
want that, it's great for the ReadMe.txt file) privilege for the Project
Content Type?

Must I make my own way for users to submit their releases to this buried
directory [ assets/releases ]?


What part of this, after this many hours, am I now missing?  I feel so close
to having it make sense to me, which means it might make sense to a user.


Thanks for any guidance.

--
Gary


P.S.


The 'Issues' page -- at Drupal, too -- has the same link on every project:

    Support Forums  with a link to 'forum/18'


Is this not configurable?  If there __is no forum for support__ for this
project, why is the link there?  I have nothing at 'forum/18', yet the link
still appears.  (Users are taken to a blank forum page.)

Further, why is the link the same, since I'm looking at a project-specific
page, and why is it not the support link provided in the project's entry
record?  (I don't want to run support forums for everyone else's projects,
but I'm happy to link _to_ their support set-up.)





More information about the support mailing list