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.

Comments

AlexisWilke’s picture

That'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.

naught101’s picture

Status: Active » Needs review
StatusFileSize
new7.14 KB

This 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

AlexisWilke’s picture

Status: Needs review » Needs work

Hi 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

naught101’s picture

AlexisWilke: 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..

AlexisWilke’s picture

In the following, whether you are creating or editing the node, we test deadline != 0

-    '#default_value' => $node->deadline != 0,
+    '#default_value' => $node->deadline != 0 ? 1 : variable_get('to_do_default_include_deadline', 0),

If you look at this one instead, we use isset()

-    '#default_value' => isset($node->self) ? $node->self : 0,
+    '#default_value' => isset($node->self) ? $node->self : variable_get('to_do_default_assign_self', 0),

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?

naught101’s picture

Ok, 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 ;.

naught101’s picture

Status: Needs work » Needs review
StatusFileSize
new7.06 KB

version 2, using isset($node->nid). works for me.

AlexisWilke’s picture

Status: Needs review » Active

Okay, 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

naught101’s picture

Status: Active » Fixed

I'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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.