[TYPO3-ect] Project-List in the Wiki: Enhanced Rights Management

[Jan-Hendrik Heuing]

> Hi JH,
> 
> maybe the be_acl-Extension has not been known at that moment of the
entry.
> Also today it is not so famous. I have got no exact idea what it does
> right
> now. I go to get me a cup of coffee and look into the documentation
...

It's probably because it's some niche thing. It gives you the
possibility to add be-rights to fe-users. That's what timtaw uses. You
get those backend-forms while not being a backend-user. Great idea, we
use it in one intranet-solution, to edit some records. No work had to be
done, as be-forms gave all what was needed.
Of course there are some other small features as well, but this is the
most interesting one I guess.

> Well, to someone used to UNIX 775 ACLs it looks pretty impressive. So
> maybe
> we could wipe out the ACL proposal from the wiki.

It worked in our case, but I am not quite sure if I'd call it mature. It
works, but it could probably taken much further. That was why I was
asking about the idea behind that wiki-entry :)

> But I think our task in this case is to communitcate the solution to
the
> community. That brings me to the idea to set up a list of basical
> extensions that are recommended by ECT. I don't think of end user

I had that one too. At least sort of ;) I had some other thing in mind
though. I had a short chat with Karsten and Robert to see if it would be
possible to extend TER and EM in some ways without too much work:

With the new EM/TER, and some more customizing, you could add a new
repository, which could be related to the public TER. But the special
thing about that copy of TER, you ONLY publish "ECT-extensions". Now
that you might want to install other extensions as well, EM has to be
changed in that way, as it would query not just one TER-source, but all.
Now you can choose whether you want to see all extensions, or just
ETC-extensions.

Sure you can say, keep it in one repository, add some checkbox to
extensions to filter those... BUT: The public ter has been reworked to
work as simple as it can. I'd be interested to move those extensions
into a more or less local repository, which is not just the filebase,
but does also have svn-backend and some other features you can access at
the same time.

> extensions like tt_news, but of extensions that set up the
infrastructure
> other extensions can build like be_acl and libraries. I will use the
term
> library for them all here.

Mostly I am with you. But as thinking, browsing, scribbling,... It seems
it would be interesting to have extensions being somehow communicated as
using the "ETC-framework", requirements which have to be set up, to give
some quality control. Yes, I know we had a few cases trying to get that
on the road, and it didn't work. And I don't want to start a discussion
on that now ;) But it COULD work out in some way: 1: Get it analyzed
automatically. If it uses some libraries instead of doing that on it's
own, we are sure that things are save; if it uses an ETC-validated
templating, it could also get some quality points. This is just rough,
nothing thought of in detail yet. 2: I guess it could work out with the
cert-thing Dominic is managing as well: Manpower did not work out to
check extensions, true. But what if you have companies doing that job.
You can not get done that quality control for your own extensions. You
could find some other company associated with certification, asking them
doing the job. Either you pay for it, or get a review in exchange.

Just collecting ideas here, does it make sense to get into discussions
about those ideas at this moment? Maybe not.

> 
> However every library brings it's own style of API and table prefixes.
The
> table *tx_dam_cat* could be used for global categories. In an
integrated
> solution the table would be called *sys_categories* or
*tx_categories*.
> We
> could make a difference between recommended libraries and integrated
> libraries.

I'd not suggest tx_dam_cat for a global table, I guess the others would
do a better job :-)

> Before we recommend a library we need to test it seriously. But we
would
> help the developers to decide, on what they can build their own
> extensions.

How? I guess it's at this moment, how about a lib-explosion like it has
been with extensions?
Just to pop in to at least have that in mind.

JH