Game, user and devteam need links to +edit if authorized

[Matt Giuca]

If a user is authorized to edit an object, there should be a link to the edit page from that object's main page.

[Matt Giuca (mgiuca)]

Does anyone have any ideas on how the client can figure out whether the user is authorized to edit or not? I don't think the client has access to any authz information like that at all, which makes it pretty hard.

(After all, that's the whole problem why we are letting people into the +edit pages even if they don't have permission -- we can't detect whether or not they have permission until they try to edit something.)

I'm wondering if we should / can add a field to the User, DevTeam and Game objects (just the client objects, not the *Data versions) called userCanEdit : Boolean, which indicates whether the user has edit permissions. Then we can use that to determine whether to display the "edit" links, as well as whether to show an error if the user visits the +edit page. Does that sound feasible?

[Matt Giuca (mgiuca)]

Setting this to high priority, as it's the last truly broken thing about the UI (with this, it will be possible for a user to get everywhere they need to go).

[Scott Ritchie (sritchie)]

That could be feasible, you'd just need to make sure the field can't be
edited client side.

On Wed, May 25, 2011 at 11:25 PM, Matt Giuca <email address hidden>wrote:

> Setting this to high priority, as it's the last truly broken thing about
> the UI (with this, it will be possible for a user to get everywhere they
> need to go).
>
> ** Changed in: mugle
> Importance: Medium => High
>
> --
> You received this bug notification because you are subscribed to MUGLE.
> https://bugs.launchpad.net/bugs/786835
>
> Title:
> Game, user and devteam need links to +edit if authorized
>
> Status in Melbourne University Game-based Learning Environment:
> Triaged
>
> Bug description:
> If a user is authorized to edit an object, there should be a link to
> the edit page from that object's main page.
>

[Matt Giuca (mgiuca)]

I don't see why that's a problem; it doesn't matter what the client does with it, as long as it can't be written back to the server. There's no way it could be written back to the server if the server doesn't have a field for it.

[Matt Giuca (mgiuca)]

Fixed in trunk r438.