Permission and usergroup changes failing silently
Posted by DavidJCobb on Jan 06, 2012; 5:33am
URL: https://support.nabble.com/Permission-and-usergroup-changes-failing-silently-tp7157335.html
EDIT: Problem identified, workaround created, see next post. Most of the stuff in this post has turned out to be irrelevant.
I'm trying to rig up a NAML-based system for "portfolios" -- little storage areas for active members, that each have special permission setups so that only they (and admins) can create threads in them. Basically, each portfolio is a sub-app, and each user that has one is put in a usergroup named after them, which gets unique permissions to the sub-app. I've been trying to automate the process of setting up these groups and permissions by creating forms with NAML; currently, I'm in the process of replacing one set of (badly-implemented poorly-thought-out) portfolio forms with a single new form, but I've encountered a peculiar little problem.
Let's say that we have a user, "Registere". I give him a portfolio. All is fine and good.
Now, he changes his name to "Registere really now?".
I go to my new portfolio form and trigger an update, which should: rename the sub-app that serves as the portfolio; modify the user's usergroups, removing him from the "Registere" usergroup and adding him to the "Registere really now?" usergroup; and modify the portfolio permissions, resetting them to normal and adding the create_topic permission for admins and for the "Registere really now?" usergroup.
In tests, I'm finding that removing -- and occasionally even adding! -- usergroups and permissions fails silently. No syntax errors, no 500s, no evidence of any kind of actual problem, and I've double-checked everything that I'm feeding into the system (and triple-checked the bits that I designed to fail silently, i.e. "local_portfolio") and I can't find anything wrong... Yet the renamed user never leaves the old usergroup, and in my most recent test, absolutely no permission changes whatsoever were ever actually made to the node. A complete lack of changed permissions is new, but the failure to remove the old group has consistently occurred in about a dozen tests now, irrespective of the names that the user is changing to or from.
The form experiencing this problem is here, though you'll probably need admin privileges to use or access it. I can grant those if you need me to. The user I'm testing with was previously named "Registere", and is now named "Registere really now?". The portfolio node I'm using for that account is here. The (unrelated to this issue, but related to testing) other forms, including the one I used to actually turn a node into a portfolio, are all accessible from here (also access-limited). I haven't "cleaned up" the mess left by the silent failures; the groups and permissions are still mismatched in the manner I have described.
What I need to know is, is this some sort of bug, or am I doing something wrong but somehow not triggering an error message? I pretty much have no idea what's going on with this code.
The portfolio macros are sort of a jumbled mess right now, so here are links to the ones that are the most important, along with some other info that may be useful if you need to read the NAML code in-depth:
Documentation for portfolio system implementation. Some of it is out-of-date (mostly the ones listed in section 3 paragraph 3 of the post) -- I'm working to replace those bits with the new (currently-broken) code. Doesn't yet describe the new macros, which include:
update_portfolio_name renames the node and (fails to...) swap out usergroups and permissions, when using the form to update the node name and usergroups to match the user's new name. Checks are done to ensure that we don't end up manipulating a bad group (i.e. a user getting a portfolio, changing name to "Administrator" -- the check prevents them from getting admin privileges if someone were to trigger a portfolio update in such a scenario).
That's called by update_portfolio, which the new form calls when saving the changes.
NAML for the (new) form itself.
URL: https://support.nabble.com/Permission-and-usergroup-changes-failing-silently-tp7157335.html
EDIT: Problem identified, workaround created, see next post. Most of the stuff in this post has turned out to be irrelevant.
I'm trying to rig up a NAML-based system for "portfolios" -- little storage areas for active members, that each have special permission setups so that only they (and admins) can create threads in them. Basically, each portfolio is a sub-app, and each user that has one is put in a usergroup named after them, which gets unique permissions to the sub-app. I've been trying to automate the process of setting up these groups and permissions by creating forms with NAML; currently, I'm in the process of replacing one set of (badly-implemented poorly-thought-out) portfolio forms with a single new form, but I've encountered a peculiar little problem.
Let's say that we have a user, "Registere". I give him a portfolio. All is fine and good.
Now, he changes his name to "Registere really now?".
I go to my new portfolio form and trigger an update, which should: rename the sub-app that serves as the portfolio; modify the user's usergroups, removing him from the "Registere" usergroup and adding him to the "Registere really now?" usergroup; and modify the portfolio permissions, resetting them to normal and adding the create_topic permission for admins and for the "Registere really now?" usergroup.
In tests, I'm finding that removing -- and occasionally even adding! -- usergroups and permissions fails silently. No syntax errors, no 500s, no evidence of any kind of actual problem, and I've double-checked everything that I'm feeding into the system (and triple-checked the bits that I designed to fail silently, i.e. "local_portfolio") and I can't find anything wrong... Yet the renamed user never leaves the old usergroup, and in my most recent test, absolutely no permission changes whatsoever were ever actually made to the node. A complete lack of changed permissions is new, but the failure to remove the old group has consistently occurred in about a dozen tests now, irrespective of the names that the user is changing to or from.
The form experiencing this problem is here, though you'll probably need admin privileges to use or access it. I can grant those if you need me to. The user I'm testing with was previously named "Registere", and is now named "Registere really now?". The portfolio node I'm using for that account is here. The (unrelated to this issue, but related to testing) other forms, including the one I used to actually turn a node into a portfolio, are all accessible from here (also access-limited). I haven't "cleaned up" the mess left by the silent failures; the groups and permissions are still mismatched in the manner I have described.
What I need to know is, is this some sort of bug, or am I doing something wrong but somehow not triggering an error message? I pretty much have no idea what's going on with this code.
The portfolio macros are sort of a jumbled mess right now, so here are links to the ones that are the most important, along with some other info that may be useful if you need to read the NAML code in-depth:
Documentation for portfolio system implementation. Some of it is out-of-date (mostly the ones listed in section 3 paragraph 3 of the post) -- I'm working to replace those bits with the new (currently-broken) code. Doesn't yet describe the new macros, which include:
update_portfolio_name renames the node and (fails to...) swap out usergroups and permissions, when using the form to update the node name and usergroups to match the user's new name. Checks are done to ensure that we don't end up manipulating a bad group (i.e. a user getting a portfolio, changing name to "Administrator" -- the check prevents them from getting admin privileges if someone were to trigger a portfolio update in such a scenario).
That's called by update_portfolio, which the new form calls when saving the changes.
NAML for the (new) form itself.
| Free forum by Nabble | Edit this page |