I suspect this will be a candidate for a swift kick in the "won't fix" direction, but I wanted to start a thread to discuss it. ;)

webchick has been kind enough to use her UI-goodness powers on our beloved module (witness my cleanup patches over at http://drupal.org/node/153757). However, she really hates the per-project settings table. :( I know neither of us are thrilled with how it looks/works now. She asked what's the use case, and I explained it. However, given all the functionality in 5.x-2.*, I wonder if we really need this anymore. We've already got a much better way to handle betas, etc, which was the primary motivation for these settings in the first place. There's also the setting to only warn on security updates, which should handle a bunch of other people's needs to quite down the warnings. Do we still need this per-project and per-release stuff at all?

I don't want to spend a bunch of time improving the help text and trying to make the UI more obvious if we can just get rid of it entirely. But, I also don't want to work on a patch to rip it out if you feel strongly it should remain. ;) I certainly can imagine cases people would still want it, but it seems like a fairly complicated thing that only power-admins would use and understand.

Let me know what you think. Thanks!

Comments

NancyDru’s picture

I think you're talking about the ability to say "Don't warn about release 78.90" Several people have said they need this because they hacked release 78.90 and can't update easily. Likewise, the notes field holds information about why they don't want to update or what sites the module is used on.

dww’s picture

Title: Remove the per-project settings table entirely? » Improve the UI of the per-project settings table

webchick, merlin, and myself discussed this last night in IRC. we all agreed there are still reasons for this table, so it should stay. Turning this into an issue to figure out ways to make the UI more self-evident and clear for non-power-users who won't know what to do with it.

jQuery-based inline ignoring of projects on the status report itself would be slick, but probably a ton of work. Short of that, any other bright ideas?