Enhancement to allow permissions on form fields

[David.Byrne@…]

I have certain forms that I would like to embed in either milestones or tickets that can only be updated by specific users. I've installed both WikiFormsPlugin and AccessMacro (I've also looked at ProtectedMacro). If I put the WikiFormsPlugin within the AccessMacro like:

    {{{
    #!access
    #allow(SOME_PERMISSION)

    {{{
    #!WikiForms

    ...  FORM CODE HERE
    }}}

    }}}

    {{{
    #!access
    #deny(SOME_PERMISSION)

    {{{
    #!WikiForms

    ...  ALTERNATE FORM HERE WITH UPDATE ELEMENTS REPLACE BY VALUES
    }}}

    }}}

I get the form to work correctly. One problem is that if I don't have the alternate form part, then I'm getting the wiki code instead. Another problem with this approach is that I have to create a totally different form for each type of permission I want. So if I have a form with three different combinations, I have write the form three times.

The alternate method is to embed the AccessMacro within WikiFormsPlugin. This works, but the problem is that the lines of the form do not line up. Each line is treated like it is a different form -- there is no space between the lines, but the columns do not line up.

It would be nice if WikiFormsPlugin could be enhanced to allow tests to dictate how the fields are displayed. This could be either permissions (like AccessMacro uses) or other tests such as Ticket status, Ticket Type, Milestone status, etc. I understand the forms that are created outside of a ticket or milestone wouldn't have an easy way to identify that information when included into a ticket or milestone. I'm just brainstorming here.

[David.Byrne@…]

I just looked a little closer to how WikiForms works. I'm probably not going to be able to use it like I was thinking. It should work fine for one of the uses where I attach forms to tickets, but I don't think it will work with milestones. That is because of the url for the roadmap (which shows multiple milestones) vs. the individual milestone urls. A form attached to an individual milestone displayed via an url such as:

​http://my.trac.site/instance/milestone/milestone_name

will not show the same data when that milestone is viewed in the roadmap url such as:

​http://my.trac.site/instance/roadmap

[anonymous]

Replying to David.Byrne@us.xchanging.com:

I just looked a little closer to how WikiForms works. I'm probably not going to be able to use it like I was thinking. It should work fine for one of the uses where I attach forms to tickets, but I don't think it will work with milestones. That is because of the url for the roadmap (which shows multiple milestones) vs. the individual milestone urls. A form attached to an individual milestone displayed via an url such as:

​http://my.trac.site/instance/milestone/milestone_name

will not show the same data when that milestone is viewed in the roadmap url such as:

​http://my.trac.site/instance/roadmap

Just a quick idea...

The form builds the db-access-key (under which all data/infos about a form is stored) in different ways (see resolve_name​).

E.g.:

• relative_name : key = <url>/<field_name>
• absolute_name : key = <field_path_and_name>
• relative_context : key = <url>/<context>/<field_name>
• absolute_context : key = <context_path>/<field_name>

To decouple the key from <url> you might use the absolute_context.

<tf>context:/milestone_xyz_checklist</tf>

Please ensure that the context_name starts with '/'.

To check under which keys something is stored in the database, you might use the dump command:

<tf>dump:<regexp></tf>

or

<tf>dump:</tf>

[asic_druide]

one further comment...
The context might be changed several times within a form and is effective for all the following db-access-key calculations.

[David.Byrne@…]

I'm not sure if the relative vs. absolute helps. I'm creating a directory under the wiki that will have the forms that I will use in my tickets and milestones. One form would be client / manager sign-off on a milestone. My form looks like:

{{{
#!WikiForms
|| || '''Date Completed''' || '''Completed By''' || '''Description''' || '''Comments''' 
|| <tf>checkbox:client_app</tf> || <tf>when:client_app</tf> || <tf>who:client_app</tf> || Client Approval || <tf>input:client_notes</tf>
|| <tf>checkbox:mgr_app</tf> || <tf>when:mgr_app</tf> || <tf>who:mgr_app</tf> || XChanging Approval || <tf>input:mgr_notes</tf>
<tf>submit:
# label    : label on the button, defaults to 'Send'
# class 
# id 
label='Update'</tf>
}}}

This is then being included in the individual milestones with:

[[Include(Forms/MSApproval)]]

If I add the / to make it absolute or add an absolute context, I would think it would make it worse. I could see using absolute naming or absolute contexts, if I was re-creating the form in each milestone. The idea was to create the form once and include it in each milestone. For tickets, I think it will work because there isn't a summary page for tickets that shows all of the information.

