I want to rework terms of use to get a solution for the following problems:

JS PopUp & token support = filtered textblock

At first I thought about creating plugins to realise the popup. But now I believe the best way is to provide a filtered textbox. I want to add token support and nearly any JS PopUp Module has some input filter solution. By this we can add a "I agree to the terms" text like we want with any JS fancyness we need. This way an admin can add as many links as desired. A "You have to agree to our terms and our privacy policy" will be possible.

This text should be small and NOT contain the terms it self. This would be a faulty design because we could not achieve the versioning of our terms with ease. But even it might mislead people into doing this imo its much better with a filtered textarea.

Versioning & multiple terms

Versioning of the terms is a much asked feature! Problem here is the workflow.

IMO it should be like this:

  • Add a node to the terms list.
  • The list shows you version ID of the terms used, last update and current version ID. With some nice colors so you see change.
  • The real versioning should be done by other modules and the difference by something like the diff module. Maybe I can hook them in. Maybe I need a dependency for TOU versioning.
  • If you click a button and agree the term IDs are synchronised.
  • Every User that did not agree to the current version ID has to reagree again or can't use the site logged in.

Just to mention: To add the multiple terms pages to the TOU checkbox text you can use tokens :)

More options & exportable & template file

For example we need some more options like "Show the terms in a fieldset" that you don't need to hack the template. We need a real template file to use preprocess. And last but not least imo we do need to be able to export our terms. So we can use the module with a deploxment strategy that updates the terms nodes and demands people to re agree. Don't know exactly if ctools export can do this but it can do magic so it should :)

CommentFileSizeAuthor
#7 terms_of_use.png33.36 KBkars-t

Comments

kars-t’s picture

kars-t commented

My wish for a 2.0 is that we create an interface that can manage multiple nodes marked as terms pages. The problem is how can we manage all those.

A textarea so nice it might seem at first might be too complicated as we loose the "One simple textbox" approach for the terms. This should be easy and not complicated. And my first though "Hey every JS Pop thing has a filter support" is probably wrong because íf we use tokens for the links to openup a term node we can't add a special CSS class or another token that enables the JS popup. So I believe we have to enable it otherwise and a textarea is not a wise idea.

kwinters’s picture

kwinters commented

I like the idea of using a node to render the terms. The legal module does this and that part is good, but the way it renders the output into the register form prevents me from using the module. Tokens, versioning, fields, etc. can all be handled by other modules through the node api.

As far as displaying the result, my vote is to let the end user choose.
* Open a link to the node in _blank. (default)
* Open a link without _blank.
* Render the text directly into the form.
* Use a supported popup module if it's installed (open in new window if JS disabled).
* Put a custom template in the theme to do whatever you want.

Where I can foresee trouble is in multi-language setups or where the site makers want to have subtle differences in TOS for different roles, etc.

The fieldset option sounds good. I would likely remove the fieldset if it was easy.

kars-t’s picture

kars-t commented

Hi kwinters

"The legal module does this and that part is good"
The legal module does not use nodes. Thats what I never liked about it, used TOU and I took a quick look to make sure they didn't change the module. ;)

"Where I can foresee trouble is in multi-language setups or where the site makers want to have subtle differences in TOS for different roles, etc."
I don't think this will be a problem because nodes map nicely in a translation set and TOU is already doing this.

TOU for different roles other wise is a problem. Maybe we need TOU Sets to achieve this. I think I will make some mockups.

kwinters’s picture

kwinters commented

Oops, I guess I got confused when you started talking about tokens and textareas. I think you were talking about the checkbox form item's text instead. Maybe that can go in the node as well? Fields are in D7 core already, and tons of sites use CCK in D6, so that might be an appropriate way to handle it.

As for translations, I was more concerned about the user-provided checkbox title / description. They can be tricky to translate, since t($user_provided_text) doesn't work all that nicely. I think that putting that data into the node would solve the problem.

kars-t’s picture

kars-t commented

CCK is a problem because we can't rely on that a terms node has a text field to be used as checkbox lable. I believe we still need that in the TOU module.

And t() is not a problem because I already use tt() from i18n for user given strings :)

kars-t’s picture

kars-t commented
StatusFileSize
new terms_of_use.png33.36 KB

I created a mockup and some more thoughts:

There should be Term sets per

  • Form
  • Group

This means we have the signup form and the group anonymous user gets a terms set. For this rather special form no other sets make sense.

But if we use the comment form we might add terms sets for any group there is. The anonymous maybe get a different terms page and the privacy agreement. The authenticated only get a special netiquette text to agree and the admins nothing.

Currently I have to think about ease of use and a special "All" terms set.

kwinters’s picture

kwinters commented

Take a look at the Mollom module for a good way to associate extra data with a set of form names. The latest version also support Webform.

The comment form TOS agreement makes sense per-role. If you are already registered, you would have agreed there, so it's reasonable to hide it on the comment form for authenticated.

Now, this is a lot of structure for just the ability to add checkboxes. Maybe it could be extended just slightly further and have more use? For example:

1) Module A creates this form management interface and other basic functionality
2) Module B adds functionality specific to TOS (checkbox required node?)
3) Module C uses the same framework to add a CAPTCHA to some forms (with a few per-form options)
4) Module D adds a text block (#type => 'markup') to the comment form about etiquette

Something along the lines of Actions, if not actually using actions.

It's hard to tell if anyone would actually use such a framework, but it's a thought. You will already be writing most of it anyway.

As far as usability goes, the only issues I see are:

* Making it easy for non-technical users to quickly and easily get to the most common configuration (good default?)
* There will be a lot of overlap between roles, so making it easy to keep them synced. "Same as X" checkboxes?

lpalgarvio’s picture

lpalgarvio commented

terms and conditions per role would be a good feature.

i think the main role (the first of possibly many applied to a user) should apply when selecting the terms of use.

kars-t’s picture

kars-t commented

My roadblocker is currently except that I want to do a cumulus release asap that I need an "add to form" functionality like the Captcha Module uses. I think I have to develope an open API approach but this will take some time thought...

iva2k’s picture

iva2k commented

> #2 My wish for a 2.0 is that we create an interface that can manage multiple nodes marked as terms pages. The problem is how can we manage all those.

Are you trying to achieve something like the terms of use section on the registration page on the following site?
http://qphy.org/user/register

kars-t’s picture

kars-t commented

Hi iva2k,

this is a slick idea to put links in the terms node ;)

But no not exactly like that. More like you can display two sroll boxes and three links. And be able to add this to a role + form combo.

zet’s picture

zet commented

Nothing new on this ?

kars-t’s picture

kars-t commented

Hi

the good thing is I am bound to projects. The bad thing is I am bound to projects. So currently nothng new about this. But as this is open source anybody can pick up the task and make the module shine :)

kars-t’s picture

kars-t commented
Status: Active » Closed (won't fix)

If someone wants to maintain this further please do. I am currently closing all D6 issues and will only add patches to D7 that are there. But at least I won't rewrite this module to something completely different.

I believe you can just use capture to add some kind of "agreement" challenge dialogue to all forms. This shouldn't be part of this module.