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.
Related
I'm trying to figure out a way to make Phabricator manage several unrelated products. I installed Phabricator, imported a few source repositories and customized the side menu by adding all the default Phabricator applications (just to get an idea of what Phabricator offers "out of the box").
At first, I liked what I saw, but after spending a bit of time exploring, it started to appear Phabractor is just a collection of various SCM tools that are not linked together. I'm really looking for a set of top level "Products" and under each I can create various related Wiki Pages, Tasks/Bugs, [sub]Projects, Uploaded Files, Legalpad entries, etc.
What I am seeing, for example, is a general Wiki Engine (Phriction) that is no way linked to a Project or a top-most Product. Also, I can create a Legalpad document, but again cannot assign it to a project or product. Same with Files I upload. Even my imported source code repositories are just floating out there without any link to a Project or Product.
Am I missing something? Is anyone using a single instance of Phabricator to manage multiple unrelated products with potentially different groups of end users?
One potential work-around is I could setup a custom Dashboard for each of my products and link in the associated projects, tasks and even links to related wiki pages, but seems like a lot of work for each product and it still seems there is no way to categorize Uploaded Files and Leagalpad.
#Flagrama answers is most of the reality. If you want simple hard separation like you could find in other tools like Redmine, Phabricator is not conceived this way.
Now there is something that could make thing a little more natural: Phabricator Spaces.
It allows to split things pretty neatly. You can see the doc here:
https://secure.phabricator.com/book/phabricator/article/spaces/
In Phabricator you can create a Project. You can set it up so that anybody can join it, or so only administrators can add users. You can also make projects only visible/joinable to members of other projects.
"Visible to Members of Project..." is the basis of managing unrelated projects in Phabricator. Every repository you create, page you add to the Wiki, file you upload, or LegalPad document you create can be set to only be visible to members of a certain project.
Unfortunately I'm pretty sure this is the limit of Projects in Phabricator at present so it may still not meet your needs.
Phabricator is very flexible and includes several different ways to organize your work and your workflows.
Spaces
Another answer already suggested that you could try Spaces, which is a sort of global grouping and that can be used to isolate everything within one space and keep it almost entirely separate from everything that's in another space.
Projects
Phabricator also has a concept of "Project Tags" which you can use to organize tasks, repositories, blog posts and various other "Objects" within the various Phabricator applications. Most objects support one or more tags and the tags are defined by Projects which you create. Tags can be used as free-form labels or you can create a hierarchy of projects and sub-projects.
I'll go into a bit more detail about using Phabricator's Projects feature since that is how I've used Phabricator so that is what I'm familiar with.
Organizing your work with with Projects and Tags
Create a top level project for your tool, product, team or whatever makes sense in your situation.
Tag the repositories, wikis pages, blog posts, tasks, etc which belong to the project created in 1. using the project's #hashtag.
Customize the menus on your project to link to related repositories, wikis, documentation, etc. The project menus are quite flexible, as are other "profile" menus such as dashboards and user favorites menus.
Use the project's workboard to manage tasks related to the project.
Create subprojects, milestones, etc as needed.
6, Repeat 1-5 for each project you work on.
We have a main schema which are using for generic content at many places and across blueprint for many websites(markets).
Now one of the website(market) wants one extra field but all other do not wants to see this in their publications.
I suggested to rename the fields for all other markets like (Not in use) but they are not agreeing on this as well.
What are the possible solution to hide the field from the child publication?
My suggestion is to not hide the field. Simply add the new field as non-mandatory and in its description clearly call out that it's only applicable for Market B such that the other markets know not to use it. This is simple, requires no effort and is a maintenance free solution. Otherwise a GUI extension is your best bet.
Without knowing the full context it is hard to give an advise. But in general I would not recommend to hide fields (even though it's possible with a GUI extension in 2011 and with some hacking in 2009). I think Tridion offers plenty of options to solve the puzzle out of the box. For example:
Isolate the common fields into an embedded schema and set up separate content schemas for market A and market B which reuse the common fields
Isolate the different fields into content schemas for market A and market B and create a component link field in the original schema which links to those specific schemas.
With security on folders you can limit access to the market-specific schemas.
I am working on a ASP.NET MVC 2.0 Multi-Presentation web application which would use a common codebase to support different websites. These websites would differ in following aspects:
Each website will have their own headers, footers, images, CSS etc (I guess website specific Master Pages)
Some of the UI elements could be different based on soft-coded settings at website level
What is the best approach to handle these requirements? Should I be storing these website level soft-coded settings in Database or multiple config files? I might have to provide a admin UI to manage these soft-coded settings. How do I access these settings in different layers (MVC, Services, Repositories etc) of my application?
I need suggestions from experts.
Regards,
Alex.
Develop some sort of Presentation Object Model (or possibly Aggregate if you're DDD inclined) and then persist that to the db. It could be per-user or per-site (if it's a multi-tenanted app you're building) and with MVC it would be easy to build Html Helpers that accept these Presentation Model Objects and render out your customized header, css, images etc.
Potential long-shot practical example:
Let's say your 'tenant' is called a Site - you'll prob have a Site object in your model. A property of Site could be a WebPresentation object. WebPresentation may have a series of child objects and lists with methods for reading css, css files (for <link> elements in the document head), images, etc. You may also have a Service or set of Service functions for persisting/validating the WebPresentation objects (or you may try to have this functionality come off the objects themselves- think .Save()). I won't go into how you persist this data to the db (don't want to insult you). As for the Views, you would design them (perhaps Partial Views) such that the custom WebPresentation Html helpers render the customizations out into the views or <head> sections of your MasterPages.
I hope this example is useful.
I just want some opinions on what's the best way to go about meeting the following requirements.
I have
One main Drupal Installation
It is a typical "listings" site where users can list items
One user can have how many ever "listings" that are linked to his account
I want to be able to create sub-accounts, that use the same base site. However, for each subsite:
Only the users listings must appear on his site
It must have a completely different theme.
It must have its own menu items
The site must run off it's own domain OR subdomain
I need some answers:
Is this possible, or will each user need a completely new Drupal installation and just use a web service or something to get its listings from the main site?
What modules / components will make my life easier?
Any other suggestions to make this as simple as possible?
The problem description is not detailed enough to give a fully sound advice (and - additionally - it looks like you could probably get better advice on a drupal specific forum, as the question seems more related to installation and configuration than to programming), however - from what I understand - it looks to me that your solution could give in either of the two directions:
Tweaking a single installation to appear as different sites
Creating multiple sites that shares the same codebase and part of the data
The tweaking solution has the advantage that you have only one DB to mantain, but there is no actual real separation between the subsites. You could implement this by:
SUBSITES: mapping various subdomains on the same IP
CONTENT: using the native permission system to filter which list items to display (for example: each logged user can display only nodes created by himself, or set to be visible to its role, or having as associated taxonomy term its username...)
THEMES : if subsites will be used only by logged-in users, use the same mechanism that you would use for filtering content [each user can natively pick a different theme if you allow them to], if they must appear with a different look also to anonymous users, then use the URI to pick up the appropriate theme (if visitor X reaches the site via user1.example.com the site will have the blue theme, whilst if the URI is user2.example.com the theme will be pink).
The multiple sites solution has the advantage that you have a real separation between subsites (with even a different DB). But you would then have to either sync or transfer "on the fly" data between the main site and the subsites. If you go for this solution, you should probably take a look at the following links:
the services module, which allows to easy set up webservices
this page explaining how to connect drupal to different databases (surely faster than using webservices... reasonable solution if you for example have sites and subsites running on the same server)
I didn't want to stick this in a small comment but I am in agreement with mac on many of his points (upvote!).
The best way would be to create your subdomains and have them be symbolic links in the site folder to the default / main-domain folder.
Given what you have told us, you are much better off creating a module that creates its own node types (or even just CCK) and use a combination of the permission system (CCK offers this as well through content_permission), Views, etc. No need for separate sites, just need users to look at their own content.
The beauty of this approach is you can use Flag to allow user's to friend each other, use Views to allow them to see friend's lists, etc.
Theme's can be set on the account level, so no issues there.
"Have their own men" - does this mean have their own block on the sidebar or header than has customized links or a completely different menu SYSTEM? Will need clarification before I can answer that.
My site is to have a section for normal users, a section for managers, and a section for use only by anonymous visitors. Each section of the site requires changes to Drupal settings for using a different theme, changing the Primary & Secondary links, changes which blocks are used, etc. In other words, the user experience changes significantly from section to section.
I could probably accomplish what I need by using Drupal's multi-sites, a shared database, and using settings.php to override the variables I need to (ie: menu_primary_links_source). However, to make things more manageable from an operational point of view, and to buy flexibility, I'm considering using the PURL API (purl.module) to prefix the URLs for certain site sections, and having my theme and custom modules react according to the current PURL prefix.
Before I get started, I want to ensure I'm not discounting Spaces.module. Spaces uses PURL, Features, and Context (which I'm also currently using for my site). I don't entirely understand how exactly Spaces fits into the picture. Would it help me make different site sections, each with specific configuration & behavior? Or am I better off depending directly on the PURL API?
The Spaces-PURL-Context conundrum. Fun. I've been meaning to write this up long-style to finish wrapping my head around it.
What is Spaces?
Spaces is a module that creates containers of overridden configuration for your site. It's not specifically about features, it's about any number of configuration values that are able to work with Spaces, including whether a Feature is active or not. (Active does not mean the module is disabled, just that a number of Feature-oriented things are whisked away, such as content types and Spaces-aware Views.
When using Spaces, you need to decide what type of "buckets" you want to use. Open Atrium uses OG and User-shaped buckets, what you need is a new sort of bucket based on user role. For the sake of sanity, you might even need to create a separate module just to define user roles as a more concrete thing in Drupal, kind of like how Spaces OG needs to lean on Organic Groups for a number of concepts.
What is Context?
Context is ultimately a page decorating mechanism. You tell it some stuff about the page, it modifies the page accordingly. Context cannot modify the URL, it's the other way around. Features define Contexts to tell the site how to render a given page uniquely for that Feature, there is no direct connection between Context and Spaces or Context and PURL.
What is PURL?
PURL is a method of sticking things in the URL and keeping them there until you are done with them.
How this Glues Together
Spaces with PURL integration are triggered based on one of two things: The URL or something about the content in the page. To explain this, I'll use Spaces OG as an example.
You click a link. The link was prebuilt with a PURL component that Spaces OG is watching for clues. If that piece of the URL makes sense to spaces, the Space is triggered.
All links except those that opt-out of the PURL modification persist the PURL URL element, meaning the Space is happy, and re-triggers with each page load.
Spaces OG knows to check nodes for their group affiliations. If Spaces can crack open a node and find a group, it will trigger that node's Space, using PURL's modified version of drupal_goto() to redirect the whole page for URL consistency. This will trump any existing URL structure.
If there is no URL component, and the node has no group affiliation, no Space is triggered.
Once the Space is triggered, all of that Spaces configuration values are pulled into play. This will mean the Space's preset defaults (you can have multiple default Space configurations for every Space type) overlay Drupal's defaults, which in turn are overridden by any configuration saved specifically for the Space. In the case of Open Atrium, this includes such nice things as group color, blocks on the dashboard, and enabled Features.
If the user goes to visit something provided by a Feature--a Node, a View, etc, any Contexts related to that node, that view, that URL that any module provides might just be triggered, and start doing things with blocks and theming to tailor the page for the Feature's content.
Next Steps
As I mention above, it sounds to me as though your first step is to try looking at Spaces OG, and rewriting it to be centered around the User Role instead of Organic Groups. You shouldn't have to do much with PURL directly besides a little copy and paste from Spaces OG. You might want to post in the Spaces issue queue to float this idea where the maintainers might see it and give pointers.
The way I understand the spaces module is this:
It provides a way for the features module (and your "features" created from this) to integrate with and be available within defined areas of your site. Out of the box this includes: Organic Groups, Taxonomy, and Users. There is an API to define more "spaces" than this.
So for example you could create a "feature" (with the features module) of an image gallery. Using spaces with organic groups, you would be able to have each group have the ability to enable and disable this feature and it would only be available within that "space" (group in this case).
From the organic groups page:
Groups get their own theme, language, taxonomy, and so on. Integrates well and depends upon Views module
So in your situation, you could think of spaces as a way to make organic groups more flexible. As NoParrots said, OpenAtrium (http://openatrium.com/) relies on the features/spaces/context modules heavily, so that might be a good place to review how these modules work together.
EDIT:
I found a great video that might explain things more clearly: http://www.archive.org/details/TheHeartOfOpenAtriumContextPurlAndSpaces_782. Around 16:00 he starts talking about PURL.
From this page (below the video) there is also an explaination of PURL/Context/Spaces which I think is pretty good:
Context is a module for triggering reactive behaviors within a page load.
Controlling block visibility, menu
trails, page classes, and page
template layouts are examples of
things that fall into its
jurisdiction.
PURL is a library for capturing and abstracting request handling that goes
beyond what the Drupal core menu
system provides ($_GET['q']).
Detection of request components, like
subdomain, path prefix, user agent, or
file extension, and sustaining their
presence is its primary role.
Spaces is a generalized configuration override framework. In
theory it allows you to "customize
everything, for anything." In practice
it allows things like custom group
colors and features, per-user
dashboards, and multisite-like usage
of a single Drupal install.
I would suggest using Spaces or Organic Groups. Spaces was used considerably in Open Atrium... a Development Seed out-of-the-box intranet package. Intranets really require the concept of access control and feature visibility depending on which department or role you have so I'm confident that Spaces will be very good for you.
Of course there is the venerable Organic Groups also. Spaces is a "higher" level concept than PURL. Spaces uses the context and PURL modules BTW. My gut instinct is for you to use Spaces or Organic groups.
There are a couple of videos on the net that talk about Spaces. Check them out.