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

Discussion in 'Fabrik 3.x Testing' started by lcollong, Feb 4, 2012.

  1. lcollong FabriKant d'applications web

    Level: Professional

    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 ?
  2. rob Administrator

    Level: Community
    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
  3. lcollong FabriKant d'applications web

    Level: Professional
    As far as my tests were deep enough the "where" clause apply to "everybody" whatever you choose on the ACL dropdown.
  4. black.be3 Member

    Level: Standard
    I'm also having the samething with Jerome..
  5. lcollong FabriKant d'applications web

    Level: Professional
    Friendly bump
  6. lcollong FabriKant d'applications web

    Level: Professional
    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.
  7. troester Well-Known Member

    Level: Standard
    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)
  8. lcollong FabriKant d'applications web

    Level: Professional
    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 :

    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
  9. rob Administrator

    Level: Community
    you should then create viewiing access levels for customers and suppliers I think
  10. lcollong FabriKant d'applications web

    Level: Professional
    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.
  11. jfquestiaux Well-Known Member

    Level: Professional
    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


    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.
  12. troester Well-Known Member

    Level: Standard
    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"
    cond for customers
    cond for suppliers
    Where id > 0 apply to superadmin
  13. lcollong FabriKant d'applications web

    Level: Professional
    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".
  14. rob Administrator

    Level: Community
    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
  15. rob Administrator

    Level: Community
    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
  16. cheesegrits Support Gopher

    Level: Community
    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

Share This Page