Access control solution - Workbench Access

[MaddyDaigle]

Hello,

Just wanted to post a discussion here on access control and what the potential solutions will be for the WET Drupal variant.

From the last discussion I was in, workbench access had been removed from WET Drupal (at least for now) for a variety of reasons. I was just wondering about the status of that. I know that ERS was mentioned as an alternative. http://drupal.org/project/ers , although from what I understand, it seems likes it's more for workflow, instead of access control.

Any other suggestions or comments?

Thanks! :)

[liquidcms]

Hey Maddy,

Great that you started this thread as i think it needs to be discussed (and as per my rant at the meeting; the higher level "Roadmap" for this project is also very much required - for which this would certainly be an item on that map).

I am not sure what the reasons were for pulling out Workbench from the distro as it seems like a pretty basic function that is required by most/all GoC groups looking to utilize this distro. The only reasoning i think i heard was that it was not developed using ctools plugins (although i doubt that is the reason as most of the modules, for example the entire drupal core, does not use the ctools framework). Perhaps the reason was that it was not i18n happy? Although we (i.e. LiquidCMS) did solve the i18n issues for the CTA project and those patches have been posted back to the Workbench project.

That all being said, merlin's ERS project does look like it does a similar function as Workbench does; although not yet as polished (from demo video; haven't checked out Beta release) as Workbench. And of course, something that needs to show on our missing Roadmap is how i18n happy is it. Historically, although obviously one of the top Drupal devs out there (ok, let's just say THE top), merlin is not usually too concerned with i18n. I think a critical part of the "roadmap" and the "acceptance criteria" for modules in to this distro should likely be "i18n aware" as i am pretty sure this is a key component of this distro and there are certainly modules included in the distro which are not i18n happy... but i digress...

Perhaps, in prep for our roadmap discussions you could describe what you are looking for as far as workflow, access control, etc. I know there are a lot of different terms in the Drupal world for similar and completely different ideas of what "workflow" encompasses. One of these discussions can be found here: http://drupal.org/node/732578#comment-4850780 where i was trying to determine the difference between Workbench and Workflow (before i was familiar with Workbench) and many people were trying to state it was a replacement for Workflow - which it is not.

Feel free to contact me any time and we can discuss further.

[patcon]

@liquidms I think the concern was that Workbench in general seems very opinionated and does everything its own way. My understand is that it was developed at Palantir and, while it solved lots of tough problems, it was just kinda dropped into the community as a turn-key solution. It doesn't use many of the abstract modules in the Drupal ecosystem that the community seems to be moving toward.

If wet-boew is really striving to be a long-term, future-oriented platform, I think the workbench discussion is an important one to have. I'm personally very wary of workbench's fit into such an ambitious project and long-term project

(You do raise a very good point with i18n though :)

[liquidcms]

replacement of a feature in lieu of something better is always something to be considered for a project such as this - even better if it comes with an update plan (assuming it has data/config that needs to be migrated).

dropping of a feature with no replacement, on the other hand, seems to make less sense. especially with no roadmap for replacement.

i think the argument can be (and will be and i think has been) made that this project should be a minimal install and therefore if people want workbench, possibly because they can't wait for the replacement (which they don't know about); they can simply add on their own. But certainly with the list of modules currently in the distro; i don't think minimal is the goal anymore.

[patcon]

I actually rather agree with that argument if it's the current one.

I'd say it's less a matter of whether the whole project is "minimal" anymore, but rather that the project maintainers will become responsible for the "bad press" and huge volume of "unfun" (ie. not innovative) work in coordinating a migration solution for a number of diverse sites. What's more, these will be sites that have come to rely on one of the largest and most complicated module suites in the Drupal ecosystem. I'm unsure whether an easy upgrade path will exist, and so it may lock in the project and hold it back.

I find this to be a very good reason to leave this in the hands of individual site-builders for now.

And this is aiming to be an agile project, so I'd say scaling back scope is totally fair, to avoid servicing future technical debt.

[kavinay]

@patcon I agree, in the end WBA is probably not something you want turned on for every use case. Still, clear workflow and access control is a big deal in the government environment. Even if this isn't part of wetkit's default build, shouldn't the development and integration of WBA (or a similar solution) be a formal part of this project?

I was under the impression that us making variants of the WET-Variant wasn't what the maintainers intended. :D

[patcon]

Maybe I'll just clarify that the only reason I chimed in was to express my feelings that the project should stay open source in spirit :)

If we want to see something, let's:

• find the people who agree,
• fork the project,
• create a feature branch with a pull-request right off the bat, and
• give some other interested contributors commit access to that repo.

Those who think Workbench is the solution can invest in that, and those who don't can research another solution. We might disagree on the best approach, but we can all start working at putting forward one solution or the other with code. Not everyone will be in it together, but the best approach will prevail, and the project will be stronger for that :)

We don't need consensus to start working, and in fact, it's probably a weakness if we expect it before producing any actual working code.

Is that a fair approach? How about this can be the workbench thread? Anything said in here can be under the assumption that workbench is the way to go, and no one will disagree.

Oh, and when someone feels like committing code, this issue can be converted into a pull request using the hub extension of git: http://github.com/defunkt/hub#git-pull-request

[thriuin]

Whether it is Workbench or some other workflow solution, it is very much a goal of the core maintainers not to have to integrate into the WET variant a solution for every requirement that GoC and other implementers will encounter when building their websites. Modules are not added lightly, and while there may be more modules than we may have ideally wished for, most are there to support the advanced UX (panopoly, etc) and the WET toolkit (fences, etc).

Instead, I think @sylus and I were hoping that people would instead use the App mechanism to extend the functionality of the core Drupal distribution. The fantastic work being done at CTA by @joejoseph00 and others on a Proactive Disclosure App is a perfect example of people implementing a valuable function that many GoC departments will want to use without having to fork or modify the distribution and make it even more work to maintain. Workflow is another excellent candidate for someone to implement an App without forcing it into the main distribution. And just like with other extensions, people can try different solutions and the community can compare and pick the best solution.

[sylus]

Cleaning up some old issues. :)