Re: [libreoffice-website] CMS requirements / suitability testing

Hi Carlos, *;

On Mon, Oct 11, 2010 at 7:46 PM, Carlos Jenkins <hastciberneo@gmail.com> wrote:
> 2010/10/7 Christian Lohmaier
> <lohmaier+ooofuture@googlemail.com<lohmaier%2Booofuture@googlemail.com>
> > [static pages]
> http://www.bestofdrupal.com/boost-static-page-caching-drupal.html
> http://drupal.org/project/boost

Thanks, so that point seems to be covered.

> > [user-friendly URLS]
> Those will be absolutely necessary:
>
> http://drupal.org/project/pathauto
> <http://drupal.org/project/pathauto>http://drupal.org/project/globalredirect
>  <http://drupal.org/project/globalredirect>
> http://drupal.org/project/transliteration (because of the i10n)

Not sure whether it 100%covers the requirement, but surely >90%

> > * Support for Translations
> > Key pages should be available in multiple languages, the CMS should
> > support managing those (without having the editor keep the list of
> > translations in sync, wihout the editor needing to update all
> > translations with a new link)
>
> Not sure what complex translations needs LibO have,

What I meant is that the system should keep track of the translations,
not do/assist in the actual translation. I.e. Show a list of available
translations, offer a way to add a new translation, make those
translations available in the visitor-visible site.
And yes, given the vast amount of available modules, extensions,
whatnot for drupal, I'd be surprised if there wasn't a solution
already. But hunting for those takes time....

> > * Support for subsites
> [...]

OK, covered, but:

> [...] User database
> table can be share between subsites but this is an advanced thing.

This is unfortunate. I mentioned subsites especially for sharing the
users, as many people in the OOo-project are active in different
subprojects, and I expect it to be similar with TDF/LO.

> * sufficiently sophisticated user-rights system
> > Not every user should have the possibility to change every aspect on the
> > site.
> > Some parts are reserved to be edited by admins, some areas are free to
> > be messed-around by community members.
>
> No problem I think, Drupal permission system is one of the most advanced and
> permit more granularity I've seen. You can create roles and give a lot of
> permissions to that role, even, with CCK, you can specify who can View or
> Edit a single field.

Oh, that's not what I meant. I mean assigning rights to modify user
permissions to a group of people, without those people having access
to modify every user.
With silverstripe you can restrict access to sites (view, edit,
publish,...) to individual users as well, and you can also create
roles that only an administrator might apply, but (I didn't really
look deeper into it yet) there's no way to declare someone as
"subsite-administrator" who could then add members to the subsite's
"authors" or "publisher" groups *only*, without that person also being
available to modify other aspects.

> > Specifically, it should support a review/approval workflow.
>
> You can setup a content type that is by default no published, and user role
> X can not change that, then, role X can publish it. This could be a
> rudimentary setup. If not enough, you can try things like this one:
> http://drupal.org/project/workflow.

Drupal people really hate screenshots, do they? ;->

> Check out this video about that:
> http://www.lullabot.com/videos/drupal-actions-and-workflow-video

Just states "missing plugin" without stating for what media type...
but I could download and watch - but unfortunately was a waste of time :-(

I would have been interested in the editor's experience, not that of the admin.
All he did in the end was letting the system send a notification email...

What I meant with workfow is: Author modifies a page, but cannot
publish to live site. He requests review/publication and then another
user with more privileges can either approve it, edit it and approve,
comment on it and do nothing else, or reject it with a comment.

> * user friendly editor
> [...]

covered

> [...]
> > The only drawback of silverstripe I found sofar is user account
> > creation/validation.
> > By default the email is not verified by sending a probe, thus a user
> > can create an account with an email-address that he/she doesn't own.
> > Only burden is a captcha. This puts a little burden on the
> > administrators to double check
>
> Drupal can send e-mail for validation if you want to and configured that
> way. Didn't understand about the burden, sorry my English, but you can use
> re-captcha or captcha on Drupal:

Using recaptcha is no problem with silverstripe either. My concern was
people signing up with email-addresses they don't own. A captcha
cannot prevent this.
So with burden here I meant "the only thing that prevents abuse in
this regard, the only thing a malicious user has to overcome"

Only way to control this is double-opt in like for mailinglists.

Well, it isn't a big problem in itself, as users who register would
only have access to the Forum (that we very likely won't use, maybe
internally/restricted for project-internal affairs), and not to the
cms itself.

And every user who would register does so to work on a specific
aspect, and thus the corresponding "project lead" will have to approve
that request anyway (to grant that user edit permissions).

ciao
Christian

--
To unsubscribe, e-mail to website+help@libreoffice.org
List archives are available at http://www.libreoffice.org/lists/website/
All messages you send to this list will be publicly archived and cannot be deleted.