[David.Byrne@…]

I found a way to split things out per milestone using the absolute contexts. If I use the TemplInclude and pass a key, I could make the context unique for each milestone. My form now looks like:

    {{{
    #!WikiForms
    <tf>context:/milestone/{{milestone}}</tf>
    || || '''Date Completed''' || '''Completed By''' || '''Description''' || '''Comments''' 
    || <tf>checkbox:client_app</tf> || <tf>when:client_app</tf> || <tf>who:client_app</tf> || Client Approval || <tf>input:client_notes</tf>
    || <tf>checkbox:mgr_app</tf> || <tf>when:mgr_app</tf> || <tf>who:mgr_app</tf> || XChanging Approval || <tf>input:mgr_notes</tf>
    <tf>submit:
    # label    : label on the button, defaults to 'Send'
    # class 
    # id 
    label='Update'</tf>
    }}}

My call now looks like:

[[TemplInclude(Forms/MSApproval, milestone='Modifiers 2010')]]

for milestone called 'Modifiers 2010'.

Going back to the original enhancement, would it be possible to combine permissions into the WikiForms. Ideally, it could not only use actual user permissions like the AccessMacro does, but also conditionals either based on python code or based on Trac database entries (like Ticket 1 status is closed or Milestone 'Milestone 1' is completed).

I was thinking that it would be nice to have at least two levels: viewable vs editable. Three would be better yet: non-viewable, viewable, and editable. Some items (such as value fields or labels) would not have a editable version.

I'm not sure how the level would be set. One way would be that an alias could be created and that alias attached to various elements.

Maybe something like:

<tf>permission:mgr_approval:
editable=User(SOME_PERMISSION)
</tf>

Then when the items are displayed, the code would look something like:

<tf>mgr_approval:checkbox:mgr_app</tf> || <tf>when:client_app</tf>

This would show the checkbox as editable when the mgr_approval permission is satisfied. Otherwise it would show a disabled (but possibly checked) checkbox. Since the when is not prefixed, it would always be shown (it's not editable anyway).

This is just some of my initial thoughts. As I said before, it would be nice to include permission checks that didn't only look at User permissions. Maybe something like Milestone('Milestone 1', completed=False).

[cna training]

nice post. thanks.

[asic_druide]

...i'll think about a solution how fields could be made conditional (no-view/view/change)...

[asic_druide]

To my understanding there are two independent parts:

1. Make forms attached to milestone descriptions show the correct data independently whether they're displayed via milestone or roadmap URl.
2. Make forms configurable with respect to visibility/changeability of individual fields.

The first part you've already solved by combining WikiFormsPlugin with TemplInclude (which i didn't found to be publicly available).

As the first problem is very generic, my solution will go into the direction of embedding a modified version of the IncludeMacro (limitted to include wiki pages but supporting parameters) into the WikiFormsPlugin code (named e.g. WikiFormsInclude).

To help the second problem my idea is to add additional commands for setting permissions to (r,rw,w,'') optionally based on conditions.

Like this:

permission

<tf>permission: [permission-condition] : permission-value | permission-modifier | permission-name </tf>

permission-condition

milestone_state | ticket_state | user [not] in (list-of-string-literals)

permission-value

'' | r | w | rw

permission-modifier

+r | -r | +w | -w | +rw | -rw

permission-name

string-literal

If a permission-name is not yet defined, it's set to the current permission, if it's already defined, it's fetched and the current permission is set to it. The intention is to define the possible permission levels once at the beginning of a form, assigning them to symbolic names and reuse the settings in the rest of the form. This should avoid repeating conditions.

If current permission (might change while parsing a form definition) has no read permission, those parts of the form (fields or other text) are discarded (not shown at all).

If current permission has read but no write permission, other text will be shown and field will be rendered read-only.

If current permission has read- and write-permission, other text will be shown and fields will be rendered like currently.

Default of current permission will be 'rw' to be backward compatible.

Please note that all the above mentioned permission stuff will impact the rendering of a form, not blocking evil users who have WIKIFORMS_UPDATE permission of faking POST request replies and accessing read-only fields. Protection against this would require much more effort.

[asic_druide]

changeset:8190 should solve the enhancement request.

see WikiFormsPlugin and WikiFormsPlugin for the extended syntax (slightly different than comment:8)