Re: CMDB Row Level Security
Just looked at local logs when logging into both App servers (active link, filters, sql, API) and they are the same. I'm looking into the DB right now. This is so weird Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, June 27, 2014 10:31 AM To: arslist@ARSLIST.ORG Subject: Re: CMDB Row Level Security ** that might have affected how the records were created, and what their settings are, but it shouldn't affect how they look when viewed by one server vs the other. One thing you can do is to turn on AL/Filter logging on each server and see if there is anything updating the row on get, or something similar...even this should be the same between servers...but sometimes things can get out of sync... On Fri, Jun 27, 2014 at 8:28 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: Good question, I'll get with our DB guy to get this info (we don't have direct access to do any SQL queries in the DB). One theory we having is that one of the servers (server 1 that only has the 10006 permission) was create with Multi Tenancy turned on (which is checked on by default) and that might have something to do with it. While Server 2, we unchecked it. We did eventually find this out and unchecked MultiTenancy on server 1 after the fact, but the CMDB Row Level fields never changed back. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, June 27, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Re: CMDB Row Level Security ** Lisa, what does it show when you look at the row in the DB, via SQL tools? I don't know how you would be seeing different results one one server vs the other. On Fri, Jun 27, 2014 at 8:14 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: ** 2 new 7.6.4SP5 Servers (in a server group, no load balancer). After everything is set up we start importing our CI’s and on server one 40% of the CI’s have 10006 in the CMDBRowLevelSecurity field on the BMC_BaseElement form for server 1. Server 2 has 10006 and Unrestricted Access on this same record same field (different server). Same Database. What could have caused this? Why is the same record’s row level permissions different on different servers sharing the same database Lisa Kemes Remedy Consultant Dev Technology Group DLA Office: (717) 770-6437 tel:%28717%29%20770-6437 tel:%28717%29%20770-6437 Cell Phone: (717) 602-9460 tel:%28717%29%20602-9460 tel:%28717%29%20602-9460 lisa.ke...@devtechnology.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
CMDB Row Level Security
2 new 7.6.4SP5 Servers (in a server group, no load balancer). After everything is set up we start importing our CI's and on server one 40% of the CI's have 10006 in the CMDBRowLevelSecurity field on the BMC_BaseElement form for server 1. Server 2 has 10006 and Unrestricted Access on this same record same field (different server). Same Database. What could have caused this? Why is the same record's row level permissions different on different servers sharing the same database Lisa Kemes Remedy Consultant Dev Technology Group DLA Office: (717) 770-6437 Cell Phone: (717) 602-9460 lisa.ke...@devtechnology.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: CMDB Row Level Security
Lisa, what does it show when you look at the row in the DB, via SQL tools? I don't know how you would be seeing different results one one server vs the other. On Fri, Jun 27, 2014 at 8:14 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: ** 2 new 7.6.4SP5 Servers (in a server group, no load balancer). After everything is set up we start importing our CI’s and on server one 40% of the CI’s have 10006 in the CMDBRowLevelSecurity field on the BMC_BaseElement form for server 1. Server 2 has 10006 and Unrestricted Access on this same record same field (different server). Same Database. What could have caused this? Why is the same record’s row level permissions different on different servers sharing the same database Lisa Kemes Remedy Consultant Dev Technology Group DLA Office: (717) 770-6437 Cell Phone: (717) 602-9460 lisa.ke...@devtechnology.com _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: CMDB Row Level Security
Good question, I'll get with our DB guy to get this info (we don't have direct access to do any SQL queries in the DB). One theory we having is that one of the servers (server 1 that only has the 10006 permission) was create with Multi Tenancy turned on (which is checked on by default) and that might have something to do with it. While Server 2, we unchecked it. We did eventually find this out and unchecked MultiTenancy on server 1 after the fact, but the CMDB Row Level fields never changed back. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, June 27, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Re: CMDB Row Level Security ** Lisa, what does it show when you look at the row in the DB, via SQL tools? I don't know how you would be seeing different results one one server vs the other. On Fri, Jun 27, 2014 at 8:14 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: ** 2 new 7.6.4SP5 Servers (in a server group, no load balancer). After everything is set up we start importing our CI’s and on server one 40% of the CI’s have 10006 in the CMDBRowLevelSecurity field on the BMC_BaseElement form for server 1. Server 2 has 10006 and Unrestricted Access on this same record same field (different server). Same Database. What could have caused this? Why is the same record’s row level permissions different on different servers sharing the same database Lisa Kemes Remedy Consultant Dev Technology Group DLA Office: (717) 770-6437 tel:%28717%29%20770-6437 Cell Phone: (717) 602-9460 tel:%28717%29%20602-9460 lisa.ke...@devtechnology.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: CMDB Row Level Security
that might have affected how the records were created, and what their settings are, but it shouldn't affect how they look when viewed by one server vs the other. One thing you can do is to turn on AL/Filter logging on each server and see if there is anything updating the row on get, or something similar...even this should be the same between servers...but sometimes things can get out of sync... On Fri, Jun 27, 2014 at 8:28 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: Good question, I'll get with our DB guy to get this info (we don't have direct access to do any SQL queries in the DB). One theory we having is that one of the servers (server 1 that only has the 10006 permission) was create with Multi Tenancy turned on (which is checked on by default) and that might have something to do with it. While Server 2, we unchecked it. We did eventually find this out and unchecked MultiTenancy on server 1 after the fact, but the CMDB Row Level fields never changed back. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, June 27, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Re: CMDB Row Level Security ** Lisa, what does it show when you look at the row in the DB, via SQL tools? I don't know how you would be seeing different results one one server vs the other. On Fri, Jun 27, 2014 at 8:14 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: ** 2 new 7.6.4SP5 Servers (in a server group, no load balancer). After everything is set up we start importing our CI’s and on server one 40% of the CI’s have 10006 in the CMDBRowLevelSecurity field on the BMC_BaseElement form for server 1. Server 2 has 10006 and Unrestricted Access on this same record same field (different server). Same Database. What could have caused this? Why is the same record’s row level permissions different on different servers sharing the same database Lisa Kemes Remedy Consultant Dev Technology Group DLA Office: (717) 770-6437 tel:%28717%29%20770-6437 Cell Phone: (717) 602-9460 tel:%28717%29%20602-9460 lisa.ke...@devtechnology.com _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
I wanted to give a quick update on this. I'm currently testing it. I created a field I called ReadOnlyGroups with Field ID 60710 and set the default of that field to be ;-10; so it will pick up the Unrestricted Access group by default. I also created a radio button called Confidential that when checked will clear out the ReadOnlyGroups field. However, upon further investigation, it looks like the Customer's company group id goes into Assignee Groups (112) and the Support Group Company group id goes into Vendor Assignee Groups (60900). As a result, they are still visible to people in those organizations, which unfortunately is too many. If I clear those two fields out as well, then nobody other than administrators can see it. That surprised me a bit because I would have thought the Assignee Groups field would have been used to actually track assignee groups. I'm not really able to see where the specific group is being tracked in such a way that would be used to drive permissions. For example, the Assigned Group ID and the Owner Group ID fields are there, but storing the Entry ID field rather than the group id. As a result, it looks like they aren't using Group security for actually securing the Incidents. My next step is to create a ReadWriteGroups field with a Field ID of 60715 that I can then move the General Access role to by defaulting it to ;-2;, remove that role from having access to the Entry ID and add the ReadWriteGroups dynamic group to that and see if that makes a difference. At that point, I can also see about adding the actual groups tied to the Support Groups to this field as a part of my workflow. I also need to investigate some workflow that is broken by doing this. Specifically, the active links to make the record read only and display the warning on the banner instead of the process flow bar aren't working. However, users that don't have write access still can't get to the record. Does anyone know of anything else I should look at, specifically any other fields on HPD:Help Desk that might need to be taken into consideration so I can ensure that the Assigned Group are the only ones (other than Remedy admins) who have access to the Incident? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security
Re: Row-Level Security on HPD:Help Desk
One more update for today since some people have emailed me off list with interest in what I'm doing. What I ended up doing so far is this: 1) Create a custom character field on HPD:Help Desk called ReadOnlyGroups (FID 60710) to store a default of ;-10; to be able to handle Unrestricted Access permissions. 2) Create a custom radio button on HPD:Help Desk called Confidential that functions as a flag. 3) Create a filter that executes upon submit or modify when the Confidential flag is set for the first time or the Confidential flag is set and the group assignment changes. a. This does a Set Fields from CTM:SYS-Access Permission Grps which sets the Vendor Assignee Groups and Assignee Groups fields on HPD:Help Desk to the Permission Group ID field on CTM:SYS-Access Permission Grps where the Support Group ID field on HPD:Help Desk matches the Assigned Group ID field from CTM:SYS-Access Permission. 4) Create a filter that executes upon modify when the database version of the Confidential flag was checked, and the transactional version is unchecked. a. This does a Set Fields from CTM:SYS-Access Permission Grps which sets the Vendor Assignee Groups field to Permission Group ID where the Assigned Support Company = Navigation Menu01. b. It Sets the ReadOnlyGroup field back to ;-10;. c. It also does a Set Fields from CTM:SYS-Access Permission Grps which sets the Assignee Groups field to Permission Group ID where the (Customer's) Company = Navigation Menu01. Unfortunately, I've broken a few things, so I may have to change how this works to get it working right. One of these things has resulted in the Assigned Group*+ and Assignee+ fields not working for normal users anymore, not just on confidential Incidents but in general. It also looks like it's broken some of the Active Links that handle normal security. I'm hoping these are easy to resolve, but it's too soon to say and I'll probably stop working on it for the day. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Tuesday, March 11, 2014 10:42 AM To: arslist@ARSLIST.ORG Subject: RE: Row-Level Security on HPD:Help Desk I wanted to give a quick update on this. I'm currently testing it. I created a field I called ReadOnlyGroups with Field ID 60710 and set the default of that field to be ;-10; so it will pick up the Unrestricted Access group by default. I also created a radio button called Confidential that when checked will clear out the ReadOnlyGroups field. However, upon further investigation, it looks like the Customer's company group id goes into Assignee Groups (112) and the Support Group Company group id goes into Vendor Assignee Groups (60900). As a result, they are still visible to people in those organizations, which unfortunately is too many. If I clear those two fields out as well, then nobody other than administrators can see it. That surprised me a bit because I would have thought the Assignee Groups field would have been used to actually track assignee groups. I'm not really able to see where the specific group is being tracked in such a way that would be used to drive permissions. For example, the Assigned Group ID and the Owner Group ID fields are there, but storing the Entry ID field rather than the group id. As a result, it looks like they aren't using Group security for actually securing the Incidents. My next step is to create a ReadWriteGroups field with a Field ID of 60715 that I can then move the General Access role to by defaulting it to ;-2;, remove that role from having access to the Entry ID and add the ReadWriteGroups dynamic group to that and see if that makes a difference. At that point, I can also see about adding the actual groups tied to the Support Groups to this field as a part of my workflow. I also need to investigate some workflow that is broken by doing this. Specifically, the active links to make the record read only and display the warning on the banner instead of the process flow bar aren't working. However, users that don't have write access still can't get to the record. Does anyone know of anything else I should look at, specifically any other fields on HPD:Help Desk that might need to be taken into consideration so I can ensure that the Assigned Group are the only ones (other than Remedy admins) who have access to the Incident? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only
Re: Row-Level Security on HPD:Help Desk
The filter would be a good idea but in our situation we are using BMC Analytics for reporting, which goes directly against the database via a SQL driver rather than through the Remedy ODBC driver. It also has what Business Objects calls a derived table for permissions that I may need to modify for this stuff to work as well, but I'll leave that to the reporting team to figure out. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential
Re: Row-Level Security on HPD:Help Desk
Multi-tenancy isn’t really designed in such a way that it could be used for this because we had to basically give everyone “Unrestricted Access”. Unfortunately, multi-tenancy is pretty useless if you’re using SRM unless you’re a big fan of creating duplicates of every single thing that is shared between different companies (I have no idea why BMC doesn’t allow you to use “- Global -“ in SRM.) Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: patchsk [mailto:vamsi...@gmail.com] Sent: Friday, March 07, 2014 11:57 PM To: arsl...@googlegroups.com Cc: arslist@ARSLIST.ORG; arslist@ARSLIST.ORG; Pierson, Shawn Subject: Re: Row-Level Security on HPD:Help Desk Multitenancy is for security in a shared environment between different companies or different business units with in the same company. You might want to check if you can use this feature if your ITSM env is multitenant enabled? Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
That’s a pretty good idea. I had two others that I could do as a “last resort” if for some reason setting the row-level security didn’t work the way I expect. One is to create a field that only the assigned group has access to called “Confidential Notes” or something like that, but your idea seems cleaner. The other one, which would be cool to work on but isn’t necessarily something that would be quickly implemented would be to add a flag that could encrypt all the data on the Incident via a run process on a Filter when they save the record, and on display a similar run process Active Link would decrypt it. That would be fun to build, but not necessarily quick enough. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Roney Samuel Varghese. Sent: Sunday, March 09, 2014 8:01 AM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** Shawn, We had a similar requirement, the only difference being the confidentiality was supposed to be in the worklog instead of the Help Desk form. We repurposed the view option on the Helpdesk form and added a third option of confidential to public and locked options while configuring row level access on the HPD:Worklog form. Regards, Roney Samuel Varghese Sent from my iPhone On Mar 7, 2014, at 11:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I’ve come up with a plan but it’s a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I’m going to remove the “Unrestricted Access” Role from the Request ID field on HPD:Help Desk. - Then I’ll create a custom field to take its place, let’s say 60701, which I will create a Dynamic Group for that I can have the “Unrestricted Access” Role be put into as a default. - I’ll add a Radio button called “Confidential” on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I’ll set 60701 to the “Unrestricted Access” Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I’m working on something that has been discussed by others here but I’m having trouble conceptualizing how I can do this. The user’s requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I’m debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I’m struggling to come up with a good way to lock things down. Also, using multi-tenancy isn’t an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we’ll have to be very careful to ensure these don’t show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed herehttp://www.energytransfer.com/mail_disclaimer.aspx. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender
Re: Row-Level Security on HPD:Help Desk
Shawn, We had a similar requirement, the only difference being the confidentiality was supposed to be in the worklog instead of the Help Desk form. We repurposed the view option on the Helpdesk form and added a third option of confidential to public and locked options while configuring row level access on the HPD:Worklog form. Regards, Roney Samuel Varghese Sent from my iPhone On Mar 7, 2014, at 11:22 AM, Pierson, Shawn shawn.pier...@energytransfer.com wrote: ** I think I’ve come up with a plan but it’s a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I’m going to remove the “Unrestricted Access” Role from the Request ID field on HPD:Help Desk. - Then I’ll create a custom field to take its place, let’s say 60701, which I will create a Dynamic Group for that I can have the “Unrestricted Access” Role be put into as a default. - I’ll add a Radio button called “Confidential” on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I’ll set 60701 to the “Unrestricted Access” Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I’m working on something that has been discussed by others here but I’m having trouble conceptualizing how I can do this. The user’s requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I’m debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I’m struggling to come up with a good way to lock things down. Also, using multi-tenancy isn’t an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we’ll have to be very careful to ensure these don’t show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Row-Level Security on HPD:Help Desk
Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, *Shawn Pierson * Remedy Developer | Energy Transfer *From:* Pierson, Shawn *Sent:* Friday, March 07, 2014 9:30 AM *To:* arslist@ARSLIST.ORG *Subject:* Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, *Shawn Pierson * Remedy Developer | Energy Transfer Private and confidential as detailed herehttp://www.energytransfer.com/mail_disclaimer.aspx. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
Multitenancy is for security in a shared environment between different companies or different business units with in the same company. You might want to check if you can use this feature if your ITSM env is multitenant enabled? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row Level Security
-- Sent from my BlackBerry Wireless Handheld - Original Message - From: Vikram [vkulka...@columnit.com] Sent: 08/26/2011 10:49 AM AST To: arslist@ARSLIST.ORG Subject: Re: Row Level Security What if we dont have any ITSM solution implemented and have home grown system for Customer support and ticketing? in that case we wont have any company created and hence no group for that company.. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Row Level Security
-- Sent from my BlackBerry Wireless Handheld - Original Message - From: White, Michael W (Mike) [michael.wh...@verizon.com] Sent: 08/26/2011 11:15 AM AST To: arslist@ARSLIST.ORG Subject: Re: Row Level Security Row-level security can be applied a number of ways. Assignee Group (Field 112) is common and easy. Add it to your form and populate it with the group(s) that you want to grant whatever access to. You'll obviously want to implement workflow to manage it - set it for new records, reset it on behalf of changes, whatever. Field ID 1 (Request ID) controls record access itself. Set Assignee Group View or Change to it. The target group will have the intended access on a per-row-basis. Dynamic groups are another way. They provide much more granular control. Create groups with ids 6 and higher. In your form, you add fields with the same ids. In your field permissions, such as Field ID 1, you assign the intended permission to whichever group name you used to provide the permission. This supports both groups and users (delimited with single quote). Also supports multiple fields/groups (many of them could introduce a performance issue based on total number of groups, number of fields in a form, etc.). Best to read-up on them in Remedy documentation. Mike White EMail michael.wh...@verizon.com Office 813.978.2192 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Vikram Sent: Friday, August 26, 2011 10:49 AM To: arslist@ARSLIST.ORG Subject: Re: Row Level Security What if we dont have any ITSM solution implemented and have home grown system for Customer support and ticketing? in that case we wont have any company created and hence no group for that company.. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Row Level Security
What if we dont have any ITSM solution implemented and have home grown system for Customer support and ticketing? in that case we wont have any company created and hence no group for that company.. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Row Level Security
Row-level security can be applied a number of ways. Assignee Group (Field 112) is common and easy. Add it to your form and populate it with the group(s) that you want to grant whatever access to. You'll obviously want to implement workflow to manage it - set it for new records, reset it on behalf of changes, whatever. Field ID 1 (Request ID) controls record access itself. Set Assignee Group View or Change to it. The target group will have the intended access on a per-row-basis. Dynamic groups are another way. They provide much more granular control. Create groups with ids 6 and higher. In your form, you add fields with the same ids. In your field permissions, such as Field ID 1, you assign the intended permission to whichever group name you used to provide the permission. This supports both groups and users (delimited with single quote). Also supports multiple fields/groups (many of them could introduce a performance issue based on total number of groups, number of fields in a form, etc.). Best to read-up on them in Remedy documentation. Mike White EMail michael.wh...@verizon.com Office 813.978.2192 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Vikram Sent: Friday, August 26, 2011 10:49 AM To: arslist@ARSLIST.ORG Subject: Re: Row Level Security What if we dont have any ITSM solution implemented and have home grown system for Customer support and ticketing? in that case we wont have any company created and hence no group for that company.. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Row Level Security
Does anyone have a good write up on how to implement row level security. You used to be able to implement without having to create records for customers in user, group or role form (using implicit Assignee Group). According to the doc for 7.x you need to put either user name, group or role in field 112. I don't want to enter our customers in user or group table, instead I want to use company or contract as the implicit assignee group. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: Row Level Security
You can use the company - when a company is created it creates a group for it. Search on the long name of the group for the company name to get the group ID. This is what will be appended to field 112 if want company row level security. Use Public if you want to open it to everyone. Regards, Andrew Goodall Software Engineer 2 | Development Services | jcpenney . www.jcp.com -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Deborah Darrah Sent: Thursday, August 25, 2011 12:25 PM To: arslist@ARSLIST.ORG Subject: Row Level Security Does anyone have a good write up on how to implement row level security. You used to be able to implement without having to create records for customers in user, group or role form (using implicit Assignee Group). According to the doc for 7.x you need to put either user name, group or role in field 112. I don't want to enter our customers in user or group table, instead I want to use company or contract as the implicit assignee group. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient, you are hereby notified that your access is unauthorized, and any review, dissemination, distribution or copying of this message including any attachments is strictly prohibited. If you are not the intended recipient, please contact the sender and delete the material from any computer. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: Where the Answers Are
Re: CMDB Performance - Updating Row Level Security
Thanks Ramy, I have checked all the logs and have run filter, api and sql logs many times. There is no loop, just the issue with the second CMDB filter trying to update the child CI. I have copied a small part of a filter log below to show the issue more clearly. Cheers Peter /* Fri Mar 27 2009 17:12:22.2430 */ Checking INT:ASIFND:ACT:UPDATEGROUPLIST_105_ASTRel 0: Push Fields - BMC.CORE:BMC_BaseRelationship deferred from filter INT:ASIFND:ACT:UPDATEGROUPLIST_105_ASTRel z1D_Action (100076) = CIUPDATEGROUPLIST /* Fri Mar 27 2009 17:12:22.2580 */ Start filter processing (phase 1) -- Operation - SET on BMC.CORE:BMC_BaseRelationship - 3496543 /* Fri Mar 27 2009 17:12:22.2580 */ Checking CMDB:Instance:REEscapeToCompareFilters (0) -- Failed qualification /* Fri Mar 27 2009 17:12:22.2580 */ Checking CMDB:Instance:InvokeCMDBEngine01 (100) -- Passed -- perform actions 0: Set Fields +WFGS ARIWfGetSchema -- schema BMC.CORE:BMC_BaseRelationship -WFGS OK +WFGLSF ARIWfGetListField -- schema BMC.CORE:BMC_BaseRelationship -WFGLSFOK +WFGE ARIWfGetEntry -- schema BMC.CORE:BMC_BaseRelationship -WFGE OK +WFSCE ARIWfSetCurrEntry -WFSCE OK +WFSCE ARIWfSetCurrEntry -WFSCE OK +WFSCE ARIWfSetCurrEntry -WFSCE OK +WFSCE ARIWfSetCurrEntry -WFSCE OK Application-Invoke-External-Filter bmc.cmdb.cmdbEngine PHASE=1 CLIENTTYPE=3 Exit code: 0 Value: zCMDBEngInvokeResult (530031900) = /* Fri Mar 27 2009 17:12:22.2890 */ Checking ASI:CDM_SetData_500 (500) -- Disabled -- filter is ignored /* Fri Mar 27 2009 17:12:22.2890 */ Checking ASI:CDM_UpdateGroupList-AsgGroupCI_550 (550) -- Passed -- perform actions 0: Set Fields CMDBRowLevelSecurity (112) = 10; /* Fri Mar 27 2009 17:12:22.3520 */ Checking CMDB:Instance:InvokeCMDBEngine02 (600) -- Passed -- perform actions 0: Set Fields +WFGE ARIWfGetEntry -- schema BMC.CORE:BMC_BaseRelationship -WFGE OK +WFGLEWF ARIWfGetListEntryWithFields -- schema BMC.CORE:BMC_ProtocolEndpoint -WFGLEWFOK +WFGLEWF ARIWfGetListEntryWithFields -- schema BMC.CORE:BMC_ComputerSystem -WFGLEWFOK +WFSE ARIWfSetEntry -- schema BMC.CORE:BMC_ProtocolEndpoint /* Fri Mar 27 2009 17:12:22.3990 */ Start filter processing (phase 1) -- Operation - SET on BMC.CORE:BMC_ProtocolEndpoint - 0043961|3587241 /* Fri Mar 27 2009 17:12:22.3990 */ Checking CMDB:Instance:REEscapeToCompareFilters (0) -- Failed qualification _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ramy S. Ayoub Sent: 30 March 2009 20:54 To: arslist@ARSLIST.ORG Subject: Re: CMDB Performance - Updating Row Level Security ** ** did you checked the AR Error log it seems there infinity loop start when the action also start , you can refer to ar.montor and ar,cfg configuration .. a lot of fact can cause this issue Regards, Ramy Ayoub On Mon, Mar 30, 2009 at 2:17 PM, Peter Romain p.romain.arsl...@parsolutions.co.uk wrote: Hi All, On my system Marimba has imported ~4500 computers each with ~200 related CIs. When I add a Company value to a computer system CI the CMDBRowLevelSecurity is correctly pushed to all relationships (via the SYS:Action form). The problem I am seeing is that when the relationship CMDBRowLevelSecurity is updated the CMDB filter at order 600 performs a set fields on the child CI of the relationship instead of the underscore form of the relationship (eg BMC.CORE:BMC_Component_). This is causing a performance hit as we try and add companies. I have played with the security and markasdeleted fields on parent and chld CIs as well as the relationship CI but I can't figure out why this is happening. Has anyone else seen this and found the reason for the child CI being updated during an update of a relationship? Cheers Peter Win 2003 ARS 7.1 Patch 6 CMDB 2.1 Patch 5 SQL Server 2005 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org http://www.arslist.org/ Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are __Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
CMDB Performance - Updating Row Level Security
Hi All, On my system Marimba has imported ~4500 computers each with ~200 related CIs. When I add a Company value to a computer system CI the CMDBRowLevelSecurity is correctly pushed to all relationships (via the SYS:Action form). The problem I am seeing is that when the relationship CMDBRowLevelSecurity is updated the CMDB filter at order 600 performs a set fields on the child CI of the relationship instead of the underscore form of the relationship (eg BMC.CORE:BMC_Component_). This is causing a performance hit as we try and add companies. I have played with the security and markasdeleted fields on parent and chld CIs as well as the relationship CI but I can't figure out why this is happening. Has anyone else seen this and found the reason for the child CI being updated during an update of a relationship? Cheers Peter Win 2003 ARS 7.1 Patch 6 CMDB 2.1 Patch 5 SQL Server 2005 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
Re: CMDB Performance - Updating Row Level Security
** did you checked the AR Error log it seems there infinity loop start when the action also start , you can refer to ar.montor and ar,cfg configuration .. a lot of fact can cause this issue Regards, Ramy Ayoub On Mon, Mar 30, 2009 at 2:17 PM, Peter Romain p.romain.arsl...@parsolutions.co.uk wrote: Hi All, On my system Marimba has imported ~4500 computers each with ~200 related CIs. When I add a Company value to a computer system CI the CMDBRowLevelSecurity is correctly pushed to all relationships (via the SYS:Action form). The problem I am seeing is that when the relationship CMDBRowLevelSecurity is updated the CMDB filter at order 600 performs a set fields on the child CI of the relationship instead of the underscore form of the relationship (eg BMC.CORE:BMC_Component_). This is causing a performance hit as we try and add companies. I have played with the security and markasdeleted fields on parent and chld CIs as well as the relationship CI but I can't figure out why this is happening. Has anyone else seen this and found the reason for the child CI being updated during an update of a relationship? Cheers Peter Win 2003 ARS 7.1 Patch 6 CMDB 2.1 Patch 5 SQL Server 2005 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: Where the Answers Are
