Jump to content

Search the Community

Showing results for tags 'Plugin'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Product Groups

  • Form Builder
  • ProFields
  • ProCache
  • ProMailer
  • Login Register Pro
  • ProDrafts
  • ListerPro
  • ProDevTools
  • Likes
  • Custom Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Is it possible to restrict the listing of pages/subpages based on the roles (user or role-access defined in a page?) FOR THE BACKEND? (The page has no frontend, only a complex json output of the different users' content.) i have multiple users which should not be able to VIEW or EDIT forign content. They all (should) have their own "parent"-page with children: It would be nice if the admin gives a "base-parent" for each user - where he is free to edit and create childs, but not somewhere else. The template of the parent and the child-Pages is always the same, thats why i dont want to / can't restrict access through the template. I also cant use the "settings-tab" on the page to give access, because it says: "Access is inherited from page "/" and defined with template: home" if i change the home-template-access: Template 'home' is used by the homepage and thus must manage access The plugin "page-roles" is not able to inherit the access to children, and its not possible to regulate EDIT/Create, only "view"...
  2. As I said I've been thinking about creating a kind of short cut InputfieldType similar to ryan's idea of repeatable fields. But this one would allow to manage a page's hidden child pages of a set of allowed templates skipping the way through the page tree. It's something I think would help people editing contents to work faster and avoid mistakes. And it still would keep the data hierarchically consistent within the tree. In the case of Repeatable Fields I guess it's all based upon FieldtypeMultiple and ryan stores the IDs of the hidden pages representing the single repeatable elements in the DB like in FieldtypePage. The point is, that - in case of my Fieldtype's idea - it wouldn't make sense to store any additional information in the db, as all information would be already stored within the pages' relations within the page tree (children, IDs, sort values). But when I'm not totally wrong, the Fieldtypes expect a DB scheme to be provided for installation, saving and getting values. Which methods do I have to override to work around using an own DB scheme and just provide data from API calls? Is it possible at all?
×
×
  • Create New...