is it possible to not show page submission in page tree ?

[adrianmak]

I'm building a front-end simple enquiry form with only name, email, subject and message fields

The submitted form data will be stored as page (or something else).

To make use of the pw's core page api, i have to create a page template with mentioned fields. But any pw's page(s) should show on page tree.

In instead I don't want the submission data shown on page tree, and write a admin module to retrieve submission page data.

[tpr]

If you save your pages under the Admin section in the Page list, isn't that OK to you?

[adrianmak]

If you save your pages under the Admin section in the Page list, isn't that OK to you?

it could be an option is there is not any other available options.

[LostKobrakai]

Make the pages not viewable for anyone (except superuser) and use the module permission system to limit view access of your dashboard module separately. 

[cstevensjr]

Make the pages not viewable for anyone (except superuser) and use the module permission system to limit view access of your dashboard module separately. 

I strongly agree.  This is a process that I use frequently and it works well.

[adrianmak]

Make the pages not viewable for anyone (except superuser) and use the module permission system to limit view access of your dashboard module separately. 

I knew what is template permission. But what is module permission ? where to config a module permission ?

[adrianmak]

I strongly agree.  This is a process that I use frequently and it works well.

could u mind share more implementation details about this technique from you real project ?

[cstevensjr]

could u mind share more implementation details about this technique from you real project ?

No problem, 

Give me a little while and I will write something up.

[LostKobrakai]

(Process-)Module access is obviously not determined by template access settings, but real permissions, like 'comments-admin' or 'page-edit'. Without such a permission set in the modules config only superusers can see the process module. With it all users having that set permission can see it. If you need more dedicated permissions than "can access" or "cannot access" you can always check for further permissions on the current user in your code manually.

[cstevensjr]

Real-Life Example

Website:  crms.sdtool.info

Purpose:  Collaborative Resource Management System (CRMS)

Ok, this website uses Adrian's Protected Mode module to control access to the website.  ProcessWire (PW) Roles are then used throughout to control access to selected pages.  Fields within templates are also controlled via this method.  

These PW Roles are added at each PW template using the Access Tab.  I use a concept I call a "Security Container" that sits at the top of the PW Page Tree (backend) on the website.  This is how the "Security Container"is explained on the website:

Security Container

Once you log in, you will immediately see your name or the name of your company under the Security Container banner. This is your primary area and the top-level structure of the CRMS. There may also be other names or company names that you manage on a day-to-day basis. These are your secondary Security Containers.

The SDTool is a multi-company multi-purpose system. All data is structured around this top level Security Container hierarchy for each name or company. Data is then implicitly siloed by strict access control permissions and role-based security parameters. Access permissions are manually assigned and tested by trusted System Administrators, to ensure that access to your data only goes to individuals you have authorized.

Each "Security Container" has a PW template that controls who has access to that particular page.   Once again, access is gained via one or more PW Roles.  You have to have access to the gateway "Security Container" page to get to any pages under it.

My Client: (I will be using the name Axxxx, as I still need to respect confidentiality and privacy) is an Internet Marketing and Investment Company in the Washington DC Metropolitan Area.  They provide selected SEO services to their clients.

My role with this client is to provide back-end Internet-based infrastructure support for Axxxx and their clients.  This comprises of:

• Manage/maintain existing web hosting user accounts (SSH/SFTP) and creating new ones (when required)
• Database creation and upkeep
• Domain and SSL/TLS registrations
• Wordpress website installations, day-to-day back-end management and upkeep
• Email domain/account creation, back-end management and upkeep (website, plug-ins and themes)
• Centralized database backups and restorals
• Analytics management using Google Tag Manager/Analytics, Piwik and Woopra
• Work with Wordpress developers, on behalf of the client, to integrate third-party plug-ins or capabilities

Accessing Axxxx Client Data or Resources

The Axxxx Client has three possible PW Roles that can be assigned:

axxxx-client-access (Contractors or any outside Axxxx related entity)

axxxx-manager-access (Axxxx Business Owner or Manager)

axxxx-staff-access (Axxxx Staff who aren't at the manager level)

The top-level Axxxx "Security Container" Page ensures that only the above three PW Roles have access to Axxxx data or resources.  Whenever an Axxxx employee logs into the website, they only see Axxxx related information.

Form-Based Page Submissions

All newly created pages (by clients) make extensive use of Ryan's Form Builder module. Support request pages and emails are created using this handy tool.   Each client has dedicated Form Builder forms that are applicable to their particular mission.

Email-Based Page Submissions

All my clients have the capability to submit updates or new submissions to me through email.  I use the fantastic Email To Page module by Pete and Adrian to achieve this feat.  I now make extensive use of Twilio based communications capabilities due this module being installed on this website.  

Axxxx Company Clients

The Axxxx Client company has clients of their own and their data is stored within the website's "Client Portal" Security Container.  They can all see the "Client Portal" page (but not any CStevensJr or Axxxx data) and each has an individual named page (which is a "Security Container" for their permissions) under it.  PW Roles are used here also to segregate access to each client's own data.

Whenever a Axxxx client logs into the CRMS, they only see the "Client Portal" PW Page and beneath that their own data/resources. 

Final Thoughts

PW has an extensive Roles and Permissions system which has significantly improved over the last year.  I previously made use of Ryan's 

Page Edit Field Permission module but now use the greatly expanded native permissions instead.

My SDTool Project has progressed very nicely and is being expanded to make use of all the great new capabilities that PW provides.

I hope this rather long explanation is helpful.   This is just one way I work with PW.  I will, in the next few months, provide some more promised updates on the SDTool Project (in the linked post) .