How to assign pages to specific users ?

[kradzcalypse]

I would like create a small b2b like website which have 2 pages (about user's company & products) for each users.

Can somebody show me how to do this ?

Edited August 17, 2015 by LostKobrakai
Moved Topic

[Webrocker]

Hi,

do you want to give those users the right to edit those pages, or are they only visible to logged-in users on the web page?

Each can be controlled with the access-roles and permissions for users and the settings on the page's templates. If you sketch what you want to achieve, I'm sure the answer can be found here

cheers
Tom

[kradzcalypse]

Yes, I want each user to be able to edit their personal pages.

I can see the access-roles and permissions only provide option for assigning pages by user category, can I assign pages by user id ?

for example :

Username : Alex

Pages belongs to Alex : 

- About my company

- My products

Username : Bob

Pages belongs to Bob : 

- About my company

- My products

Thanks

[LostKobrakai]

The ProcessWire core doesn't provide that detail of access management, but there are various modules out there to enhance the access management. You should take a look at the Dynamic Roles module. Keep in mind, that if you don't offer access to the backend to those users you could also manage access on your own for the frontend.

[kradzcalypse]

Thank you. 

[kixe]

Processwire does provide to add 'page-edit-created' permission. See instructions below (PagePermissions.module is a core module Installed by default)

/* Optional special permissions that are optional (by default, not installed):
 *
 * 1. page-publish: when installed, editable() returns false, when it would otherwise return true,
 *    on published pages, if user doesn't have page-publish permission in their roles.
 *
 * 2. page-edit-created: when installed, editable() returns false, when it would otherwise
 *    return true, if user's role has this permission and they are not the $page->createdUser.
 *    This is a permission that reduces access rather than increasing it. Note that
 *    page-edit-created does nothing if the user doesn't have page-edit permission.
 *
 * 3. page-rename: when installed, user must have this permission in their role before they
 *    can change the name of a published page. They can still change the name of an unpublished
 *    page. When not installed, this permission falls back to page-edit.
 *
 * 4. page-edit-lang-default: when installed on a multi-language site, user must have this
 *    permission in order edit multi-language fields in "default" language. This permission
 *    is also required to create or delete pages (if user already has other permissions that enable
 *    them to create or delete pages).
 *
 * 5. page-edit-lang-[language_name]: when installed on a multi-language site, user must have
 *    this permission to edit multi-language fields in the [language_name] language.
 *
 * 6. page-edit-lang-none: when installed on a multi-language site, user must have this
 *    permission to edit non-multi-language fields. They must also have it to create or delete
 *    pages (if user already has other permissions that enable that).
 *
 * 7. user-admin-all: when installed, a user must have this permission in order to edit other
 *    users of all roles (except superuser of course). When installed, the regular user-admin
 *    permission only acts as a pre-requisite for editing users, and enables only listing users,
 *    and editing users that have only the 'guest' role. The user-admin-all essentially grants
 *    the same thing as user-admin permission does on a system that has no user-admin-all
 *    permission installed. That's what it does, but why is it here? The entire purpose is to
 *    support user-admin-[role] permissions, as described in the next item below:
 *
 * 8. user-admin-[role_name]: when installed on a site that also has user-admin-all permission
 *    installed, a user must have this permission (along with user-admin permission) in order
 *    to edit users in role [role_name], or to grant that role to other guest users, or to
 *    revoke it from them. Think of this permission as granting a user administrative privileges
 *    to just a specific group of users. Note that there would be no reason to combine this
 *    permission with the user-admin-all permission, as user-admin-all permission grants admin
 *    privileges to all roles.
 *
 */