Restricted choice in ManyToOne, ManyToMany editors?

[Ognen Ivanovski-2]

Hi again,

I have the following situation.

A, B, C - entities

A OneToMany B
A OneToMany C

B OneToMany C

In the C class I have a ManyToOne editor for the property referring  
to B. When trails show up available choices it shows up ALL instances  
of class B available for selection. I don't want that. I want to  
show  only the instances of B where B.getA() == C.getA() (in other  
words  I want to show only B instances that have that share the same  
parent A as the C instance I'm editing.

To illustrate this better, lets say we have

@Entity
class Category {
   @OneToMany(mapppedBy="parentCategory") @Collection(child = true)
   Set<SubCategory> subCategories;
}

@Entity
class SubCategory {
   @ManyToOne
   Category parentCategory;
   @OneToMany(mappedBy="subCategory") @Collection(child = true)
   Set<Topic> topics;
}

@Entity
class Topic {
    @ManyToOne
    Category category;
    @ManyToOne
    SubCategory subCategory;
    String title;
}

Now, when I am editing a topic, I'd like the field subCategory to let  
me chose from all SubCategories that belong to the same Category as  
the Topic, not ALL the SubCategories that are there.

The same thing is needed for  ManyToMany links.

How can this be done? Do I need to extend the HibernateEditCollection?

--
Ognen Ivanovski | ognen.ivanovski@...
phone [phone] | fax [phone]
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk




---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alejandro Scandroli]

Hi Ognen

This feature is not ready yet:
http://jira.codehaus.org/browse/TRAILS-99
http://jira.codehaus.org/browse/TRAILS-100

So yes, you'd need to extend the EditCollection component.
The changes should be minimal, take a look at the AssociationSelect
component mentioned on the jira issues.

Alejandro.


On 10/24/07, Ognen Ivanovski <ognen.ivanovski@...> wrote:

> Hi again,
>
> I have the following situation.
>
> A, B, C - entities
>
> A OneToMany B
> A OneToMany C
>
> B OneToMany C
>
> In the C class I have a ManyToOne editor for the property referring
> to B. When trails show up available choices it shows up ALL instances
> of class B available for selection. I don't want that. I want to
> show  only the instances of B where B.getA() == C.getA() (in other
> words  I want to show only B instances that have that share the same
> parent A as the C instance I'm editing.
>
> To illustrate this better, lets say we have
>
> @Entity
> class Category {
>    @OneToMany(mapppedBy="parentCategory") @Collection(child = true)
>    Set<SubCategory> subCategories;
> }
>
> @Entity
> class SubCategory {
>    @ManyToOne
>    Category parentCategory;
>    @OneToMany(mappedBy="subCategory") @Collection(child = true)
>    Set<Topic> topics;
> }
>
> @Entity
> class Topic {
>     @ManyToOne
>     Category category;
>     @ManyToOne
>     SubCategory subCategory;
>     String title;
> }
>
> Now, when I am editing a topic, I'd like the field subCategory to let
> me chose from all SubCategories that belong to the same Category as
> the Topic, not ALL the SubCategories that are there.
>
> The same thing is needed for  ManyToMany links.
>
> How can this be done? Do I need to extend the HibernateEditCollection?
>
> --
> Ognen Ivanovski | ognen.ivanovski@...
> phone [phone] | fax [phone]
> Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Toby78]

Hi there!

I am having a hard time trying to do a project "properly" on basis of Trails Security and I am currently thinking of maybe doing it completely without Trails security as it would be a lot easier and quicker to do - although I would prefer a clean and secure approach.

As an example imagine the following situation:

1. A User can upload Pictures on a website. Those Pictures are only visible to the User and require the Association "user" - this way they are private and nobody else can see them.

Those pictures also carry a title and a description as well as a category.

2. Other Users can browse a directory of the picture metadata, e.g. Title and Description. All other fields are not visible to them

3. If another User wants to see those pictures, he/she has to request View Rights on that entity on the other fields, e.g. the crypted picture url/filename.

4. If the other User has been approved by the owner of the picture succesfully, those additional fields become visible.

5. All pictures need to be approved by an Admin. The admin clicks on a check box to enable pictures in general - without that the owner changes to Admin just because the Admin updates the "approved" flag.

