Post ending date

If I understand correctly, you want to be able to have a wishlist item 'disappear' from the list after a specific date. What are you looking for beyond the capabilities of the Scheduler Module (http://drupal.org/project/scheduler)? If you are looking for features beyond what Scheduler offers I'll need two or three paragraphs giving more detail and sample use cases on the feature you are requesting.

(BTW I've never checked that the Scheduler module works with Wishlist, but given that Wishlist is an extension of Drupal's core node capability I believe they will play nicely together.)

I suspect we'll go back and forth on this for a few rounds as I hone my understanding of what you are looking for.

I get the specific four step example you posted (I still don't get why you need this, but I get the four steps). To implement that feature, I'd add an administrative option to have wishlist nodes automatically get unpublished (or perhaps made private) after the configured number of days. The wishlist module's admin screen would let you set a 'number-of-days' in which a new user can post content. I'd hook into cron processing and unpublish/set-as-private all wishlist nodes owned by that user when the user's account creation date is configured-number-of-days ago. All wishlist nodes published by that user would disappear at the same time. The user would never be able to publish wishlists again after passing that date. The behavior would be the same for every user's wishlist entries in the entire system, no exceptions. In addition, I'd set up an administrative option to cap the number of wishlist entries a given user could have (with an option for unlimited). Here too this would be set for all users, no exceptions.

Given your two notes "Posting wishlist duration?" and "Restrict posting duration date?", I suspect that my assessment and implementation of your feature would be to narrow. I also suspect that my interpretation of your feature request is unlikely to meet all your needs since I'm filling in a lot of missing details. I can make exactly those four steps possible, but what other capabilities are you looking for that will not be possible with that implementation? I cannot implement what I don't understand and I'm looking for help from you to understanding what you are requesting. So far your feature request and your response have been very terse, leaving too much for me to fill in.

The wishlist module was designed to allow authorized users on the site to publish 'wishlist entries' (nodes) to share birthday/holiday/occasion lists easily with friends and family. The wishlist entries are collected up into lists organized by the user who created the entry. Authorized users can indicate that they will purchase an item, and the wishlist module tracks that action. Nno anonymous purchases are allowed by design. A given wishlist entry carries up to two reference URLs to tell people where to find the item, an estimated price (and currency for that price), title and description. There is a capacity to mark an item as private, in which case only the user who entered it can see it. This if for tracking items that you might want, but would never expect somebody else to get for you.

What are you looking to do, and how much of the wishlist module's design matches with it?

Scott

Ahh. I understand that much better now. I'll start by saying no - I'm not going to add this into the wishlist module. However, I will describe a design that I think would work given what I've learned of Drupal. There are several areas of Drupal and its extensions that I don't understand, so this will have gaps. I'm not offering to implement the functionality though. You'll need to pick it up yourself or put out a bounty for it.

It strikes me that this capability really sounds like something that fits as its own module rather than as specific to the wishlist module or any other node type. In more general terms, what I understand you are asking for is the ability to enable permissions based on a payment event, and then unpublishing (or deleting) nodes based on a fixed expiration date. The two functions are linked - a scheduled unpublish/delete is recorded based on the payment.

The module would need to maintain an inventory of what was "purchased" by each user. Something along the lines of
* uid of the purchaser
* purchase date
* expiration date of the purchase (if null/0, the right to publish does not expire until used)
* node type (that the purchase allows the user to publish)
* duration of node publication, in days

And the module needs to maintain a table of node IDs and their expiration date.

The logic is then split into three parts: the purchase part (which populates this table), catching the publication of a given node type by a given user and recording the unpublish/delete record, and the unpublish/delete processing logic.

The purchase logic would probably leverage the ecommerce module, which I know nothing about (a large reason why I'm not prepared to implement this). I gather it handles payment processing. After a successful purchase out of inventory (which the ecommerce module maintains too I think), the module adds one row into the first table I describe. This table contains one row for each 'publication right' that a user has purchased.

There is a hook, which I've forgotten the name of, that I believe allows any module to hook into the creation of a new node type in the database. This module would need to define that hook, and it it would need to check that the user was entitled to create the node type to begin with (this logic might need to go into a hook that happens as the form is drawn), and the logic on saving writes out an entry to the table that records when a given node should be expired based on what was purchsed. It also needs to delete an appropriate 'publication rights' row. Come to think of it there is a complication here that I don't know how to handle - the user needs to select a publication-right that they are exercising before the form for the node being published (wishlist or otherwise) is presented.

And finally a hook for cron, which runs through the table of node IDs and expiration dates looking for nodes that have expired. It will either unpublish them or delete them, depending on your design.

I hope that helps. I still don't grasp why you want this done, but I think I do get what you need now. It's not a fit for the wishlist module and I believe would overcomplicate the code for a feature that I really think would work better as a stand-alone module.

Glad I was able to help, even if it did not take the form of code.

I'm still intrigued about the setting in which you have a user base that will pay to post wishlist entries. Are you willing to explain? I'm curious.