Setting for not updating the node's expiration date on node edit/update (locking of expiration date)

I too need to somehow lock the expiration date, so that it doesn't get changed on each node edit-save.

Perhaps there should be a per-node 'Lock expiration date' checkbox + a setting in the content type options so one could define the default state of this checkbox. The setting could be a checkbox as well I think. Something like 'Lock dates by default'. A help text below this checkbox would explain that if this setting is enabled, the node's expiration date would not get updated once it is initially set to a date on first save.

A use case to support this request is this:

Consider an 'advertisement' content type. It is meant to be published for a year and after this period the advertised person is to be notified so they can re-subscribe in order to enable (publish) their advertisement for another year. So, the expiration date is set to one year after the node's initial published date. In the meantime, the advertised person wants to update their advertisement text after say 2-3 months of the initial post. If they do, (the way it is now) the expiration date will get updated and thus the advertisement period will be expanded. There has to be a way to prevent this from happening.

Sure.. This will be my next priority.

But this can be achieved if we hard code the date right?

Don't give users option to edit expiration date. Then add a default date in this format YY-MM-DD. This should work however if you supply +2 months, then it will not.

I know it is not a best workaround but just throwing my idea of achieving that.

I will make a release version tonight and will work on this feature soon.

Thanks..

I'd actually need to know how the module works internally to express an opinion on how this could be done, but let me simply brainstorm on this and perhaps this way I'll get the chance to help...

You are right, if the admin supplies a certain 'fixed' date as the default expiration date for each new node, then simply denying users the right to edit node expiration date (a feature already available through the 'edit node expire' permission) would suffice - I guess. But such 'fixed' dates are hardly of any use.

So let's concentrate on what can be done with cases when the default is set to something like '+1 day/week/month/year' or 'next Monday'. So, I need to ask this: when the date is entered in strtotime format, does it get stored in that format too or it gets 'translated' to an actual date before it is saved in the database? If yes, then we should not have any issue, since we are actually falling back to the basic though described in the previous paragraph. If no, than perhaps that's what we need to do (make sure the expiration date is always a date/timestamp instead of strtotime) - again, simply guessing here.

During node creation :
Lets say you enter +1 day, then it will be saved as "1281051478".

If you enter "2010-08-05", then it will be saved as 1280991600.

You could even specify something like this. 2010-08-05 6:00AM ==> 1281013200.

...so they are saved as timestamps in the db backend. Now that I know that, here's what I think might fix it (though I have no idea if/how it could be actually implemented code-wise):

The way it is now, the user is allowed to enter both 'fixed' dates (2010-08-05) and 'descriptive' ones (+1 day) in the expiration date field. Each time the node is revisited in edit mode, the field contains the entered by the user date in the exact format it was entered upon node creation. Fixed dates is not an issue, since re-saving the node has no effect to the expiration date whatsoever.

What happens with 'descriptive' dates is that upon re-saving the node, the expiration date is re-calculated based on the 'descriptive' date by comparing it to 'now'. The way I see it, we have to options in solving this:

1. We allow users to enter 'descriptive' dates in the field, but once the node is saved we change the 'descriptive' text to an actual 'fixed' date. This way, when the node is revisited/re-saved, we fall back to the case of 'fixed' dates that don't have the issue.

2. The initial value (timestamp) of the expiration date is calculated based on 'now', but on each edit after that it is calculated based on the creation date of the node's 1st revision. Here's how we do it:

- Before save/update, we check if this is a new node to be created or an existing that is to be updated.
- If the node is new, we simply do things the way it is now.
- If the node is an existing one, we check/calculate against the creation date of its 1st (oldest) revision.

There is only one extra thing I can think of that we need to take under consideration if we choose to go the second way. What happens if the node's first revision was deleted (for db maintenance reasons)?

Sorry, I am poor in explaining. Will try..

Right now it is doing what you said in your first case.

"We allow users to enter 'descriptive' dates in the field, but once the node is saved we change the 'descriptive' text to an actual 'fixed' date. This way, when the node is revisited/re-saved, we fall back to the case of 'fixed' dates that don't have the issue."

Just create a new node with "expiration date" as +1 day. Then when you try to edit that, you will see that "expiration date" is now in YYYY-MM-DD format.

This is good and works for every user who has edit expiration permission.

But lets say user who don't have edit expiration permission tries to create/edit a node.

Case 1: Default expiration date : EMPTY.
WORKS FINE AS NODE IS NOT CONSIDERED EXPIRED.

Case 2: Default expiration date : YYYY-MM-DD
WORKS FINE TILL NODE REACHES THAT DATE AND AFTER THAT, USER CANNOT SAVE THAT NODE.

Case 3: Default expiration date : +1 month.
WORKS FOREVER WITHOUT ANY ISSUES.
So every time user edits, node expiration date will change to +1 month. (I cannot recall now why I did something like that. Will try to give an answer tomo.)

But if you remove

// This gives a way to users without edit exipration permission to update nodes with default expiration.
if (isset($node->expire) && !user_access('edit node expire')) {
$node->expire = format_date(strtotime($ntypes['default']), 'custom', NODE_EXPIRE_FORMAT);
}

this from node_expire_nodeapi.inc, then Case 3 should also work as expected.

Hope this helps!

Sorry, I somehow missed this one. Digesting...