On Friday 31 August 2007 10:14:31 am Adrian Crum wrote:
> Super User (admin)
> --
> Create/update/delete Forum Groups, Forums, Forum Threads, Forum Messages
> Create/delete Forum Group/Forum members (users and moderators)
>
> User
>
> Initially granted view permissions only
> Granted T
Yes. All but the Super User would be on a forum by forum basis.
Ean Schuessler wrote:
On Friday 31 August 2007 10:14:31 am Adrian Crum wrote:
Super User (admin)
--
Create/update/delete Forum Groups, Forums, Forum Threads, Forum Messages
Create/delete Forum Group/Forum members (users
Ean,
I don't know what the original intention of the forum security scheme was. I posted an RFC a few
days ago about forum permissions:
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/200708.mbox/[EMAIL PROTECTED]
I would like to see the forum permissions evolve into something like this:
On Thursday 23 August 2007 12:41:40 pm Al Byers wrote:
> Yes, the ownerContentId is strictly for security. Andrew did some clean up
> and addition of service-based permission granting code, so make sure you
> see those.
I looked at that permission code and it does seem flexible, but I have grave
Thinking about it more...
The service call will have to hit the database for each thread message until the first message in
the thread is found - which takes me back to the original point I made: it's going to be
inefficient. It would be better to hit the db once and scoop up all of the message
Let's say you're viewing a screen of recent forum messages, most recent on top. Clicking on a
message of interest takes you to a screen where all the messages in that thread are listed - so you
can see the message of interest in context.
If the first screen is generated from a list of Content G
Is that field really needed? I recommend stepping back and looking at the
process you're trying to do, in real terms of user interaction. From the stuff
here I don't see what that is.
If it's a hypothetical "how would I..." then I recommend making it more
concrete or the problem will be diffi
Al,
Thank you for the reply!
I'm hesitant to add another field that is specific to forums. As David has pointed out,
ownerContentId is intended to be used for security purposes and right now it contains the forum ID -
I don't want to change that.
How about a field named contentGroupId? Then
Adrian,
There are so many things about this that I cannot think of and, hopefully,
David will be able to comment. The InstanceOfContentId field is used in a
mode where content is derived from a template. I don't think that there
would be any conflicts in its use, but I am guessing the right philos
I think I've mapped out the basic entity usage for forums. I wanted to see if it's okay to use an
unused field to hold the forum thread ID. I know I can start with any ContentAssoc record and walk
up the tree to find the ID of the uppermost message (the thread start) but since forums (and
thread
Yes, the ownerContentId is strictly for security. Andrew did some clean up
and addition of service-based permission granting code, so make sure you see
those.
-Al
On 8/23/07, David E Jones <[EMAIL PROTECTED]> wrote:
>
>
> If I remember right ownerContentId was used for security purposes,
> permis
David,
Thank you for the replies! They are helpful.
-Adrian
David E Jones wrote:
If I remember right ownerContentId was used for security purposes,
permissions and such. In fact, it should ONLY be used for this purpose.
I'm not sure how the permission checking code is working right now, b
If I remember right ownerContentId was used for security purposes, permissions
and such. In fact, it should ONLY be used for this purpose.
I'm not sure how the permission checking code is working right now, but if it
does a tree walk base on the ownerContentId then it doesn't matter which way
Yes, the contentIdTo should be the child.
Just think of it in terms of the primary use scenario: find a child content
element (or sub-content) by using the contentId and a map-key (sorting and
filtering by from/thruDate the same as we always do for effective dates).
-David
Adrian Crum wrote
Okay, I found a reply from Al Byers in a July 3, 2007 content management thread
(user ml):
"So contentId is for the parent and contentIdTo is for the child."
Unless there are any objections, I will assume that is the correct method.
Adrian Crum wrote:
One other thing -
eCommerce forum Conte
One other thing -
eCommerce forum ContentAssoc.contentIdTo contains the "child" message (or reply to
"this" message).
Content Manager forum ContentAssoc.contentIdTo contains the "parent" message (the message "this"
message replied to).
Which method is correct?
Adrian Crum wrote:
I'm trying
I'm trying to debug the forum section of the Content Manager component and I
need help.
In the eCommerce forum, Content.ownerContentId contains the contentId of the "parent" message -
which created a nice tree structure.
In the Content Manager forum, Content.ownerContentId always contains the
17 matches
Mail list logo
