Modify

Opened 4 years ago

Last modified 3 years ago

#8715 new enhancement

Add WikiForms functionality

Reported by: David.Byrne@… Owned by: hasienda
Priority: high Component: TracFormsPlugin
Severity: normal Keywords: form permissions
Cc: rjollos, asic_druide Trac Release: 0.12

Description (last modified by hasienda)

Have you looked at the other Forms plugin called WikiForms? I started using TracForms originally and switched to WikiForms because there seemed to be more flexibility there (additional field types besides check boxes, user-definable permissions on fields, etc) and TracForms development had slowed at that time.

However, since then, development on WikiForms seems to have slowed and development on TracForms seems to have picked up. The functionality that I need is the ability to use permissions to limit parts of forms to specific user groups. Also, the ability for the form to trigger an external event or condition would make the forms more usable for me.

Attachments (0)

Change History (6)

comment:1 in reply to: ↑ description Changed 4 years ago by hasienda

  • Cc rjollos otaku42 added; anonymous removed
  • Keywords form permissions added

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

Have you looked at the other Forms plugin called WikiForms?

I had no idea, never seen a link like that at WikiFormsPlugin wiki page back to TracFormsPlugin.

I started using TracForms originally and switched to WikiForms because there seemed to be more flexibility there (additional field types besides check boxes, user-definable permissions on fields, etc) and TracForms development had slowed at that time.

I see now, quite a different concept with registration of fields, custom permissions,...

However, since then, development on WikiForms seems to have slowed and development on TracForms seems to have picked up.

Yeah, now this has been largely driven by my own demand.

The functionality that I need is the ability to use permissions to limit parts of forms to specific user groups. Also, the ability for the form to trigger an external event or condition would make the forms more usable for me.

Thanks for sharing your thoughts. I'll have to dig much more into that plugin's code to see, what could be done to TracFormsPlugin in that respect without re-inventing the wheel. Sadly, licenses are not fully compatible, but not so much of a problem as long as it's not going from TracForms (GPL) to WikiForms (BSD). Sad to say I even had some request rejections due to the GPL-ed code. I might have joined in for WikiForms development.

This is a little late for me now, anyway I do care for freedom of choice, so let's see, what could be done, as long as the original author is still around - I hope. There shouldn't be two half-to-unmaintained plugins with similar functionality, if this could be arranged at all. And I like to have someone around testing new stuff, and this seems like a viable chance.

comment:2 Changed 4 years ago by hasienda

  • Cc asic_druide added

I'd love to hear from the WikiFormsPlugin author Klaus Welch what future he's envisioning for his plugin - or better both form providing plugins. Ideally we should have just one project with all/the best features users requested and do request in the future. Forking will just disperse effect instead of joining effort of interested contributors. All of us are too busy to let that happen, right?

comment:3 Changed 4 years ago by hasienda

  • Cc otaku42 removed
  • Summary changed from WikiForms functionality to Add WikiForms functionality

TracForms will soon have a lot more in common with other plugins regarding uniform Trac db access. With regards to published best practice for db API usage it'll be on par with WikiFormsPlugin.

comment:4 Changed 4 years ago by hasienda

See TracFormsPlugin/Dev for development plans including feature listing and side-by-side comparison of both plugins. Please correct, extend and comment on this.

comment:5 Changed 3 years ago by hasienda

(In [11283]) TracFormsPlugin: Add optional write protection to input fields, refs #3264, #5353, #8715 and #9640.

A new keyword argument '-mode', for now exclusive to tf.input and tf.textarea, with value to choose from the following list:

  • ro - input blocked, like static text, but in non-editable form field
  • rd - same as 'ro', but don't display stored value but default instead
  • rw - regular input behavior at all times (default)
  • once - initially 'rw', but blocked ('ro') after first form submission

It's an optional argument, retaining full backwards-compatibility with existing field definitions by choosing -mode=rw as implicit default.

comment:6 Changed 3 years ago by hasienda

  • Description modified (diff)

Permission based behavior is still not there, but the new conditional field locking is at least an important step towards this feature.

Add Comment

Modify Ticket

Action
as new The owner will remain hasienda.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.