Permission and usergroup changes failing silently

[DavidJCobb]

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.

[DavidJCobb]

I did more tweaking and narrowed down the problem. I rename the node and modify the user's groups in "update_portfolio_name", which works properly... However, when "update_portfolio_perms" is called immediately afterward, it doesn't seem to notice the node's new name, and so it re-adds the old usergroup.

Okay, so "update_portfolio" requires a node, and calls "update_portfolio_name" and then "update_portfolio_perms". I think that when "update_portfolio_name" runs, it modifies that node, but the macros' reference to the node remains unchanged and does not update. So when "update_portfolio_perms" runs, it still sees all of the old values. For the permission edit, I was able to force one line of code to use an updated reference, by getting a "node_editor" and referring to "edited_node"; however, I can't get that to work in the specific way I need it to.

Somehow, I need to get "update_portfolio_perms" to see the changes to the node that were made by "update_portfolio_name"... I'll keep looking for something.

EDIT: Found a solution, and figured out the nature of the problem.

Basically, if: we have three macros A, B, and C, which all require "node"; and A calls B, and then C; and B makes changes to the node... Then C won't see the changes at all unless it grabs a new reference to the node, because the node reference C receives from A isn't updated. For example, <n.subject/> inside of C would yield the old value, but <n.get_node_from_id node_id="[n.id/]" do="[n.subject/]"> should yield the new value.

So basically, to avoid this problem, one can create a macro like:

<macro name="ensure_updated_reference" requires="node" dot_parameter="do" unindent="true">
  <n.get_node_from_id node_id="[n.id/]" do="[n.do/]"/>
</macro>

And then when you need to ensure that a reference is up-to-date for a macro, you can just wrap that macro's contents in

<n.ensure_updated_reference.> ... </n.ensure_updated_reference.>

[Hugo <Nabble>]

Thanks for the detailed explanation, David. This indeed seems to be a bug and I will have to take a closer look. I will get back to you soon about this.

About your portfolio feature, it is amazing. One possible simplification is to use the ID of the user in the name of the permission (e.g., portfolio42356). Since users cannot change that ID, you wouldn't have to worry about changes to the user name. The name of the permission would be safe. The drawback is that you would have to find the ID of a given user before manually changing his/her permission for some reason (e.g., not an active user anymore, etc.).

So soon we will get back to you with an explanation for the problem you described. If you have new questions, comments or concerns, please let us know. We want as much feedback as you can provide.

[DavidJCobb]

Hugo <Nabble> wrote

About your portfolio feature, it is amazing. One possible simplification is to use the ID of the user in the name of the permission (e.g., portfolio42356). Since users cannot change that ID, you wouldn't have to worry about changes to the user name. The name of the permission would be safe. The drawback is that you would have to find the ID of a given user before manually changing his/her permission for some reason (e.g., not an active user anymore, etc.).

Glad you like it! :)

I did consider naming the groups based on IDs like you've suggested. I'm not sure if my "boss" GodlyPerfection would prefer that over human-readable group names -- he managed portfolios manually prior to all my NAML stuff, so I don't know if he'd prefer to be able to easily change settings by hand -- but seeing as I only propagate changes to the public site on his approval, I should be able to change the system easily if he gives the okay, without having to worry about backward-compatibility or anything.

Hugo <Nabble> wrote

So soon we will get back to you with an explanation for the problem you described. If you have new questions, comments or concerns, please let us know. We want as much feedback as you can provide.

Thanks for looking into it. :) Once I get the portfolio system to a stable state, I'll try to remember to post a thread for some things I've noticed and thought of during development.

[Hugo <Nabble>]

We just released a code change that should fix the problem you described. Please test your NAML without the "ensure_updated_reference" macro and let us know if the problem is solved. Thanks!

[DavidJCobb]

Sorry for the delay in my reply. Just checked; the bug appears to have been completely fixed. Thanks for the fix. :)

[GregChapman]

Hi David,

I was interested to see your original post in this topic and hope to be able to implement "portfolios" on one of my sub-forums:
http://seahawk-forum.968426.n3.nabble.com/My-Boat-f3415231.html

Is mine the kind of application you had in mind?

My programming knowledge is a little sketchy (Never got beyond Z80 assembler or batch files once I moved to a PC - but was pretty good at both those!) and as your first post said some of the documentation is out-of-date I didn't bother to take a look at it at that point. Should I be brave and have a go, or am I likely to run into problems trying it out on my forum?

[DavidJCobb]

Yeah, the RP Portfolio system is very similar to that. The biggest difference is simply that only the admins create/manage portfolio structures; the owners just get the topic-creation permission exclusive to their own folios.

When I finish the portfolio system, I'll try to remember to fully document the finalized macros that it uses, so that others can port the functionality with relative ease. As a word of warning, it does require a particular permission setup for the portfolio containers, and it will also bloat the list of usergroups when you go to manage users and groups (one usergroup per portfolio owner). Small problems, but best to be aware of them in advance.

[GregChapman]

DavidJCobb wrote

Yeah, the RP Portfolio system is very similar to that. The biggest difference is simply that only the admins create/manage portfolio structures; the owners just get the topic-creation permission exclusive to their own folios.

Having Admin set up the area would be very helpful. Many of my users are not familiar with forums and permissions and find it confusing to be allowed to create their area but then not be allowed to post in it (until I grant them that permission).

As a word of warning, it does require a particular permission setup for the portfolio containers, and it will also bloat the list of usergroups when you go to manage users and groups (one usergroup per portfolio owner).

That's a disappointment! Currently, I have a single "MyBoat" user group, simply to avoid that bloat. Of course, it does mean that those in that group could post in any of the personal "My Boat" areas. Currently, I am relying on them not trying it!. If the number of the areas grew I might have to reconsider.