Re: what is the pourpose of "fake" projects?

As an experiment, I manually changed the flag "is_fake" to 0 in 
"projects" db table. The result is: 1. project becomes listed in webui; 
2. permission became effective for the project itself, NOT for related 
documents.

In a second attempt, I manually addedd the "url" property in "projects" 
db table. The result is: 1. project is listed in webui; 2. permission 
became effective for both project itself AND for related documents.
Only adding the "url" property did not work (permission did not work 
both for the project itself and for related documents).

So, as a very temporary workaround, I think I can script the changes to 
be made in database for enterprises added outside the webui (which is my 
first aim), the only collateral damage being many more projects being 
listed in the "project" section of the webui. Do you think this is ok?

As a related thought, I think that the "permission" editor in the webui 
for filesystem projects, which can't have any permission applied, is 
really confusing.

I really like opengroupware and would like to see it receive all the 
attention it deserves, as a basic component for "sound" intranet 
projects, so I appreciate very much your committment to help users

Many thanks. Renzo Vettori

Adam Tauno Williams ha scritto:
> On Mon, 2009-05-18 at 10:20 -0400, Adam Tauno Williams wrote:
>> On Mon, 2009-05-18 at 16:08 +0200, Renzo Vettori wrote:
>>> My production server is an (old) ogo 1.0a2. I have both fs and db 
>>> project backend installed.
>>> I created a number of enterprises in the webui, and noticed that a 
>>> project was automatically created for each enterprise, which was not 
>>> listed at first in the webui (I can see these projects listed in db 
>>> "projects" table, with an empty path and an attribute is_fake=1). I am
>>> When I set some permission for the created projects using the web ui 
>>> (these projects can be reached using the "projects" tab in enterprise 
>>> webui), these projects apparently spring into existence (projects are 
>>> listed in the "project" section of the webui, documents can be added) 
>> Hmm, I'm not certain that is the intended behavior.  I believe "fake"
>> projects should remain hidden from searches, etc...
> 
> According to the docs I have fake projects should NOT appear in search
> results, however they do one permissions have been applied.
> 
>> Fake projects are actually quite useful to act as containers for
>> documents, tasks, etc... that are managed via some special means.  Or in
>> the case of the enterprise fake projects to store content associated
>> with an enterprise.
>>> but I noticed that everyone has full access to project settings and 
>>> documents, regardless from applied permissions, so their usefulness is 
>>> limited, for my purposes.
>> Perhaps the fake projects are filesystem projects?  I'll take a look, I
>> don't recall off hand.  If so there should be an option to determine the
>> default backed for fake projects.
>>> Is this the intended behaviour? Can "fake" projects be turned into 
>>> "normal" ones (i.e.: projects with configurable permissions) or is there 
>>> some default that can be set to avoid "fake" projects creation?
>> Yes, it is just a flag in the database.  But if they are filesytem
>> projects it won't change the permissions issue (a filesystem project
>> inherently don't support permissions).
> 
> They appear to be database projects so permissions should be effective
> (although internally they have no "url" property which I think should be
> considered a bug).
> 
-- 
OpenGroupware.org Users
[email protected]
http://mail.opengroupware.org/mailman/listinfo/users