Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.