Joomla! Discussion Forums

Just some feedback

1. I didn't say we aren't going to use ADOdb. We are just looking at preformance issues and are open for other alternatives. The problem with phpGACL is that it uses ADOdb and I like to have options no restrictions. I asked hackware to see if it could go without.

2. We will announce changes in the roadmap next week. This will give u guys a clearer view of what is planned when. For now I ca already say that 1.1 will focus on backend and frontend translations and is expected alot sooner as outlined in the  roadmap. More news about this soon.

An update from me,too:
After discussions with Jinx and Predator, I've done a bit work and rewrote the ACL-API to work with the Joomla-db-layer and not with mySQL. This is at the moment a proof-of-concept and is merely for testing if it will work. I can't even tell if the administrative-functions are correct because I don't have a frontend to try them with (hey, I'm a newbie at coding, I don't have such fancy things as a debugger 'n stuff. ) The frontend will be my next move. Now to the stuff you can get at the moment:
Package with corrected files to use ACL without ADOdb and with the most recent SVN: //EDIT: Took out the url/file cause its outdated
How-To for 3PD: http://forum.joomla.org/index.php/topic,12601.0.html
Naming guidelines for ACL-objects: http://forum.joomla.org/index.php/topic,12471.0.html
Handwritten manual for the API: http://forum.joomla.org/index.php/topic,3391.msg75172.html#msg75172 (Notice: This is a post I made earlier in this thread on page 2.)
Outline for installer/enhancment: Missing in action

The package contains the corrected files, a SQL-dump with the DB-structure and a few entrys and the generic phpGACL-Admin-interface (which takes most of the space. ADOdb IS big. I can understand the devs now.) You have to copy the files to their respective folders and replace the #__ in the SQL-dump with your db-prefix. To use the interface you have to set the gacl.ini.php correct. The rules set at the moment are only a fast hack to see if it works, because it was late and I had to get up early today.
The How-To and Naming guidelines are proposals from my side, they are not yet approved by the devs.
I had an outline for an installer-enhancment to create the onetime-setup of the ACL-environment for 3P Add-Ons, but it got lost somewhere in the depth of the net (or this forum...). I'm going to rewrite this sometime soon.

For all people monitoring this thread: I'm still working on this and am in contact with the devs. This "release" from me will be improved over time.
Writing back soon...
Hackwar

Hackwar,

Thanks for the update.  If you were able to get this to work with the Joomla-db-layer, that would really help!

Thanks again for your efforts.

Best,
Ryan

Hi folks,
after the update of the roadmap I have made up my mind about my work.
As it will need a lot of time till Joomla 1.2 will be released, I decided to make the stuff I made into a separate project. I will release the first files etc. when Joomla 1.1 is released.
I still don't know what will happen with my work, if it will be implemented into the core or not. Jinx has shon some interest, but a PM to masterchief has been unanswered. (I have to admit, I can't send PMs to masterchief, he seems to have blocked me. If he blocked all users or just me, I don't know, I certainly don't know why he should have blocked me exclusively. Jinx was so kind to forward a message from me to him.) Jinx stated that my work at the moment has the status of a proof of concept. If that means "It looks good, but screw you, we are going to do it all over again, Leave the big boys alone." or "Looks good, we will implement it in the near future." I don't know. You will understand that I'm pretty pissed. I know they don't have time for everybody and can't devote that much time for a single project, but I think this one is crucial for the success of Joomla. Every week at least 5 threads are opened where some guy asks can I do this or that with Joomla or how can I set user-rights and create new user-groups and everytime I write to wait for ACL-support in the VERY NEAR future. Q1 2006 is not that near in my opinion. Thats half a year in worst case...

Okay, now I feel better. Lets see:

The ACL-feature adapted to Joomla by Hackwar will be available as a core hack in v0.1 as soon as Joomla 1.1 is released. You should look out for a project called ACL-enhancment.
A complete support with admin-interface and all will come as soon as I can code it.

Hackwar

[EDIT]http://developer.joomla.org/sf/sfmain/do/viewProject/projects.acl_enhancment <-- ACL-enhancment-project[EDIT]

