I'm doing a website which has lots and lots of different documents. They need them that way because they want to do all kind of filters and so on.
Since it is a really big company with a lot of structure they have a really set in stone hierarchy of content.
That way only inside some folders they want some kind of content types.
The only successful way I made it work was creating a per-content type global addable folderish content type which only allows to create the needed content type inside it and nothing else.
So in their FTI definition I have (on the global addable folderish content type):
...
<property name="allowed_content_types">
<element value="the.only.desired.contenttype" />
</property>
...
I used to see the "Restrict content types" on the "Add new..." dropdown, which would be extremely helpful in my case, since I have like 22 containers and 22 more content types, whereas with that "Restrict content types" I would only have 1 container and 22 content types.
Is there any way to do that on Dexterity?
Not a direct answer to your Dexterity question, but...
only inside some folders they want some kind of content types.
I've found folder-local permissions work beautifully for this.
You don't need any custom container types - just use regular Folders.
Ideally each item type needs its own add permission e.g. ACME: Add Thing 1 and ACME: Add Thing 2 for Thing 1 and Thing 2 types respectively.
Rather than set the roles who have the permission at the site root (i.e. in rolemap.xml), set them only on the Folder where they're required.
That's it. The rest of the setup of these content types is as normal. Make them globally addable. The permission assignment means they'll only really be addable in the specific folders you've chosen.
If you don't want the usual types (Page, Link, etc.) addable in that folder, turn off the acquiring of the relevant add permissions.
This is one case where it's ok to break the (very sensible) rule of using only workflow to manage permissions below the site root. Since it's easy to lose track of where you've been, I would set the local permissions in code in my setuphandlers.py so there's a clear record of which folders are affected.
Related
I am trying to create a site that will enable users to publish their projecs and enlist other people to join their project.
A user should be able to list a project, specify certain attributes (name,description, etc..).
There are few things i'm having trouble with.
First, by default publishing content is refered to as "content", i dont want a user to "add new content" but rather to "list new project".
Second, a project should have certain attributes, some optional and some mandatory, rather then the default title and body,
users should later be able to filter by these attributes when searching for projects.
is there a way to define the structure of content?.
Third, a user should be able to apply to a project, if he applies, the owner of that projects should receive the appliance, and accepte\reject.
In case he accepts, the users profile should be added a record that he is part of that project.
I am completly new to Drupal, and CMS in general.
My main expertise is with java, and I initially thoght about building the site with a java REST api in the backend and angular js in the frontend, but I have 0 experience with security and dodn't know how to do the user authentication and session management.
So I am currently trying out Drupal.
Is Drupal the right solution?
If so, how should I approach the requirements specified above?
Drupal (assuming that you are talking about version 7 since 8 is still in beta) is pretty powerful CMS, with a lot of (free) modules allowing it to expand it's possibilities.
When you are in back-end under Structure -> Content types you can see all available content types defined. There is also link "Add content type" which you can use to define your own. That basically means you can add any fields in any types you want. If you don't see the field type you need there is a big chances that there is a module which adds that field type so you just have to install it. You can also remove body (hide it actually), but title must remain (but you don't have to show it on front-end).
There is a "node reference" field type, but you have to install a module for it: https://www.drupal.org/project/references
So you can create dependencies you like.
And that "add new content" is just a link - you can create your own, set title as you like, just keep the same path. You can also set different theme for (some) admin pages if you want them to look differently. Under Structure -> Menus you can even edit admin menu, add new link and stuff..
Drupal is a bit heavy on resources, because of it's complex structure and database abstraction. For static content just turning on (built in) caches will help, but generally adding some additional caching mechanism won't hurt.
Am new to Alfresco, so this might be trivial, but I couldn't find the answer....
While using Alfresco Share, I will have many sites to be created. These are not known beforehand and will be done one at a time via the UI. I would like to have a standard set of 3 folders created each time I create a site. I think rules can be used for such a purpose?
Is this possible? If so, could you outline the detailed steps necessary? (New to Alfresco!)
thanks
Yes, a rule should be the starting point for this. The rule needs to be created on the Sites folder and set to "run on subfolders".
When your rule fires, it will be handed the folder that represents the site.
Sites have "containers" for the various tools used in the site which are just folders that site in the site's root folder. The container folders have a specific aspect and a component ID. Those containers get created lazily--they don't get created until the first user uses the component.
In your case, that means when you create a site, it doesn't contain a Document Library folder (it's actually named "documentLibrary") until someone uses the document library for the first time.
That means your rule will have to create the documentLibrary folder in the site folder. It needs to be named exactly like that, it needs to have the "st:siteContainer" aspect, and it needs to have st:componentId set to "documentLibrary".
Once that's done, your rule can create the standard set of folders, then you are done.
Because there is no out-of-the-box action that does what I've described, you'll use server-side JavaScript to implement this rule which just means you'll write the rule in JavaScript, upload it to Data Dictionary/Scripts, then point to it when you configure your rule.
As a side note, if your standard set of folders will change frequently, is complex, or needs to include documents (like sample content or something), you might want to use a space template and then create the documentLibrary folder based on that space template. If that sounds like overkill or isn't what you need, then forget I mentioned it and just have your rule create the three folders.
I find the hardest thing to explain to Plone end users is the concept of having to make a folder, a page and set the folder's default view to a page in order to have nested pages. Is there any reason I shouldn't include a folderish version of a page content type in my product?
there are existing products that provide folderish types that almost behave like pages for the end-user
eg. Products.Richdocument and raptus.article.
personally i prefere raptus.article because of it's concept of components. editors can activate carousels, or image galleries and define which of the contained images are displayed in which component.
in many project i also define custom components eg one for showing addthis integration under the article text if editors turn on the component.
Ulrich Schwarz is right when commenting that using folderish content types as pages brings in extra complexity when it comes to versioning.
the problems in versioning with cmfeditions could most likle be solved by using attributestorage instead of annotationstorage for archetypes fields. (see https://dev.plone.org/ticket/11887)
The simplest was is to compare Plone as a filesystem.
There are discussions/rumors about making all content types folderish, but right now I suggest you to to something folderish only when really needed. The UI of a folderish content is more complex
Keul is right. Compare Plone as a filesystem.
I think also that you don't always have to set a page as the default view of a folder, sometimes you just want to have a list of contents (files, images, pages, etc...).
I'm working with a Publication that is low in our tridion Blueprint hierarchy. Some of the content & schemas that are being inherited from Publications higher in the Blueprint are inappropriate for my Publication & will never be used by my Publication.
I'm going to follow up with the internal team that added those items & try & convince them that either:
these items should be in a different Publication or
our Blueprint needs to be tweaked.
If that goes nowhere, what are my options? Can I hide the content/schemas that I don't want? Also, it seems that it would helpful if the Blueprint had more fine-grained control over what exactly, I am inheriting.
Any suggestions?
Yes, you can control what's visible. Since inheritance (sharing) is separate from publishing, it's typically a good idea to:
Share schemas, Category definitions, and possibly shared templating functionality (e.g. TBBs)
Share, but hide components through folder permissions
Limit schema and template visibility per publication using subfolders
BluePrint Change?
Separate content publications (to avoid sharing) makes sense for certain scenarios:
Legal requirements. To meet legal or auditing requirements to avoid commercial information on a non-profit website, you might use two publications or a setup where commercial falls below non-profit content.
Multi-tenancy. Not common, but if you have a multi-tenant scenario which uses the same CMS but separate content, your "customers" would appreciate separate content publications.
Internal content. Intranets or other very sensitive information are "safer" when placed parallel or above global content publications.
If these don't apply, it's a good idea to share at least content. You'll want schemas in a separate, higher publication.
Share Structure and Definitions
Even if content should be in different publications, it's a good idea to share the "structure" or schema definitions for the components. A single schema publication can hold embeddable/metadata/regular schemas, Categories, and some system-level folders without impacting templates or content.
Content and Folders
It's actually a good idea to consolidate content into fewer shared content publications. This makes life much easier for authors, especially if you have a centralized content authoring team.
Even if in different groups, you can definitely "hide" non-relevant folders in child publications by doing the following:
Remove read permissions to folders in the lower publication to groups that have scope for that publication
Set the MMC snap-in setting Hide organizational items if no access to content to 1 (for true).
Schemas and Templates
You can also limit the visibility of schemas and templates by:
Placing schemas in subfolders with specific permissions. Only users and groups with read for those folders will be able to see and select the schemas in the component form view drop-down.
Doing the same for templates will limit who can see which templates. Template selection is already limited when creating component presentations on a page--only the associated schemas for the component's schema are selectable in the drop-down.
Address a "will never be used by my Publication" requirement through groups and permission settings on folders. If it's a case of "should never be...", then consider a BluePrint change.
Edit: fixed where Intranet publications should go, it's parallel or above any Global Content.
It is possible to use the security model to hide Organizational Items in BluePrint children - just remove Read permissions for all Groups at the appropriate level. Of course, this is dependent on the relevant items not sharing Organizational Items with inherited items that should be available at that level.
I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.
The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.
Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.
Any ideas?
If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.
TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.
In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.
The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.
Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.
In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:
On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.
Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.