Is "Apply where beneath" relevant for J1.7 ?

[lcollong]

Hi,

I'm wondering how to use the Where option of the DB Join element together with the "Apply where beneath" option. Since with J1.7 the group levels are not necessary nested, what does "beneath" mean ?

Does the where clause apply only to that group of users ? Is it only a matter of changing the label or is this a conceptual consideration as we should be able to add as many "where clause" as there are groups level potentially affected ?

 

[rob]

I think the label and hover text are out of date. A brief look at the code suggests that the where statement would ONLY be applied to the selected group, does that tie in with what you are observing?
Let me know if it is and I will update the label and hover text

 

[lcollong]

As far as my tests were deep enough the "where" clause apply to "everybody" whatever you choose on the ACL dropdown.

 

[black.be3]

I'm also having the samething with Jerome..

 

[lcollong]

Friendly bump

 

[lcollong]

Friendly Bump as the where clause is applying to everybody instead of just the selected level which is becoming a serious brake on the project we are setting up.

 

[troester]

On my site the where clause is applying to the selected access level =>
is applying to all users belonging to a group which has viewing access to this level or which inherited viewing access to this level

So with the new J!1.7 ACL concept (if I got it right) it's the other way around: if you apply WHERE to "Registered" it's not "Registered and beneath = Registered+Public" (as in J!1.5), but "Registered" and all groups which have or inherited "Registered" access - which are ALL groups but Public (if you didn't change the default settings)

 

[lcollong]

Thanks for replying troester however I think that some situations can become more complicated.
In my project, several groups are not hierarchically organized. Except they all "belongs" to the register level, several are side by side (think about customers and suppliers : they have separate rights and views possibilities on my data but none depends hierarchically from the other).
So the ACL groups looks like that :
public
|-register
|--customers
|--suppliers

so if I set where clause to "register and beneath", it is applied to all users belonging to register, customers or suppliers but if I set the where clause to customers it should not apply to suppliers....

Ideally, the where clause dropdown should be multiselectable in order to apply the where clause to all the selected levels

 

[rob]

you should then create viewiing access levels for customers and suppliers I think

 

[lcollong]

Sorry, but I don't understand Rob. J1.7/2.5 ACL could be used in some very sophisticated ways. Not only as simply "mimicing" the J1.5 hierachical ACL basic levels.

I can agree that if where clause apply to "customers" in my previous example, it also applies to simple "registers" users as they are "beneath" the customers level. But "supplier" level is not "beneath" the customer one.

I currently use several group under register level with separate rights (different articles, different menus, etc...), if the DBJ element as access level set to register (view and edit), they all can manipulate it. If I add a where clause, it should apply only to the selected group(s ?). It works this way for the prefiltering list function.

 

[jfquestiaux]

The new ACL in Joomla! is really very powerful but, often with sophiticated feature, quite complex.

In a general way, it is advisable to organize new groups in a FLAT way, rather than a HIERARCHICAL way, because the inheritance factor can be rapidly confusing.
At least with a flat organization, you can really customize the rights/access for each group.

So in your case, I would have use this

public
|-register
|-customers
|-suppliers

So your 'customers' and 'suppliers' are childs of "Public" and inherit its rights, which are basically nothing!
You can then enable for each group the right to login in the front end.
Then create an acces level for each group, so they can have access to their specific content on your site.

If you need to pre-filter a list, so that only customers and suppliers can view the content but not the public or any other registered user that is neither a customer or a supplier, you have to set 2 prefilters :

If .... condition ... - apply to "customers"
OR (grouped) If ... condition .... - apply to "suppliers"

Don't forget to include yourself in those groups so, even as a Super Admin, you won't be able to see the records.

 

[troester]

Hmm, in my understanding you must add also a prefilter to prevent public/registered to see any record, so some "false" condition like
Where id Equals 0 apply to "public"
or
cond for customers
or
cond for suppliers
or
Where id > 0 apply to superadmin

 

[lcollong]

As a matter of fact I was not speaking about prefiltering. Prefiltering is working on my setup. I can prefilter a list in order to show the right data to the right user group. Fine.

I'm speaking about the "where clause" of the DBjoin element. This one should be applied only to the users belonging to the groups which belongs himself to the "Viewing Access Level" which is choosen in the dropdown. For all others users, as far as they can edit/view this element, the where clause should not apply. The access level are not nested. That's why "beneath" was not appropriate before Rob changed it.

I really think that the join feature is still not fully compliant with the new ACL. At least the "Where clause".

 

[rob]

i tested the apply where option - it was incorrectly labelled as 'apply where beneath' which i have fixed.
For me it works.
I set up a group view access level to a given group, if I am not signed in with this group then the where query is not applied, if I am signed in with a user whos group belongs to this view access level then the where is applied

 

[rob]

Im really not sure where we are with this thread now? are people happy its working? If not can you provide a test site with ftp access etc so I can confirm if there is something wrong in my code or if its an issue with the acl set up etc
thx

 

[cheesegrits]

My reading of the thread is that the issues are with the wording of the tooltip, rather than the functionality.

Jerome - can you give a specific example of a case where you think it isn't behaving as it should? If necessary, provide screenshots of your settings (including the J! access level set up).

One gotcha, btw ... when you change J!'s access levels and settings, the changes won't apply to logged in users, until they log out and back in again.

-- hugh