I would just like to show my support, Hackwar. I do not think the dev team is as ignorant as in your example here, but rather they demand some proof before code being implemented in the core. I think we as users should all be grateful for this - as that form of quality-check is one of the things that has made this cms what it is today.

I think your commitment and work is admirable, and in this way it reminds me of the dev team themselves. I would not be surprised if you were included in the dev team in the end if you keep up this pace - but that's only my impression of how it works, I'm not sure. The more work put into this, the better the end product - so if your work is used in the end, all good - but if not, it will give inspiration and ideas. So, keep up the good work!


BTW: I'm not sure whether there are length restrictions on project names, but I believe the correct spelling is enhancement.

its just frustrating. The API works (its not tested properly at the moment, because I thought masterchief had the admin-interface allready ported to Joomla/Mambo, which I would need to test it. As I said, he does not seem to respond.), the implementation in the core-components and the core itself work, documentation and How-To are present. And now this delay. Means, I will have to take matters into my own hands and do this on my own. As you can see above, the project is created, code and first releases will follow.


I don't want to be part of the dev-team. then I would have to deal with annoying guys who keep bugging me for including their GREAT hack into the core.
I don't think that I suit into the core team, I would just mess everything up. A few single additions to the core, send to the devs in hope of finding its way into the svn, that will have to be enough.


ARGL!! Mistyped... Can I change that now somehow??? A bit embarrassing.

Hi Hackwar,

I know the feeling you may have. I had a similar surprise reading the new roadmap, although ACL moved forward as Andrew said earlier. Six months is long, and not that long, keeping in mind it's 3-6 months and that includes tests and corrections and tests. I believe that pruning 1.1 of the not-completely finished/untested elements is a sound decision.

Andrew (masterchief) is indeed not easily reachable these months...We all have a lot of J! tasks and a life...

Maybe a better guess is to clearly analyze what's really needed to think of a good ACL component and define precisely the hooks needed in the core to make it work great. Even multilingual support is a component. Not all organizations are in need of extended ACLs... And a clean component is sometimes a better approach to modularity then "core" functions spread all around .

With that in mind, you may propose these minimal hooks for Joomla! 1.1 to Rey (stingrey) via the tracker and/or PM. Rey is very responsive, but also on a lot of fronts.

This could allow you to release a clean ACL component without hacks/edits/replacements to core files.

Later on, core team can decide to incorporate all or part your work as code, component or ideas into the core.

My feeling is that the core ACL functions have to go into the core, as core component and library to be usable by all components, and they will go there per the roadmap.

Keep the good work and the heads up.

Integrating the PHPgACL ACL admin backend shouldn't be that hard.

To include the ACL-support, you only have to replace the files gacl.class.php and gacl_api.class.php. Then you will have to create the corresponding tables and at last you have to change all acl_check that are called in Joomla, because they hand over the $my->usertype instead of $my->id. Its just that single parameter that is wrong, everything else can be left as it is. That would use the ACLs as they are supposed to be. The changing of rights would either be possible by experienced users by hacking in the db or using the phpGACL-admin-interface. The interface for Joomla is a simple component like everything else. In my eyes these changes ARE minimal.


the core acl-functions are in these two files, and those only. The rest is just visual presentation.



My next step...

$acl->acl_check() is also already used by 3pd components...  changing its parameters may break interoperability.

It's probably better to keep old function working and define a new (correct) function name or, better, a new type e.g. "userid" in addition of "users" for acl_check().

This is not possible. Old acl_check check for user being part of a certain group. Correct acl_check checks for user-ID. You will have to replace usertype by ID. The complete SQL-query is based on this. Either you don't use ACL or you change the last parameter to $my->id instead of $my->usertype. Creating a new variable would mean to put the ID into another variable. The old acl_check wont work either way. Its a difference if you check for the user-ID or the type of user.

Would it be possible to bury the incompatiblity through a lower-level redirection? For example could the new implementation have a shim that looks forwhen people ask for my->usertype and send my->id instead? Or, in the process of installation, to move the values of usertype to a new record, and put the user->id in the usertype field?

