Issue #221434: Users should always be able to access their own edit page introduces the fact that a user always can edit his own account page.
In my use case, this is not the case: some users are automatically logged in based on IP address (via IP login module), and they may not edit any of their settings.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hunmonk’s picture

i would consider a patch that adds a new 'access own edit page' permission to the module, if it was well implemented. i have no interest in writing this myself.

johnv’s picture

Wow, that's fast. ATM I'm writing that patch. :-)

johnv’s picture

Status: Active » Needs review
FileSize
3.66 KB

Attached patch adds 2 new permissions:
- Edit own user profile
- View own user profile - Overrides disabled View user profiles.

I think it will work nicely upon upgrade, since it will not throw a protection by default.

I have one thing remaining: the 'my account' menu item should disappear completely when user has none of the Edit/view user profile permissions. ATM the menu item still exists. Someone knows what's missing?

hunmonk’s picture

Status: Needs review » Needs work

i will not accept this patch as written. userprotect is focused on editing prevention, throwing in view protections feels more like it solves your issue, and not a module issue... ;)

if you re-roll with only the feature that was originally discussed, then i will reconsider.

johnv’s picture

I added 'view access' merely to complete the CRUD. Please find a reduced patch attached.

BTW. I've tested other modules (user_readonly, user_settings_access) and they were not able to hide 'my field'. I don't think restricting access to view or edit is that different? All three modules do 'account access'. You should join forces!
But, you're the master of your own scope creep :-)

johnv’s picture

Status: Needs work » Needs review
hunmonk’s picture

Status: Needs review » Needs work

getting closer. unfortunately, this needs an upgrade path. installing a new permission will make it such that all current roles on the site would not have it, which would create the opposite behavior of what we have now -- not acceptable.

so you'll need to include an update function that loops through all current roles on the site and enables that permission for them, and you'll need to adjust the installation code to enable it as well. the existing install code should give you some good hints on how to handle these.

johnv’s picture

hunmonk’s picture

not quite:

  • up_edit was only always FALSE for user's editing their own account. if you do that, you'll clobber the site's settings for user admins
  • i'd prefer if you explicitly enabled the permission for all roles. it's totally possible for a user to not have the authenticated role (a la logintoboggan's pre-auth feature), so this needs to be set for all roles to behave consistently
  • you should be using core's user_role_grant_permissions() or similar instead of querying the database directly.
johnv’s picture

I'm sorry, but I leave the patch in this state.
I'm not a full-time programmer, my demand is fulfilled and my time is running out. Perhaps the next person with this feture request can test and complete the patch.

hunmonk’s picture

well, good work thus far, hopefully somebody else will pick up the torch. now you can see why being a volunteer module maintainer can be so demanding!

johnv’s picture

Indeed. And it's good not doing it yourself - using 4-eyes gives better code.

jlholmes’s picture

Version: 7.x-1.x-dev » 7.x-1.0-alpha2

I believe that I also have the same use case as johnv. I would also like to use IP Login which maps IP numbers onto a user account and allows login to that account from a specified listing of IP numbers. The user account needs to be protected so that users from the IP numbers cannot edit (or even see may be ideal) the user account info. The use case here is giving an entire university community transparent access based upon the IP number, but only allow an administrator access to the account.

johnv, how are you accomplishing what you need? are you using the original patch you provided?

johnv’s picture

@jlholmes, I do not use this module anymore. Latest version of IP Login now has a dedicated/separate field and permission to edit the field. I also use ABT module, which has permissions tho show the field, too.

MorinLuc0’s picture

Here is an updated version on this patch to work on the latest version of user protect module.

progpapa’s picture

Status: Needs work » Needs review
FileSize
2.59 KB

Thanks for the patch, I needed this for a project I'm working on.

I have changed a few lines in the install file + added an extra user_access check to userprotect_user_edit_access.

Maybe it's getting even closer now. ;)

MegaChriz’s picture

Version: 7.x-1.0-alpha2 » 7.x-1.x-dev
Issue summary: View changes
FileSize
2.34 KB

A re-roll of the patch in #16. Also renamed the permission from "edit own user account" to "edit own account".

  • MegaChriz committed de59df8 on 7.x-1.x
    Issue #1172518 by MegaChriz: added "edit own account" permission.
    
MegaChriz’s picture

Status: Needs review » Fixed

Committed #17.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.