| Project: | Advanced User |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | patcon |
| Status: | closed (won't fix) |
Issue Summary
I've spent the last couple of days digging through the code for Advanced User trying to understand how it does stuff with a view to fixing the bug that means in correct results are given for some filterings (#505202: Filtering by "Role is not equal to" selects incorrect users when users have multiple roles.).
What has occurred to me is that the vast majority of Advanced User's functionality can be replicated by using Views and Views Bulk Operations. As a demonstration of what I mean, I've built an exported a view which is attached. To try out this clone of Advanced User:
- Install Drupal 6
- Install Views and Views Bulk Operations
- Enable Views and Views Bulk Operations modules at admin/build/modules/list
- If you want to be able to tinker with the view (highly recommended) then also enable Views UI
- Go to htp://example.com/advuser-clone
I don't want to step on anyone's toes here, as Advanced User is a really useful module, but I'd like to propose that the 6.x-2.x version is the last to function as a standalone module. 6.x-3.x should be dependant on Views and Views Bulk Operations. As a module it would provide a view programatically, as well as some styling and also a few Views handlers to enable it to do things that Views currently doesn't seem to support out of the box.
Pros
- All of the query building work would be delegated to Views, so there would be no need to maintain that code.
- Using the Views UI, it is possible to tweak the View so users could put together their own version of Advanced User to suit their specific purposes.
- We void duplication of functionality.
Cons
- Having to write Views handlers to replicate the current functionality of Advanced User - these can be tricky to write.
- A degree of bloat - having to install Views and Views Bulk Operations to run Advanced User eats resources.
- A more difficult installation process.
In the meantime I'll continue to work to try and fix the bugs in 6.x-2.x, but it would be great to get some feedback on this idea.
| Attachment | Size |
|---|---|
| advanced_user.txt | 10.77 KB |
Comments
#1
I don't want to be dependent on the views module. I believe that views adds overhead that I don't need. Can you give me metrics of with/without views?
#2
#3
I totally respect your efforts as a module maintainer ernie, but my first thought on finding this module was "can't all this be done with a custom views bulk operation view that overwrites the user admin page?" This functionality seems to be a prime opportunity to create a distribute a feature module.
Most every drupal site uses views any how (though perhaps not VBO), and even if the queries were heavy, I imagine this view would only be visible to admin's anyhow, so I can't imagine it being too taxing.
Anyhow, I realize you've worked really damn hard on this module, and I don't mean to discredit any of that work, but it seems that the new way of doing things might now provide a more intuitive approach. Most of the upkeep of such a module would be handled by others, so I would think it would be a good direction. The dependancies would all be very mainstream modules, so they're likely already taking performance and optimization very seriously.
Anyhow, thanks for everything you do! Feel free to change the thread title if it seems appropriate :)
If you're interested in entertaining the idea, I'd be happy to help out -- I need an excuse to familiarize myself with the Features module anyhow!
I can look into those metrics if you still feel it's very important, but even if the query is slightly heavier, it's likely not a big problem for an admin page (?)
#4
@patcon: Feel free to provide a patch for this issue. I'm marking it postponed but if you provide a patch please set status to needs review.
#5
Thanks for the blessing, ernie. Just wanted to make sure that I wasn't going to step on any toes :)
I'll let you know if I make any progress (or hit a wall, for that matter).
Cheers
#6
Hello guys
Just want to say that would like to help in integrating this module with views. I've been using this module since I first met it ;) but I'm also a big fan of avoiding duplication of functions.
@patacon, any thought on how you would start doing it?
My first thought was to ship a view by default, so that when you install the module a view is created, and from then on we can start putting more things together.
Anyway, I'm more than happy to join the party if you guys find that ok.
#7
I'm A-OK with that, Federico. Sounds like you're talking about creating a view programmatically, which is a nifty approach, but I think this might be a bestr-suited as a feature.
#8
I'm A-OK with that, Federico. Sounds like you're talking about creating a view programmatically, which is a nifty approach, but I think this might be a best-suited as a feature. Specifically, I'm thinking Rules will come into play, and that can also be imported with as a feature package.
Here's the feature list from the project description page:
1.x can be handled with exposed filters, and 2.x can be added with exposing the operator. I'd need to look into #3, as I'm not sure what might allow it. There is the Advanced exposed filter module, but it's not a good route in it's current state... Plus it hasn't made use of ctools_exportables, so it's not integrated with Features.
4.x is possible through standard actions that come with VBO. There's already a simple, send mail action, but there's also the Views Send module. I'm not sure whether it's possible to include its action in a feature package yet, but I could work at it. Views send has the added perk of being able to send customized messages using tokens from other columns of the view. I guess the main thing is that anyone could easily add their own action without messing about in your code.
#5 can be implemented with Rules, which can already be bundled in a feature package.
I'm not absolutely sure about these ones, but 6.x sounds like they could be a mix of Rule or actions, all of which are exportable in feature packages.
All this might seem like a lot of work, but will result in others maintaining the majority of the code, and will also allow (for those with the know-how) to easily customize things without figuring out the guts of another module. For the record, features specify specific module versions, so each release of a feature package essentially promises that all the modules will play nice :)
Any thoughts?
#9
Anyone want to give this a shot?
It's still missing the permissions filter, but this can presumeably be added once the views_perm submodule for the Views hacks module is complete.
"Select all" is done more easily, and other filters and actions can be added quite simply. The UI could do with some jquery to clean up filtering a bit. I haven't chosen to use it, but there's also a view type that could have been chosen instead of "Page", called "System", and this allows this user admin page to overwrite the regular user admin page.
Oh, and the dev version of the Admin menu module has a submodule called "Administration views", which does effectively the same thing, but the filters aren't quite as exposed by default.
#10
Sorry. Redo. Forgot to add Send mail action. Also added dependancy on Views send so that its more flexible action is included, because it makes it much more powerful :)
#11
Please attach a CVS diff -up for my review. Note, if Views is not enabled this module must still work.
#12
Sorry, I think there's a misunderstanding. It can't be a diff because it's no longer a traditional module. It's created with views and VBO as a feature package, so there's no code, just configuration information. It's basically importable instructions on how your module's functionality can be built using pre-existing modules, which is what Features allows for.
If you'd be open to testing, install the Features module, and then install this advanced_user file like any other module. Navigate to the Features section of your site, and then activate it and it will pre-configure other modules to provide functionality very similar to your advanced user module, but with no need for upkeeping extra code.
#13
Finally got my head around the Features module. WOW, It is absolutely brilliant!
Will be testing this in a few days, will report back.
#14
I know, I'm just starting to play around with it too, and you feel so much more in control when using feature packages :)
Feel free to override the feature I posted and post any improvements here. Might want to add version numbers to it if we start doing that.
#15
Then I'm going to suggest you create a new module. This module must remain for those who do not which to be encumbered by views (me).
#16
Ah. ok. Totally understand :) I find it a little puzzling that you would opt to spend your valuable time (as any volunteer's time is considered) maintaining a code-base that could be looked after by others, but that's your prerogative. At the very least it gave me a chance to figure out the Features module.