Add ability for many to many relationships for LDF relationships - Forum - Rollbase - Progress Community

Add ability for many to many relationships for LDF relationships


Add ability for many to many relationships for LDF relationships

  • Would it be possible to open the LDF relationships to many-to-many relationships? We have users in multiple locations/departments and right now it's limited to a one-to-one relationship.
  • Hi Frank,

    LDF on specific users is used to define where that particular user sits in the hierarchy, in addition to permissions.

    You can use Groups (see the Organization Management app) to assign a User to multiple Groups -- each group specifies what users in that Group have access to.

    In short, Groups is a multiselect in User create/edit page but Location/Department/Function are single select.

    Hope this helps,

  • Hi Matt,

    I just want to confirm what you said because it's going to mean we'll have to stop using the LDF functionality and use our own objects instead. It shouldn't be a big issue long term as we can use the relationship permissions in security but it will be some work in the application to switch around now and I wouldn't plan on going back to LDF again then.

    Can you confirm that the location and department relationships will always be a single relationship in terms of what's selectable from the other object perspective?


  • Hi Frank,

    Do you need an answer on this asap? I'd like to discuss internally but we may not be able to do so properly until later this month.


  • Matt,

    Unfortunately I would need to know within the next week or so if it's possible. We have a few prospects going into trial and if I start them using the LDF objects, it will be a manual process to swap those out to our own objects after their customer instance is created. So I need to switch out the objects by the end of next week to make sure things are stable and working for them.

    If this change is something you could confidently say is something you can do and are willing to do but it won't go in for a few weeks, we can make it work until then. I can let clients/prospects know that multiple relationships are coming and it will allow us to use the existing LDF objects in the meantime. I just don't want to get clients in and have them inputting data and then make a change to the application that won't apply in the upgrade process if that makes sense.

    Let me know what you think and we can take it from there. We have ways to make it work if this isn't something you can change but I would always ra
  • Hi Frank,

    I spoke with Pavel about this and confirmed that location, department and function will remain single-select lookups (due primarily to the performance implications of doing otherwise). Child nodes do inherit permissions from parent nodes, but a record can only be associated with one location, department and function.

    Hope this helps clarify,

  • Thanks, Matt-- I understand and appreciate the consideration. We'll move off of the LDF objects and go from there.


  • I find myself in a similar situation as mentioned above – needing to grant visibility of sets of records to various combinations of users. Using LDF with only a single allowed location creates difficulty as I have to create what should be a single "location" in several places of the hierarchy in order to achieve what we need. I am afraid this may quickly become unwieldy. Permission through relationship would work very well only I need some to use it with groups of users, that may change overtime, rather than directly to users. I will most likely proceed with LDF, but if a better option is suggested I would appreciate it.
  • Hi Andrew,

    Have you tried assigning multiple Groups to a user ?

    As mentioned, the Location, Department, and Function settings of a User are only used to append to the records he/she creates. It is actually the "Groups" that are assigned to a User that defines his actual view permission and the relationship between a User and Groups is One-to-Many.

    Ex. User (Martin), Locations Las Vegas and Sacramento, Groups Las Vegas Group and Sacramento Group.

    - Martin has the Location Las Vegas - Therefore if he creates a record under an object "Employee", the record could have the Location value of Las Vegas*

    - Martin is assigned the group Las Vegas Group (whose Location value is Las Vegas), Martin will now be able to see records under the Las Vegas Location, given that his role has view access to the "Employee" object (and other objects in fact).

    - at this stage Martin can't see records under the Sacramento Location

    - Martin is then also assigned the group Sacramento Group (whose Location value is Sa
  • Martin, thank you for the through followup. To answer your question we are using groups similar to your desription above. My fear is that it will become difficult to manage as the number of locations & groups grows. To give you an example,n using your analogy. Consider the following:

    Users in the Los Vegas location need to see a subset of records currently set to the Sacramento location.

    Users in the Sacramento location need to see a (possibly different) subset of records currently set to the Los Vegas location.

    Now throw in New York, Chicago, Houston, etc. and you can see where it can easily get out of hand.

    Currently we are able to do this with the hierarchical nature of location but it is less than ideal and confusing for the end users.
  • Hi,

    If this is the case, it would end up being the task of your admin side to manage the records within Location, possibly even department and function as well as the related groups. I see where your coming from due to the fact that the # of locations and groups are increasing (probably dept and function too).

    I would assume the location hierarchy would end up becoming:

    - Las Vegas

    - Subset 1

    - Sacramento

    - Subset 2

    What I think you could do is to auto-create groups when a location is created where the location is set as it's Location lookup.

    This would lessen the burden of creating groups every time a location is created. Although the # of records would still increase as you go along, at the very least you won't have to think about having to create the related groups.

    Using the existing LDF you can either:

    A.) Ride on the hierarchy feature for viewing, e.g. When you assign the Sacramento group to a user he/she also sees the subset or

    B.) do more specific assignments to users (w/c i
  • Martin, we are going to do similar to your suggestion. Good idea on auto creating the groups, we will also be auto creating the locations as well since it seems like they will align with our account structure.

    Relationship based permissions would also work. However since it is direct relationship between record and user and no way to relate between a record and a "group" of users it presents a problem. I don't want a situation where I have to update tons of records every time user affiliation changes.
  • Hi again,

    You can create a relationship to groups pointing towards the object that needs permission. Then after create and update of the records (both group and object) you can automate the attachment of users to the record to take advantage of the relationship based permissions. In turn nothing will be manual except for the group selection part.

    You will probably have to test the scenarios wherein a user is added to a group therefore he/she should also have access to the records assigned to the group and also when a record's group lookup changes so should the attached users

    Hope this helps

    Piscoso, Martin