Showing posts with label Responsibilities. Show all posts
Showing posts with label Responsibilities. Show all posts
Friday, August 1, 2014
Weekend Learning: Creating EBS role to query users and reset password
Sure we have the power with System Administrator to query users and reset the FND_USER password, but what if you do not want everybody to have the rest of the System Administrator access in order to complete this task? Well, if that is the case then this weekend you will want to read the MOS article "How To Create a Role That Can Query Users and Reset Passwords" from document ID 743683.1 so you can create a UMX role and then assign it to a new role and responsibility.
Thursday, February 6, 2014
The dangers of hard coding
We have all been there. Something gets hard coded when it does not need to be, or when it does not make a whole lot of sense, and it makes your life a lot more difficult than it should be. Today was one of those times for us!
We had a responsibility created to serve business needs, but they later wanted to segregate duties and when they did we found out that the upload report designed had the responsibility_id hard coded into the report which made it impossible to run out of another responsibility. Great idea, bad execution because we were not given a way to make it dynamic with profile options or some such plan.
So the business decided to go forward with the new segregation of duties responsibility anyways, but let an administrative account have both responsibilities which was tightly controlled. No problem right? Until a new manager came along, did an audit of the responsibilities, and removed the responsibility that was needed to run the upload report from the segregated duties responsibility. Oops.
The lesson here is that if you need to hard code something, do it in such a way that it is soft coded. Make updates possible so down the road when a parameter, e-mail address, or responsibility_id in our case have to change the people that follow you can do it without having to take your name in vain while they re-code your work. Even better? Allow a framework so changes can be centralized and manipulated easily without messy table level updates!
We had a responsibility created to serve business needs, but they later wanted to segregate duties and when they did we found out that the upload report designed had the responsibility_id hard coded into the report which made it impossible to run out of another responsibility. Great idea, bad execution because we were not given a way to make it dynamic with profile options or some such plan.
So the business decided to go forward with the new segregation of duties responsibility anyways, but let an administrative account have both responsibilities which was tightly controlled. No problem right? Until a new manager came along, did an audit of the responsibilities, and removed the responsibility that was needed to run the upload report from the segregated duties responsibility. Oops.
The lesson here is that if you need to hard code something, do it in such a way that it is soft coded. Make updates possible so down the road when a parameter, e-mail address, or responsibility_id in our case have to change the people that follow you can do it without having to take your name in vain while they re-code your work. Even better? Allow a framework so changes can be centralized and manipulated easily without messy table level updates!
Wednesday, August 21, 2013
(M)obile responsibilities
When users were assigned responsibilities and they did not show up in the Navigator or "pick list" within the Financials application, it was a strange phenomenon which took some investigating to figure out. We have had some experience with several tables getting out of sync with what the assigned responsibility tables show, but a quick glance at these problem tables told us that we were okay from that aspect so I was quickly running out of ideas. I even went to the end users to make sure the responsibility wasn't showing up, and sure enough it wasn't there. I mentioned this to a co-worker to bounce ideas off of and he reminded me that we had some problems a year or two back with a report or responsibility not showing the right information because they had some table level details mixed up. Thinking it was worth a shot, I then looked at the FND_RESPONSIBILITY_VL table for the problem child in question and was puzzled by the fact that in the VERSION column there was an 'M'.
Versions for most things are numbers and when I compared it against other responsibilities they had the number '4' listed, so I looked at the form and couldn't see anything out of the ordinary. Back to the table to run a query looking for other items marked with an M and I found several other responsibilities listed with almost all of them having "Field" or "Mobile" in the name of the responsibility, which did not seem to make sense because this responsibility wasn't part of some Field or Mobile installation of Oracle Apps. Well back to the form I go and there is the answer staring me straight in the face this time: there is an option to pick what responsibilities are "Available From." At some point an individual accidentally picked Oracle Mobile Applications when they were trying to make another change (likely a menu change since this is right above the Menu entry field) and didn't notice the radio box selection change when they miss-clicked so they saved this bad change with the changes they were planning on making. After changing the radio box selection back to Oracle Applications, life was good as the users could once again access the responsibility.
Versions for most things are numbers and when I compared it against other responsibilities they had the number '4' listed, so I looked at the form and couldn't see anything out of the ordinary. Back to the table to run a query looking for other items marked with an M and I found several other responsibilities listed with almost all of them having "Field" or "Mobile" in the name of the responsibility, which did not seem to make sense because this responsibility wasn't part of some Field or Mobile installation of Oracle Apps. Well back to the form I go and there is the answer staring me straight in the face this time: there is an option to pick what responsibilities are "Available From." At some point an individual accidentally picked Oracle Mobile Applications when they were trying to make another change (likely a menu change since this is right above the Menu entry field) and didn't notice the radio box selection change when they miss-clicked so they saved this bad change with the changes they were planning on making. After changing the radio box selection back to Oracle Applications, life was good as the users could once again access the responsibility.
Subscribe to:
Posts (Atom)