These settings in a new todo should be able to be set from admin/settings/to_do, or perhaps a sub-page atadmin/settings/to_do/defaults :
* Status:
* Priority:
* Automatically mark this listing closed after the deadline
* Assign to self
* The following user(s) can mark this listing as finished:
-- * Only me
-- * Any assigned user
I'm happy to have a go at this, will wait for confirmation from maintainers.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | to_do-840076-defaults-v2.patch | 7.06 KB | naught101 |
| #2 | to_do-840076-defaults-v1.patch | 7.14 KB | naught101 |
Comments
Comment #1
AlexisWilke commentedThat's one of the entries in the TODO.txt file, part of the module.
* Set defaults for new To do items:
- Auto-assigned users and/or self
- Priority
- Status
And having more is okay.
However, I'm thinking that we should have 2 levels of defaults:
1) Admin (admin/settings/to_do)
2) Per User
That way, each user can have his own defaults.
Watch out as the users are handled in several places. In this case, the to_do.users.inc is the right one.
Comment #2
naught101 commentedThis covers everything here, except default assign to other users - I don't the best way to do that, and it's probably better as a per-user setting, isn't it?
this is against the DRUPAL-6--1 branch
Comment #3
AlexisWilke commentedHi naught101,
Pretty good. The date checkboxes, however, are not correctly handled in your patch. Before calling _to_do_fix_dates() you can test whether those fields are set (i.e. $has_deadline = isset($node->deadline);) Then reuse that flag to know what to use, the current value or the default.
The way it is now, if it is 1, it will set the value to 1. If it is 0, it uses the default which could very well be 1.
Thank you.
Alexis
Comment #4
naught101 commentedAlexisWilke: I don't follow. All I've done is re-use the existing module logic, and replaced the defaults with values stored in the database. What line are you talking about? I didn't think my patch interacted with _to_do_fix_dates() at all...
Re: the default being 1: that's the point. this makes the date selector visible, and makes users more likely to put in a date (which is the only real reason for making it the default). If users forget to put in a date then the form validation handles that..
Comment #5
AlexisWilke commentedIn the following, whether you are creating or editing the node, we test deadline != 0
If you look at this one instead, we use isset()
The reason why I don't use isset() on the $node->deadline is because the _to_do_fix_dates() functoin sets it. In other words, it is always set by that point.
Do you see the difference now?
Comment #6
naught101 commentedOk, I see what's happening. But something like
$has_deadline = isset($node->deadline);won't work, because if the to do doesn't have a date, then$node->deadline = NULL(which returns false for isset()), so isset doesn't tell you anything.Maybe using
isset($node->changed), which only appears when the node is being edited, and not when it's being created?or, I guess,
$has_deadline = isset($node->deadline) && $node != NULL ;.Comment #7
naught101 commentedversion 2, using
isset($node->nid). works for me.Comment #8
AlexisWilke commentedOkay, I decided to use the if() on the item status to determine the current value. It looks cleaner and it is checked in if you want to have a look.
Marking this active in case you wanted to do something similar based on each user? The if() simplification would then just require to test: has this user defined some To do defaults? (we'd need one flag so users can say they want to use the system defaults versus their defaults, and a neat feature would be a button to reset your user defaults to the system defaults.)
Thank you.
Alexis
Comment #9
naught101 commentedI'm happy with that - looks good.
I don't really need per-user settings (yet), so I'm happy to mark this as fixed. If someone gets the urge, they can re-open or open a separate issue.