But I'm only just aerning how all these fields get used, but I can already see there's different ways that different programs are trying to use the db metaschema in different ways that are not compatible with each other, and there could always be unknown consequencies of redefining fields. The item and menu hierarchies in particular have lots of different facets, really one wants a field in each of them for acls, so it may be better if there was a new field entirely that new programs could use, which if unpopulated with non-default or null values is ignored. IN fact I think the values could be stuck in params fields, which appear to be catchalls, although that would require additional string processing.

And perhaps it would be nice if there could be a way to introduce a level of actraction into the database interface, so for example when executing a query on a field there could be a set of constants for the field names. Then if there's a need to move things around in the database the constants can make to different fields, or in the case of more advanced databases, invoke a procedure within the database itself. But that would be a new layer of redirection which would slow down performance in a much more global way than adding some new fields to existing records. and it would be a total rewrite. So maybe adding some new field defs is the best way to maintain backwards compatibility?

Hi guys,

First of all I want to say we really appreciate what Hackware is doing. He is creating the possibility to have an advanced ACL in Joomla 1.1 by doing it as an external component. That's actually what opensource is all about. Having the ability to take matters in your own hands and make changes. If custom work is integrated in the core is something that depends on alot of factors. To name afew :

• the qualtiy of the code, and how it integrates with the core
• the necessity of the feature(s)
• copyright issues
• ...

Then there is also the fact that we are bounded to a roadmap and a development cycle. Adding to much features into one release would push it back vastly as we experienced with Mambo 4.5.3. We are choosing for a clear roadmap, clearly defined features and release goals. We believe this is in the interest of the whole community. Our first priority is languages and the second one will be ACL as outlined in the new roadmap. This roadmap was created after carefully listing to user comments on the forums and we believe it clearly reflects the communties needs.

Hackwar,

Thank you for your work on ACLs.  I have been following this thread and am trying to test the code you posted above in acl_recode.zip so I can help you in any way I can.  Maybe it's a bit premature, but I can't figure out how to make acl_recode.zip work with my joomla installation.  I tried unzipping acl_recode and uploaded the files inside of the Joomla_files subdirectory to my server, but it broke my administrator backend interface.  When I try to go to mysite.com/administrator/index2.php, it complains:


Line 78 and 78 are as follows:


The file, joomla.factory.php does not exist in the default joomla install, and acl_recode.zip doesn't seem to include it.  Should that file be in your zip file? If I comment them out, the interface comes up doesn't work correctly.

Thanks
Mark

did you use a svn-copy or the 1.0.3? The patch I made works only for a recent copy of the svn. I'm in the process of creating a package for 1.0.3. Stay tunde, I expect it in the next two weeks.

Thanks, I just installed it on my SVN copy and it works now.  So if I use the regular phpgacl admin interface outside of joomla, can I use the ACL functions now?

essentially yes, but at the moment the API is not tested and could well be totally wrong. I had to rewrite all database-calls and don't know if I allways took the correct return-function. As I said, I'm working on a module that does 90% of the work of setting things up for you and will bring a Joomla-ACL-admin-interface with it. I'm glad some people try to use this stuff, but what I uploaded in acl_recode.zip could be seen as a proof of concept. You should wait till I release the ACL-component.

Please let me tell you a small and true story:

The last time one of the engineers in my company told me that something a large customer requested was impossible with a sound demonstration about all the problems, he convinced me and I believed him... We even convinced the customer !

Another small competitor just did it, and got not only a huge market from that customer, but also from a lot of other large customers. He became market leader.

That was 10 years ago. Since then, if an engineer tells me that something is impossible, he knows that he may well be fired on the spot for cause...

I hope now that you understand why I changed your impossibility statement in bold red font.


So *please* rethink about your statement... There is always a solution to "impossible".

It *is* perfectly possible to have old-way, "incorrect but working" group-wise ACL checks cohabit in compatibility with the new, correct, user-wise ACL check.

Either implement the new way into a separate function, or use "userid" for instance instead of "users" to distinguish the parameter after it (and new/old way). But IMHO backwards compatibility is key.

This will allow for a smooth transition, the removal of the old way can be planed in two stages: first issue warning messages in Joomla! 1.5 then remove function in 1.7 (just an example timeframe)

