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.
Related
I am running a server that hosts several disjunct instances of MediaWiki for several customers. There are a few set of CSS adjustments, which I would like to apply server-wide and "group-wide".
I already checked out WikiPedia's stacks of CSS classes, but they are all predefined and would most probably be overwritten on updates.
It would be perfect, if there were some kind of css.d folder, where I could store links to CSS files, but to the best of my knowledge there is not such a thing.
How should I realize sharing a CSS file among several instances?
Within a wiki family, install the GlobalCssJs extension and edit the MediaWiki:Global.js/MediaWiki:Global.css pages on the central wiki (manual), as you would do to customise a wiki's CSS.
Alternatively, write your own extension to make all your custom changes in a single place (the code repository) and then deploy them to all wikis with the usual methods you use to update code.
Is there a way to change the project listing so that sub projects display as nested items below their parent?
I have looked in the documentation and searched here, but cannot find anything.
At present the display of projects is either alphabetical or by creation date and doesn't differentiate between projects and sub projects.
It would be useful to be able to group projects in teh list under their master project.
NOTE: The Subprojects feature is still in development, so stuff might still change over the coming months.
There isn't a built-in way to do what you're asking, but that doesn't mean there isn't a way. For example, I often list the master project in the subproject's name, in brackets. (i.e. "Goldilocks [PawLIB]") This allows me to create and save a Projects query for those projects with "[PawLIB]" in the name.
There are a few other ways to approach the issue, such as strategic use of project icons or colors (queries can search by those).
In short, organize your projects using names, icons, or colors, and then set up a query. This does not nullify the usefulness of the subproject feature - that handles many trickier organization in the background - but the feature as it exists can't do everything.
Aside from that, you could technically request a feature, but I wouldn't recommend it. Developer Chad Little mentioned that the features are backlogged by about two years. All things considered, they have bigger fish to fry.
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 have a question regarding WP Document Revisions. I have a client with a parent company and 14 sister companies underneath it. What they're looking to do is to have a document repository where all documents get stored, but the trick is that each sister company has their own financials that should stay visible only to top management in that sister company but needs to be visible to all Executives in the parent company.
I've looked into WP Document Revisions and it does pretty much what I want concerning the document part, what I can't figure out though is how to create user groups and setting permissions for those user groups. In other words:
Set up an Executive Team group with permissions to view and edit the documents
Set up an Top Management group per 14 sister companies each with their own permissions
And then when the different users log in they should only see the documents that's set with their individual permissions.
Can anyone please help me with this, I've searched high and low but can't seem to find an answer, even if there's a different plugin that would better enable me to do the above, I'd be grateful for the help.
Regards,
Anina
I am the lead developer of WP Document Revisions. The above should be relatively easy to do as you described. There are two ways to do it:
First, you could set up a WordPress multisite install, and have individual subsites for each subsidiary, with one parent site for the parent corporation. Executives would have a login on all sites, while managers would have a login for their individual subsite, and for the single parent site. The advantage to this approach would be flexibility (if you'd like to use the workspace for other tasks, branding, etc.) but this flexibility would come at the cost of complexity (setting up 14 subsites).
The alternative approach, and perhaps what I would recommend depending on your needs, would be to group documents into a custom taxonomy (perhaps "companies"), and then base capabilities on what company the document is assigned to. This would allow you to have one single site, and could assign capabilities based on the proven and tested WordPress Roles and Capabilities system.
The functionality described in the second option does not yet exist out of the box, but is a relatively minor undertaking and is actually already under development for a potential "Pro" version of the plugin.
I hope the above is helpful. If you would be interested in discussing customizing the plugin to your needs, either as described above, or otherwise, please feel free to contact me directly.
Update: Updated link to contact information as Stack Exchange was blocking e-mail links.
I believe I have a working version of an add-on plugin that should do exactly what you're looking for. The file is here ( https://github.com/benbalter/WP-Document-Revisions-Code-Cookbook/blob/master/taxonomy-permissions.php ) and would be installed like any other plugin.
A bit more information is listed on the last question of the FAQ ( https://github.com/benbalter/WP-Document-Revisions/wiki/Frequently-Asked-Questions ), but in short, out of the box it will make a "departments" taxonomy, and will create capabilities based on any departments added. You would then install and activate Members, if you have not already, and use the interface members provides to add roles and assign capabilities.
You can tell the plugin to create and use any different taxonomy (e.g., "company" instead of "departments"), as described within the file.
It may not be 100% stable as it hasn't been tested in the wild yet, but it should work. Please let me know if it works for you, or if you'd prefer to have me set it up, etc.
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.