On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • Hi all,

    I just ran into a problem where I applied two different FC profiles (which both target the same template) assigned to two different user groups (administrator & editor)
    When I have the same user in each group, for the sake of setting access permissions, the manager appears to ignore the access permissions for the user that is in both groups (users in only one of the groups work fine).

    If I have a user admin in the administration group with FC profile applied everything works fine and likewise if I have a user editor in the editor user group the FC rules work fine.
    However, as soon as I ADD the admin user to the editor group (in addition to the ’administrator’ group), which also has it’s own, slightly different FC profile, the manager ignores my access permissions for the admin user and, in this case, my template variables are not displaying.... just as if the permissions were ignored. As soon as I deactivate the FC profile that is applied to my administration user group the admin user’s permissions kick back in.


    I’ve tested this the other way around, with a user from the editor user group being added to the administrator group and then the editor user had their permissions ignored.

    I guess this is either a suggestion to give priority to a FC profile when a user is in multiple user groups with different FC profiles... or am I mis-using the access controls???
      Environment:
      modx: rev 2.0.8-pl
      localhost: Apache/2.0.63 (Unix) PHP/5.2.11 DAV/2, MySQL client version: 5.1.37
    • Quote from: drwagner13 at Feb 15, 2011, 10:23 AM

      It seems that there is no way to delete a tab once it is a created. Is that correct?

      This is correct for me, no right-click menu to remove tabs.
        Environment:
        modx: rev 2.0.8-pl
        localhost: Apache/2.0.63 (Unix) PHP/5.2.11 DAV/2, MySQL client version: 5.1.37
      • Quote from: Hlight at Mar 24, 2011, 12:50 PM

        This is correct for me, no right-click menu to remove tabs.

        This has been fixed for 2.1: https://github.com/modxcms/revolution/commit/a10dc1bc447434b989af450b09c1e1b2040922e0
          shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
        • Quote from: splittingred at Mar 24, 2011, 12:57 PM

          Quote from: Hlight at Mar 24, 2011, 12:50 PM

          This is correct for me, no right-click menu to remove tabs.

          This has been fixed for 2.1: https://github.com/modxcms/revolution/commit/a10dc1bc447434b989af450b09c1e1b2040922e0

          That was fast, thanks!
            Environment:
            modx: rev 2.0.8-pl
            localhost: Apache/2.0.63 (Unix) PHP/5.2.11 DAV/2, MySQL client version: 5.1.37
          • Couple of customisations that were possible in Evo but I’m not sure if they can be done in Revo (yet):


            • Moving standard (non-tv) resource fields to different tabs. Say I wanted to move pub_date to the modx-resource-settings tab. Is it currently possible to do this?
            • What about the Resource Content field, could that be moved into a tab? Or could other fields be moved out of a tab and into that ’general content’ area below the Resource Content field?

            • Quote from: timharris777 at Dec 28, 2010, 04:50 PM

              2.- When moving TVs from their current tab to the first tab that appears, the placement of the form fields look awful. Nothing is in line. The TV description will be on one line and the input field below it. The input fields are not nicely lined up. This also looks very sloppy to clients.

              I was annoyed with this too. Sure it’s a cosmetic thing but it does look sloppy! See image attached.

              Using firebug the element affected is:
              input#tv1.textfield.x-form-text.x-form-field


              The width of this field is set to 97% which is too wide to keep it on the same line as the label.
              Reducing to 95% was enough to keep it on the same line for me but it still stretched much wider than the other resource fields.

              I did notice that the resource fields are styled with pixel width values (that change when the window is resized). Would be nice to have the TVs aligned with those if this isn’t being addressed already. Bug filed smiley
              • So... after two years we don't have a comma seperated list for Constraint values...
                • Funny you should ask, I just needed that this afternoon. Requires editing a core file, though.

                  Revo 2.2.4, /core/model/modx/modmanagercontroller.class.php, Starting at line 778, I changed:
                  if ($obj->get($constraintField) != $constraint) {
                    continue;
                  }

                  to:

                  Edit: To something that apparently isn't working right after all. Um, I'll get back with you. [ed. note: ocdcoder last edited this post 7 years, 8 months ago.]
                    If there's a better way to do it, I'll find it.
                  • Ok. Trying this again.

                    Revo 2.2.4, /core/model/modx/modmanagercontroller.class.php, Starting at line 778, I changed:
                    if ($obj->get($constraintField) != $constraint) {
                      continue;
                    }

                    to:

                    // CB: Allow comma-separated lists of constraints
                    //if ($obj->get($constraintField) != $constraint) {
                    //    continue;
                    //}
                    $constraintList = explode(',', str_replace(' ', '', $constraint));
                    if (($obj->get($constraintField) != $constraint) && (!in_array($obj->get($constraintField), $constraintList))) {
                    	continue;
                    }

                    That seems to be working like expected. So far...

                    I did run into another issue. I have one set of rules for a specific template with no constraints, then another for that same template with constraints. It's applying the right rules, comma-separated or not, except that I'm setting a value for one of the TVs in the set with the constraints and it's still changing the value for resources that don't match the constraints. It doesn't matter what the constraints are, it's applying it to everything unless I change the template.

                    It's not outputting it as one of the rules, it's setting the TV directly. So now I just need to figure out where that little bit of fun is coming from.
                      If there's a better way to do it, I'll find it.
                    • Ok, /core/model/modx/modtemplatevar.class.php, line 589 has this:
                      $template = $rule->get('template');
                      if (!empty($template) && $template != $resource->get('template')) {
                        continue;
                      }

                      I added code after it. (Above code included for reference.)
                      $template = $rule->get('template');
                      if (!empty($template) && $template != $resource->get('template')) {
                          continue;
                      }
                      
                      // CB: Also check constraints (allows for multiple constraints)
                      $constraintClass = $rule->get('constraint_class');
                      if (!empty($constraintClass)) {
                          if (empty($resource) || !($resource instanceof $constraintClass)) continue;
                          $constraintField = $rule->get('constraint_field');
                          $constraint = $rule->get('constraint');
                          $constraintList = explode(',', str_replace(' ', '', $constraint));
                          if (($resource->get($constraintField) != $constraint) && (!in_array($resource->get($constraintField), $constraintList))) {
                            continue;
                          }
                      }


                      Like the above, probably needs more testing, but I think this is a good time to be done for the evening. smiley
                        If there's a better way to do it, I'll find it.