I've noticed that even if a decision is set as active, users can't vote on it. I wonder if we should refactor _decisions_is_open() so that it only looks at the open/closed status, and then update this status on cron.

Otherwise, we have an interface where the "Decision status" really means, "If it fits the date range *and* this is set to active." So if an administrator wants to toggle the status of a decision, she must also re-enter date values.

Comments

anarcat’s picture

anarcat commented

Yes, that's basically the way it works: "active" is just another way of "closing" a decision. It's a necessary, but not sufficient condition for a vote to be active. I know it's a bit odd, from a user perspective, but I prefer it that way, as it doesn't require a pesky hacky cron.

Maybe the UI could be fix for this to be clearer, maybe by bringing the "active/close" buttons closer to the date settings? Adding more comments about it would help...

Also, IIRC, there's no closing date by default, and the opening date defaults to "now", so decisions should be active by default... If not, there's clearly a bug here.

ezra-g’s picture

ezra-g commented

I know it's a bit odd, from a user perspective, but I prefer it that way, as it doesn't require a pesky hacky cron."

I'm in favor of interface improvements where appropriate but in my view, there are several compelling reasons to change the underlying functionality here:

1) Consider if an administrator wishes to temporarily close a vote for some reason. With the current functionality, rather than leaving the date range in place and toggling the setting, she must adjust both the opening and closing dates. This is counterintuitive and if the voting is to be closed only temporarily, than she has overwritten the desired date range and must re-enter it to open the vote.

With a dedicated "active" status, she would simply change the toggle and leave the date settings intact. Signup uses an active/inactive toggle and closes signups using Cron. Decisions is like Signup.module in that it creates nodes that have an active/inactive status (other than published state) that can be manually toggled as well as managed by a date range.

2) Having an active/inactive status simplifies database-level operations (and any module-specific Views integration) and is likely to be more performant. Currently if we want to generate a listing of all active/votable decisions, we have to select against a range of dates as compared to the current date, rather than selecting where active = 1 or 0.

3) The cron implementation would be relatively simple (and I would write a patch for it). Is there something in particular that you don't like about cron :)?

Having a dedicated status seems better for developers and end users.

ezra-g’s picture

ezra-g commented

After further consideration, I have to retract the part about "not being able to temporarily close the vote within the defined timespan ;). You would only have to update these dates to toggle outside the timespan. #2 and #3 still seems worth considering.

ezra-g’s picture

ezra-g commented

Two more thoughts:
Regarding performance - to find all of the decisions that are truly active, we'd actually need to select not only between the date range but select between a date range *and* the active/inactive status.

Also, having an active/inactive toggle that is observed regardless of date range makes it easier to use other tools, like Views Bulk Operations to batch open and close decisions.

anarcat’s picture

anarcat commented

#3 - The thing I do not like about cron is that it doesn't necessarily run reliably or at reliable times. So in theory, it would be possible for someone to access, view or even vote an on issue beyond the validity date if we rely only on "Active" status, if the cron has run after the close date (or before, even). There's window there where things get too fuzzy.

Regarding #2, I don't feel looking at dates imposes a significant enough performance enhancement to warrant such a change.

I like the fact that Active/closed status is separate from the dates. For example, it allows you to close a decision before the end date (but not open it before it starts), as you mentionned.

ezra-g’s picture

ezra-g commented
Title: Active/Closed status ignored for date options » Improve Date/Active/Closed interface
Category: support » task

I agree that the date range is useful. If we remove the active/closed status, we don't actually lose functionality (users can still temporarily close) and I suppose re-entering the date range isn't a huge cost. How would you feel about removing the active/closed status altogether?

anarcat’s picture

anarcat commented

Er. I don't feel very good about that. I think having active/close is a good idea: it gives people a quick and simple way to close decisions.

floater’s picture

floater commented

My service provider does not allow cron, and I think that there will be more.
That means that the closing has to be done by manual cron. So I prefer a check on closing date.

An other suggestion: what if Active/Closed is renamed to Enabled/(temporary) Disabled and moved underneath the date options?