Tutorial: Issue Tracker, Problem with Authorization

Question

Hi All,
I just worked through the Issue Trackin System Tutorial, everything looks great except the Authorization. I did the Tutorial on our local Instance of HTMLDB so I had to modify the Authorization Schemes a little. People should login using their internal HTMLDB-Account, which uses an extra loginname, not the email adress. So i added a column PERSON_LOGIN to the ht_people table which holds the userID. My Authorizationscheme looks like this:
select '1' from ht_people where
(upper(PERSON_LOGIN) = upper(:APP_USER) and
PERSON_ROLE in ('Lead','Member') and
ASSIGNED_PROJECT = :P7_RELATED_PROJECT)
or (:APP_USER = 'HOWTO')
or (:P7_ISSUE_ID is null)
This Scheme simply does not work, the user does not get the authorization to edit the issues assigned to him. I can´t see the problem, if I do this query I get the expected column back. If I log in to the Application and try to edit the issues, I don´t get the neccesary authorization. Any Ides ?

Answer 1

From Scott -
I installed that demo app on our hosted site. I don't see anything structurally wrong with page 0 breadcrumbs. When you edit page 0, do you see the correct menu region, or is there a big number where its name should be? If you find something that you cannot repair, please let us know.
As for the authorization schemes, I see what's going on. The scheme controls the display of buttons and a region on page 7 and is evaluated during the rendering of the region and the buttons. These events take place before the item P7_RELATED_PROJECT is rendered, thus before its session state is established or altered during that page view. However the implementation of the authorization scheme references the current session state of that item. That won't work. Using standard conditions (vs. authorization schemes) to control the buttons/regions that are earlier on the page than the referenced item would have the same problem if they used the same logic. For situations like this, LOVs that submit the page and result in a branch back to the same page can be very useful, or splitting the page into multiple pages, as in wizard implementations, can also work.
From Sharon -
I want to thank you for pointing out this bug. This is our first tutorial document and a lot of time was spent making sure that users could follow the directions and learn how to create all the objects that make up an application. Obviously, not enough time was spent testing the resultant application. The statement below should work for the Authorization Scheme in question.
select '1'
from ht_people
where (person_email = :APP_USER and
person_role in ('Lead','Member') and
assigned_project = (select related_project
from ht_issues
where issue_id = :P7_ISSUE_ID))
or (:APP_USER = 'HOWTO')
or (:P7_ISSUE_ID is null)
You will notice that is allows the modification of the issue by either the Lead or any Member of the project, not just the one assigned. When I update the document and repost on OTN, I will make a note of that.
This checks that the current value of related project is the project that the Member or Lead is assigned to. It is true that while viewing the page, the user can change the related project. Once the change is applied, they would no longer be able to edit that issue.