KIS plugin additional ticket keywords exposed to KIS assistant expressions

[solstice333]

Also, maybe I should open a new ticket for this, but I also wanted to do something like

foo.visible = authname == owner

where owner is replaced with the owner of the ticket. In kis.py, I did

    def post_process_request(self, req, template, data, content_type):
        ...

            if 'id' in req.args:
                ticket_id = req.args['id'].lstrip('#')
                ticket = Ticket(self.env, ticket_id)
                status = ticket.get_value_or_default('status')
                owner =  ticket.get_value_or_default('owner')
            else:
                ticket_id = ''
                status = ''
                owner = ''

            page_data = { 'trac_ini' : config,
                          'status'   : status,
                          'owner'    : owner,
                          'id'       : ticket_id,
                          'authname' : req.authname }

Then in kis.js, in term()'s promise executor,

    function term() { return new Promise(function (resolve, reject) {
        ...
        if (token == 'owner') {
            result.value = page_info['owner'];
            next_token();
        } else

Might be useful to expose all the column names in the ticket schema to page_info?

[Jon Ashley]

In 17197:

Look in the ticket header for the value of a field that can't be found in the change properties area. I think this only applies to 'owner'. See #13436.

[Jon Ashley]

In [17197], I have tried a slightly different solution for getting 'owner' as I found that passing in the result of ticket.get_value_or_default('owner') gives the wrong owner when viewing a preview when the pending change to the ticket will change the owner: it resolves to the current owner rather than the new owner. Also, this keeps it a little more integrated; you could always control the visibility of the 'owner' field with the kis plugin, just not read its value until now.

status presumably suffers from the same issue; I'll look at that later.

This works on Trac 1.0.9; I haven't tried it on Trac 1.2 or later yet.

[Jon Ashley]

It does work on Trac 1.2.2.

status does always evaluate to the "real" current status of the ticket, rather than the status in the preview. However, the transition from one state to the next tends to be a key trigger for hiding a lot of fields from the interface and making a lot of different ones visible. Generally you don't want this to happen while still previewing the change. status is a special token not a field name, so I think the existing behaviour is justifiable.

I had a look at which other columns were in the ticket schema. The only ones I saw that don't get passed to 'page_info' (and aren't available as ticket fields) were time and changetime. Also id, while passed, is not available for use in configuration rules. Did you have anything else in mind?

[solstice333]

Replying to Jon Ashley:

In [17197], I have tried a slightly different solution for getting 'owner' as I found that passing in the result of ticket.get_value_or_default('owner') gives the wrong owner when viewing a preview when the pending change to the ticket will change the owner: it resolves to the current owner rather than the new owner. Also, this keeps it a little more integrated; you could always control the visibility of the 'owner' field with the kis plugin, just not read its value until now.

status presumably suffers from the same issue; I'll look at that later.

This works on Trac 1.0.9; I haven't tried it on Trac 1.2 or later yet.

What I was trying to achieve was for the current owner of the ticket to be able to view and modify almost all ticket properties, but for anybody else (excluding the admin who can view and control everything), I wanted them to only view and modify the cc checkbox. I think what you mentioned about the current owner resolving as the owner, as opposed to the new owner resolving as the owner, works for my specific case.

[solstice333]

Replying to Jon Ashley:

It does work on Trac 1.2.2.

status does always evaluate to the "real" current status of the ticket, rather than the status in the preview. However, the transition from one state to the next tends to be a key trigger for hiding a lot of fields from the interface and making a lot of different ones visible. Generally you don't want this to happen while still previewing the change. status is a special token not a field name, so I think the existing behaviour is justifiable.

I had a look at which other columns were in the ticket schema. The only ones I saw that don't get passed to 'page_info' (and aren't available as ticket fields) were time and changetime. Also id, while passed, is not available for use in configuration rules. Did you have anything else in mind?

So right now I have it so the current owner of a ticket can view/modify almost all the ticket properties. I tried clicking an action radio button that previews a state transition to where the current owner disowns the ticket. The result is that the fields shown on the view stay fixed and don't disappear. To me, this is the right behavior since the current owner still has full control of the ticket.

I'm OK with passing time and changetime to 'page_info'. Here's the schema of the ticket:

sqlite> .schema ticket
CREATE TABLE ticket (
    id integer PRIMARY KEY,
    type text,
    time integer,
    changetime integer,
    component text,
    severity text,
    priority text,
    owner text,
    reporter text,
    cc text,
    version text,
    milestone text,
    status text,
    resolution text,
    summary text,
    description text,
    keywords text
);

I'm thinking any column with text affinity is viable? Probably the ones presumed to not have any newlines in them? It'd be pretty cool to pass any of those to a user defined function, parse it however you'd like, then eval it in a larger expression. Although, if it becomes too much work, I'm actually fine with exposing the simple text fields like owner and reporter that are less likely to have whitespace in them.

Thanks for the hard work BTW. I'm certainly finding the plugin very useful.

[Jon Ashley]

Replying to solstice333:

What I was trying to achieve was for the current owner of the ticket to be able to view and modify almost all ticket properties, but for anybody else (excluding the admin who can view and control everything), I wanted them to only view and modify the cc checkbox. I think what you mentioned about the current owner resolving as the owner, as opposed to the new owner resolving as the owner, works for my specific case.

...

So right now I have it so the current owner of a ticket can view/modify almost all the ticket properties. I tried clicking an action radio button that previews a state transition to where the current owner disowns the ticket. The result is that the fields shown on the view stay fixed and don't disappear. To me, this is the right behavior since the current owner still has full control of the ticket.

I think you should be able to get this simply by referring to _owner in your rules rather than owner. I'd prefer to make it so that 'owner' matches the preview so as to be consistent with the behaviour of the other fields. 'owner' is still bit of a special case of course, as it isn't really a ticket field and only ever appears in the ticket header, never in the Change Properties box.

I'm OK with passing time and changetime to 'page_info'. Here's the schema of the ticket:

sqlite> .schema ticket
CREATE TABLE ticket (
    id integer PRIMARY KEY,
    type text,
    time integer,
    changetime integer,
    component text,
    severity text,
    priority text,
    owner text,
    reporter text,
    cc text,
    version text,
    milestone text,
    status text,
    resolution text,
    summary text,
    description text,
    keywords text
);

I'm thinking any column with text affinity is viable? Probably the ones presumed to not have any newlines in them? It'd be pretty cool to pass any of those to a user defined function, parse it however you'd like, then eval it in a larger expression. Although, if it becomes too much work, I'm actually fine with exposing the simple text fields like owner and reporter that are less likely to have whitespace in them.

This should work right now for all those text fields. For example, you can have a rule like myfield.visible = myfunction(cc, reporter) == milestone and myfunction() will be called with the value of the cc field as the third parameter (after 'self' and 'req') and the value of the reporter field as the fourth parameter. The return value of myfunction(), presumably a string, will be compared to the current value of the ticket milestone.

I'm pleased to hear that you are finding the plugin useful. I appreciate getting useful fault reports and suggestions for improvements. I have no idea how many people are using this plugin, so it's always good to get some input.