Continue your good work, and think well about this story.

Beat, you could be right....
I was about to write a comment against all your opinions, but I think I have a somewhat ellegant solution for this. Would be nice to have some feedback if it will work that way:
Now a acl_check is handled like this:

I would have forced the people to change it to this:

But we want it compatible to all components, etc. out there and I want it to be able to check for rights other than those of users. To achieve that, I change the acl_Check from

to


Is there a possibility, that the acl_check could not be called to check for the rights of the logged-in user?

I think that's the way to go. It will be easy to modify this acl_check function in 1.4 (post 1.3 example) when components will be required to use the proper syntax.

I got it done so far.
The acl_check works correctly even with the old syntax and the till now hardcoded rules are translated completely into mySQL. I got an install-script that does the whole thing and even can install this feature in running Joomlas and most probably in a Mambo starting from 4.5.2. I'm still churning on the admin-interface, but that should be a matter of days or hours, I don't know. I will write when its done.

Hi Hackwar,

Thanks for your insight. :)

The API is correct, meaning that "users" should remain compatible and mean that the following parameter is ARO Group. That was the best solution.

The "if" statement of the implementation is correct also.

The implementation of the case "users" needs to be a little more elaborate (backwards compatible) ;) :

indeed, it's not always "$my->usertype" which is passed to the acl_check, but sometimes "$anotheruser->usertype".

This could be a little better:



As 99% of the time, it's $my->usertype which gets checked, this is better than old way I think.
I don't have time now to see what to insert where the comment is, but I'm sure something can be found. Very worst case, you can find a user which has same usertype... 

Looking forward to your component

Hi folks,
one week after my last post in this thread, I've got a bit done and I need a bit help from someone.
Working:
- API works most of the time
- Tables get set automatically, updates existing sites, too
- easy installation: installing component and then copying the two API-files into the includes-folder - done
- Add/Edit/Delete Groups

Not working:
- Assigning objects to groups
- Administrating ACLs (there I need some help)
- ACL List (haven't made it to this yet)
- user manager (this neither)
(- content manager) (and this to will need some more time)

To get my latest work, download these two files:
ACL Component - You have to install this BEFORE copying the //EDIT: Took out the url/file cause its outdated
ACL API-files into the Joomla-Includes folder. //EDIT: Took out the url/file cause its outdated

Now to my problem: In the generic interface the author uses javascript that is called in with a onLoad=, but I don't know how to put this into the body in Joomla, so I made a link with a onClick-event and thought this would work. Long story short: It does not work. As I see it, the javascript is supposed to initialise severall arrays with the data of the different ACL-objects. When you click on the entrys in the section-areas the object-areas should get populated with data. This is all in the file admin.acl.html.php in the function acl_show_html.
If anybody got a clue???
At the moment I'm tired and don't know any way to solve this.
As allways I would be glad for some feedback.

Hackwar

P.S.: I know it looks ugly, but I just wanted it to work for now...

Link from ACL-API doesn't work.

little typo, is fixed now.

Ok works now something more to play

Maybe this will help you with the unload problem: Generic onload --> http://www.brothercake.com/site/resourc ... ts/onload/

Hackwar, I think there may be an error in the acl_show_html function.
Line 140, you have the opening tag of a form


Then on line 150 you have another form


The first form is not closed before the 2nd one starts, which is causing document.acl_admin to be undefined.  You can't have nested forms.  I removed the 1st form tag and now it works correctly.  Hope this helps

Mark

Here are some other fixes I made to admin.acl.html.php that seem to make the pick-boxes work correctly:
File: admin.acl.html.php
line 140, Remove:


line 206, Change:

to


line 263, Change:

to

Thank you mstralka for your help. I found these errors this afternoon and now adding ACL-rules works fine. Just have to make objects and sections editable and then just listing the rules and I would be done with the admin interface. Just where is all that time I would need??? lets see if I get anything done this evening. I hope to have my first official release in the next 48 hours.

Good to hear.. 

ACL done. patTemplate and WCAG compliance being rolled out. Caching somewhat retuned. Joomfish being integrated. Extended SEF functionality.. This community rocks!!