The first one was created before there were any diagnostic questions input into the application and therefore are "uncategorised". The latest one was one I raised using the questions into a category of "DCME".
On both of these when I view the ticket I can see all the information and change things like who it is assigned to and the priority. When I try to edit the category I have problems. If I am looking at the uncategorised one then all the other category options are present but when i slect them and then push update the screen refreshes exactly how it was with no change to the category I just edited.
When I use the DCME one I only have the option of DCME or the Uncategorised option. When I again select Uncategorised and then update the task won't register a change in category.
Not sure why this is happening. Does this function rely on other information being present in the database to operate correctly?
Also if I want to change my DCME task's category why aren't all of the available categories listed?
Best Regards
David Price
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The change of category is done in f2w/operator/request/upd_r_redefine. Try the Test tab of upd_r_redefine, and see if you can change the category OK that way, and if it gives you errors.
It does three things:
1) change the category of the request r_cat
2) add any properties to the request that belong to the new category.
3) delete any properties from the request that do not belong to the new category and contain no information.
If any of those goes wrong, the transaction might be undone. I'm just guessing though.
The feature (or misfeature) of not seeing all the categories in the list was intentional. At first I thought it would be helpful to see only related categories. Now I think that's probably obstructive rather than helpful most of the time. I may remove it in the next release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just tested it with the results below. Basically it works from the upd_r_redefine object but not when I am in the application.
Does this work for you or am I the only one having problems with this. I look at /f2w-1.2.3/operator/request/detail and can see that there is a r_req that I presume gets passed via the namespace when the upd_r_redefine is called. I can't see where r_cat is passed or that it is in the namespace at that point in time when the update button is pushed. I can see old_cat and new_cat but no r_cat. Is this how the mechanism works or am I on the worng track?
Results from running upd_r_redefine from management interface.
+++++++++++++++++++++++++++++
This statement returned no results.
SQL used:
insert into reqprop
(rp_req,rp_cat,rp_prop,rp_value)
select
7, 'SDH',
cp_prop, ''
from catprop where
cp_cat = 'SDH' and
cp_prop not in
(
select rp_prop from reqprop where
rp_req = 7 and
rp_cat = 'SDH' )
It works OK for me, but the code is a crufty mess, and I can well believe there's some subtle bug that makes it fail under conditions I haven't thought of.
One thing you could try is putting <!--BEFORE--> and <!--AFTER--> around the <dtml-call upd_r_redefine>, and see if they appear in the HTML of the page when you try to change the category.If the SQL works in isolation, perhaps it is not being called for some reason?
Or maybe use
<!--BEFORE r_cat=<dtml-var r_cat> ... -->
to check the namespace contains the values you expect.
I *really* need to tidy this up. So thanks for drawing my attention to it, even though it's a little embarassing!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a couple of tickets open.
The first one was created before there were any diagnostic questions input into the application and therefore are "uncategorised". The latest one was one I raised using the questions into a category of "DCME".
On both of these when I view the ticket I can see all the information and change things like who it is assigned to and the priority. When I try to edit the category I have problems. If I am looking at the uncategorised one then all the other category options are present but when i slect them and then push update the screen refreshes exactly how it was with no change to the category I just edited.
When I use the DCME one I only have the option of DCME or the Uncategorised option. When I again select Uncategorised and then update the task won't register a change in category.
Not sure why this is happening. Does this function rely on other information being present in the database to operate correctly?
Also if I want to change my DCME task's category why aren't all of the available categories listed?
Best Regards
David Price
That's one I haven't seen before.
The change of category is done in f2w/operator/request/upd_r_redefine. Try the Test tab of upd_r_redefine, and see if you can change the category OK that way, and if it gives you errors.
It does three things:
1) change the category of the request r_cat
2) add any properties to the request that belong to the new category.
3) delete any properties from the request that do not belong to the new category and contain no information.
If any of those goes wrong, the transaction might be undone. I'm just guessing though.
The feature (or misfeature) of not seeing all the categories in the list was intentional. At first I thought it would be helpful to see only related categories. Now I think that's probably obstructive rather than helpful most of the time. I may remove it in the next release.
I have just tested it with the results below. Basically it works from the upd_r_redefine object but not when I am in the application.
Does this work for you or am I the only one having problems with this. I look at /f2w-1.2.3/operator/request/detail and can see that there is a r_req that I presume gets passed via the namespace when the upd_r_redefine is called. I can't see where r_cat is passed or that it is in the namespace at that point in time when the update button is pushed. I can see old_cat and new_cat but no r_cat. Is this how the mechanism works or am I on the worng track?
Results from running upd_r_redefine from management interface.
+++++++++++++++++++++++++++++
This statement returned no results.
SQL used:
update request set r_cat = 'SDH'
where r_req = 7
------------------------------------------------------------
insert into reqprop
(rp_req,rp_cat,rp_prop,rp_value)
select
7, 'SDH',
cp_prop, ''
from catprop where
cp_cat = 'SDH' and
cp_prop not in
(
select rp_prop from reqprop where
rp_req = 7 and
rp_cat = 'SDH' )
------------------------------------------------------------
delete from reqprop where
rp_req = 7 and
rp_cat <> 'SDH' and
rp_value = ''
It works OK for me, but the code is a crufty mess, and I can well believe there's some subtle bug that makes it fail under conditions I haven't thought of.
One thing you could try is putting <!--BEFORE--> and <!--AFTER--> around the <dtml-call upd_r_redefine>, and see if they appear in the HTML of the page when you try to change the category.If the SQL works in isolation, perhaps it is not being called for some reason?
Or maybe use
<!--BEFORE r_cat=<dtml-var r_cat> ... -->
to check the namespace contains the values you expect.
I *really* need to tidy this up. So thanks for drawing my attention to it, even though it's a little embarassing!
Hi
I forgot to ask: does 1.2.5 cope with changing the category of a request?
Or do the other problems make it impossible to tell?