Turning off Profile Edit and Password Change on accounts

[Doki]

All,

Got a question for the community which I haven't been able to answer by going over the forums and related online materials. We're attempting to make an account type that will be used by several individuals at once (essentially an institutional account for an instituition with a dispersed client base, hence not being able to use IP address for access). For this account type, because of this multi-user access, we want the account credentials and profile to only be changed by the site administers.
So, is there a way to easily turn off these functions on an individual account type? Our backup solution is to shut these down for every individual account type using CSS and redirect tricks, but then true individual accounts can no longer edit their profile info and passwords, which is an issue. Further, if we need to close off access by all accounts, I'd prefer a more direct way since CSS and redirect could leave security holes which I'd prefer not to deal with. This is a small audience journal so security risk is minimal but I still would like launch to go with a minimum of issues.

Doki

[asmecher]

Hi Doki,

Is there anything that sets these accounts apart from the rest? Are there a limited, fixed set of these or do you expect to be creating and maintaining more as time goes on?

Regards,
Alec Smecher
Public Knowledge Project Team

[Doki]

Hi Doki,

Is there anything that sets these accounts apart from the rest? Are there a limited, fixed set of these or do you expect to be creating and maintaining more as time goes on?

Regards,
Alec Smecher
Public Knowledge Project Team

We have a fixed list currently but the hope is to add more in over time. Additions will be done via administrator rather than have people sign up by form (since access to the journal is granted as a perk for a society membership, we, the admins, get the list of members sent to us periodically and update the subscription list as needed).

Because all info is added by administrator, we can add any mark necessary to the account distinguish these accounts in the profile. Our original plan was to add specific text in "Affiliation" to note these accounts, but we can do whatever is easiest.

Doki

[asmecher]

Doki, you might consider adding a new field to the users table and allowing the Site Admin and/or Journal Manager to flag these accounts in their Edit forms. Then you could disable the built-in Edit and Password Change forms based on the value of that flag. This will require a little PHP dev skill but will be the cleanest approach. I can direct you to the appropriate classes, if you've got the PHP skills on hand.

Regards,
Alec Smecher
Public Knowledge Project Team

[Doki]

As a matter of fact, one of my many, many tasks around here (amongst journal management and calendar modeling) included PHP coding

If you have a list onhand, I can crack into it tonight.

[asmecher]

Hi Doki,

Here's a quick list:

• Back up your installation's files and database
• Add the new field to the database descriptor for the "users" table (lib/pkp/xml/schema/common.xml)
• Run to sync:

  Code: Select all

  php tools/dbXMLtoSQL.php -schema execute lib/pkp/xml/schema/common.xml

• Add getter/setters to lib/pkp/classes/user/PKPUser.inc.php
• Add fetch/update code to lib/pkp/classes/user/PKPUserDAO.inc.php (insertObject, updateObject, _returnUserFromRow methods)

That will get the additional field implemented in the data model PHP classes. Then you'll have to add the field to the form the Journal Manager uses to create/edit users and its associated template -- classes/manager/form/UserManagementForm.inc.php and templates/manager/people/userProfileForm.tpl.

Then you can make the presence of the "Edit Profile" and "Change Password" forms dependent on the results of the new User get... function you created. These are implemented in pages/user/ProfileHandler.inc.php and linked from various parts of the system (e.g. lib/pkp/templates/common/header.tpl).

Regards,
Alec Smecher
Public Knowledge Project Team

[Doki]

Thanks! I got the change in on our test server as we speak, and it seems to be working smoothly. Will probably press it live this weekend. Thanks for your help on this!

(Side note: think this may be a good candidate to add to the core?)

[asmecher]

Hi Doki,

Glad to hear it's working. I suspect this is a little too specific to add to the core, but if others find it useful, hopefully they'll post here (possibly even asking for your code). Keep in mind that you'll have to maintain this over OJS upgrades, but using the patch-based upgrade process you should be fine.

Regards,
Alec Smecher
Public Knowledge Project Team