Workspace Hierarchy

[julien]

Hello,
I'm a new user of opengoo for yesterday, and i'm too french.

It is a very good project.

on the link http://blog.opengoo.org/?p=25, It's write :
"Workspace Hierarchy. It is now possible to create workspaces inside workspaces! This allows for more flexibility to organize your work. For example, you could have in your Company a workspace for Development, which you can now subdivide into workspaces for Programming, Testing, Design, etc. When browsing the Development workspace you can see all of the items of all its child workspaces in a single, unified view."

   
Is it possible to reverse the principle. To use the same example, you could have in your Company a workspace for Development, which you can now subdivide into workspaces for Programming, Testing, Design, etc. When browsing the Programming workspace you can see the items of Programming and all of the items of all its parent workspaces in a single, unified view?

Is it easy to change the code?

Thanks.

Julien

PS : Excuse me for my bad speak English

[conrado]

Hello Julien.

Do not worry about your English. For most of us, English is our Second Language. 

Changing the code to achieve the behavior you describe would not be easy. It would affect all the architecture.

Why do you wish to do this? Maybe the solution you are seeking can be addressed with another twist?

[julien]

Thank you for the quick response.

It's easier to explain with an example. A large majority of user to a single child workspace.

   
Hierarchy organization of a compagny

Compagny -> Development   -> Programming   -> User1
                                                                             -> User2
                                               -> Testing              -> User3
                                               -> Design              -> User4
                   ->Human Resources-> DHR             -> User5
                   -> ...

   
If the user1 wants to share a document with user1 and user2, it puts the document in the workspace Programming.
If the user1 wants the document to be seen by the user1, user2, user3 and user4, it puts the document in the workspace Development.
But if the user1 wants to share a document to all the world, it puts the document in the workspace Compagny.

Is it comprehensible?
   
Another twist is it possible?

Thanks

Julien

[conrado]

So, what we would do in our installation:

Examples 1 (Programming) and 2 (Development) are ok. All you need to assure is that all users of the sub-workspaces have access to the 'Development' Workspace.

Now, what do you mean with "the whole world"? If you want to share with the whole company then, yes, a "Company" Workspace accessible by all company users is the best way.

If you want to "publish" content, then I would suggest a "Company"->"Public" Workspace, where you give access to all users, internal and external, and might even publish it on the Internet.

Also, a "Public" sub-space for "Programming" could be made, where you give access to everyone. That is where you would put the public information that is particular of "Programming".

All that can be made with the current application.

[julien]

Hello

Excuse me but I have not had the opportunity to respond before.
   
I tried to think as the application and ultimately is good.    
My way of thinking is probably too complicated to implement.
   
I am in the process of testing.
   
For the moment I have 3 questions :   
-In terms of "workspaces", instead of just sort alphabetically, there would be able to sort by "the color"?
-Is what is expected in the future to fill create sub-company to company creates at the install?
-Is it possible to retrieve the users create opengoo level contacts, and more to find in compagny?

Thanks

Julien

[conrado]

Hi Julien.

The sorting of the Workspaces is a bit more complicated than it might seem, so we are probably leaving it at what it is for some time.

I don't think I got your other two questions right. Maybe you can post them in french and I will try to figure them out (I believe I have a shot a it). Remember to post them in the Other Languages Forum

[gylf]

I don't know if this is what Julien is saying but I could see this example being useful:

Client Workspace
   -Client Project 1
   -Client Project 2

Adding "Joe Client" to "Client Workspace" would have "Joe Client" listed as a contact in both Client Project 1 and 2; likewise, all calendar activities in "Client Workspace" would appear in the sub workspace calendars, but activities in the sub-calendars would not necessarily appear in the parent.

That make sense? 

Seems like it gives more meaning to having workspaces nested (also provides a "project template" of sorts since you don't need re-add the parent's objects to the children.)

Actually, now that I look at it again, I see that it is currently the reverse; if you add "Joe Client" to "Client Project 1" he appears in "Client Workspace"

Maybe that is more useful in practice; just seems counter-intuitive because usually a child node inherits from the parent, not visa versa.

[conrado]

Workspaces are "collections" that aggregate (sum up) the information in their child (sub) workspaces.

So, if you position yourself in a workspace, you will see the information stored in all its sub-workspaces (but only those for which you are granted the rights).

If you want to share information to all projects of a client workspace you either:
1) Grant permission and publish in "Client Workspace" to all project people (this does not necessarily mean granting people at "Project 1" permissions to "Project 2").
2) Do a special Sub-Workspace under "Client Workspace": "General Information" and grant permissions on that.

[gylf]

I see - so it is by design.  That's fine, and it does make sense.  I was just a bit confused since inheritance usually goes down from the parent node instead of up from the child.  Thanks for explaining.

[amazingchicken]

Workspaces are "collections" that aggregate (sum up) the information in their child (sub) workspaces.

So, if you position yourself in a workspace, you will see the information stored in all its sub-workspaces (but only those for which you are granted the rights).

If you want to share information to all projects of a client workspace you either:
1) Grant permission and publish in "Client Workspace" to all project people (this does not necessarily mean granting people at "Project 1" permissions to "Project 2").
2) Do a special Sub-Workspace under "Client Workspace": "General Information" and grant permissions on that.

I am also new to OpenGoo, am looking at it for support of work I am doing for a NFP (Not-For-Profit) child care and also for some other PM work for myself.

I am "trying" to use a Company I created in my first workspace in a second workspace.  The Company has users and contacts which I would like to assign tasks to in this second workspace.

I'm not successful in this.  I can modify the Company to include a filter for the 2nd workspace, so that it displays in the 'Contacts' listing for that 2nd workspace.  But, I don't see the contacts/users available for task assignment.

Do I have to wrap all topics of the Company into one workspace?  How does this work, say, for a Company who supplies services to me for multiple projects, such as a real estate company who manages properties for multiple clients?

This is a wonderful product...I think I just need to understand it a little better!

Thank you,

JohnB