As the User Association makes all data invisible to anyone, I do not know how this could be solved using Trails security!


What do you think ?

Toby

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[nhhockeyplayer]

Toby,

All your assertions are valid and feasible.

I am not sure if project generation for trails is ripe as of now with regards to starting/generating a new project as I have not done it for many months.

It takes developer grade knowledge I think to get thru it and I do not know if it is ripe yet (project generation). Kalle and Alejandro would know better.

If there are issues then they should be JIRA for those. I did my share months back in the past.

Copy roster to a new project. It comes with image support and security already in place as well as lots of relationships that you can rename or model to your domain...

Thats what I would do as a newbie.

Best regards
Ken in nashua

> Date: Wed, 24 Oct 2007 12:34:06 +0200
> From: superoverdrive@...
> To: users@...
> Subject: [trails-users] Trails security - Restrictions of ViewRequiresAssocation("user")
>
> Hi there!
>
> I am having a hard time trying to do a project "properly" on basis of Trails Security and I am currently thinking of maybe doing it completely without Trails security as it would be a lot easier and quicker to do - although I would prefer a clean and secure approach.
>
> As an example imagine the following situation:
>
> 1. A User can upload Pictures on a website. Those Pictures are only visible to the User and require the Association "user" - this way they are private and nobody else can see them.
>
> Those pictures also carry a title and a description as well as a category.
>
> 2. Other Users can browse a directory of the picture metadata, e.g. Title and Description. All other fields are not visible to them
>
> 3. If another User wants to see those pictures, he/she has to request View Rights on that entity on the other fields, e.g. the crypted picture url/filename.
>
> 4. If the other User has been approved by the owner of the picture succesfully, those additional fields become visible.
>
> 5. All pictures need to be approved by an Admin. The admin clicks on a check box to enable pictures in general - without that the owner changes to Admin just because the Admin updates the "approved" flag.
>
> As the User Association makes all data invisible to anyone, I do not know how this could be solved using Trails security!
>
>
> What do you think ?
>
> Toby
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>

---

Climb to the top of the charts!  Play Star Shuffle:  the word scramble challenge with star power. Play Now!

[Kalle Korhonen-2]

On 10/24/07, superoverdrive@... <superoverdrive@...> wrote:

Hi there!
I am having a hard time trying to do a project "properly" on basis of Trails Security and I am currently thinking of maybe doing it completely without Trails security as it would be a lot easier and quicker to do - although I would prefer a clean and secure approach.
As an example imagine the following situation:
1. A User can upload Pictures on a website. Those Pictures are only visible to the User and require the Association "user" - this way they are private and nobody else can see them.
Those pictures also carry a title and a description as well as a category.
2. Other Users can browse a directory of the picture metadata, e.g. Title and Description. All other fields are not visible to them
3. If another User wants to see those pictures, he/she has to request View Rights on that entity on the other fields, e.g. the crypted picture url/filename.
4. If the other User has been approved by the owner of the picture succesfully, those additional fields become visible.
5. All pictures need to be approved by an Admin. The admin clicks on a check box to enable pictures in general - without that the owner changes to Admin just because the Admin updates the "approved" flag.
As the User Association makes all data invisible to anyone, I do not know how this could be solved using Trails security!
What do you think ?

Correct, the owner-instance based associations are static the same way the role annotations are - i.e. you cannot later decide you want this entity be protected by some role (but naturally you can assign roles and associations run-time as you wish). For dynamic security rules (at one point you want it to behave one way, at one poin later some other way) such as in your case above, you are better off implementing the security yourself. You might take advantage of the static associations that you know won't change - like only the owner of the pictures can see them by default, and then implement the rest of the cases as "exceptions" to this rule. The advantage is that a common security failure - whoops I forgot to "secure" something - cannot happen. The picture metadata could be its own entity because it's (again, as a static rule) is available to all, and it's easy to do OneToOne associations in Trails. On the page where you show the picture that user has request access to and has been approved, you can turn off the security as needed, by doing SecurityContextHolder.getContext().setAuthentication(null) - if there's no authentication in the security context, security rules are not used.

So, as a rule of thumb: static rules with built-in annotations, dynamic rules in application code.

Kalle