Role based legal

Yep would be great actually!
Any idea if it will be implemented?

In order not to duplicate this ,
subscribing for D6 !

Subscribing for D6

I would like this too

Ditto. I am using Agreement module http://drupal.org/project/agreement only because it supports role-specific agreement. Legal appears to be a more capable module, but we have buyer and seller user roles on our site and our agreement only applies to sellers.

This would be a great feature, and thanks @mdayton for the tip about agreement module!

+1 to D6!!

+1 to D6!

I'm in the same boat. I have buyer roles and seller roles. Each of which need different T&Cs.

+1

++

Subscribing

There's a lot mentioned on the Agreement module's description page that would sit well in this module. I'm rather surprised that none of it features here.

I'd love to just sit down and code this right now, but I really can't justify it with so much else on, dangit.

Legal is currently designed for use on the registration process, at which point the user doesn't have a role.

Not clear what people actually want from 'Role based Legal', maybe someone could specify the workflow?

By the way, at some point I'll be working on converting Legal module into an API, so will be possible to build other modules on it and add Legal features to existing modules.

Ok so a specific use case. I create users of a certain role long before they use the site. These users are in the system unwittingly at first. When they have passed certain criteria, a rule kicks in and promotes them to another role. These users never log in until this point, indeed they probably don't even know they're in the site at all, but that's when they are automatically sent a password reminder, at which point they can then log in with their new role. It doesn't, at any point, make sense to challenge these users before they have this role. Indeed, it is more likely to be a hindrance than anything.

Furthermore, in this same site, there are two distinct sections. In the section not relating to the above scenario, there is no need to challenge any of the associated roles *at all* - content managers, etc.

That said, legal.module still issues an appropriate challenge at the point of login for those newly-promoted users, which is fine. The point is, users can exist *with* roles before they ever log in; they can be created *with roles* in the create UI; etc. That they are challenged on the registration page is of course admirable, but there are many other use cases.

Placing a multi-checkbox widget on the settings page is relatively trivial, as is implementing the checks on that in code - if the current role is not selected on the widget, don't challenge them.

I see from testing that any user will not be challenged until they log in directly. Masquerade does not trigger the challenge for example, which is good, this is a start.

I actually quite like what http://drupal.org/project/agreement offers, from its description. I don't see a need to shy away from displaying the Legal page (view legal page permission). That can be done with content_access or other access modules. I don't see a need to be creating revisions internally either - why not just use a node and be done with it? Or failing that (as there was an obvious architectural decision made) why not offer a choice? Radio between hard coded /legal and a choice of node via autocomplete widget?

I understand why the terms-on-registration thing is useful as a short-cut. That said, it is a one-hit affair. If the registration is approved, either by admin or email confirmation, then the user gains the "authenticated user" role. If another role is granted by the system under different circumstances, then the user may then be in a role selected for challenge. Under either of these circumstances, could a check not be applied *then*, as an alternative? This is seemingly the default behaviour in any case, if the user has gotten to a position where the challenge has not yet been accepted.

In any case, I am curious as to what the performance hit is of all this? It strikes me there must be some check performed on every page load to ensure the challenge has been met...?

Perhaps some of this is off-topic, but better out than in! ;)

So the features shopping list would be:

• Bypass Legal accept at login/account page for specific roles
• Different T&Cs at login/account page for specific role(s)

I don't have time to work on these at the moment, but good to think about them.

I have used a trick that doesn't require any of the modules. This is for Drupal 7.x
1) First add a field set having title similar to 'Terms & Conditions' or any thing you want
2) Install markup module and add a markup field
3) Copy past your legal text and put the field under the fieldset
4) Now, add a boolean check box and make it 'requited'
5) Give it a lable like 'I agree to above terms & conditions'
6) Place this field blow the markup field, within the fieldset and you are done.

Now, you need to hide both these feilds using the display settings.
Also, once the node/profile created, you need to write a hook_form_alter and disable the checkbox.

This is worked for me quite nicely.
I appreciate your feedback.

Regards.

Bypass Legal accept at login/account page for specific roles would be appreciated.
For example latest updates of drupal's Facebook login applications will not work with Legal module enabled (Legal's login redirect to legal_accept page will cause an infinite loop at the login for facebook users) but this issue would be solved if we could bypass legal accept at login for role i.e. 'facebook' (and at facebook application side auto-assign facebook users with role 'facebook').

There are a few requests for changes by role. In my use case, regular users have a general purpose T&C covering reading pages. Some users have roles allowing upload and they have to agree to special T&C. Skipping the T&C part looks to be a small code change with a configuration variable to select the right role.The legal_user_function has if ($user->uid == 1) { return; }. If the test was followed by a user role check, we could skip the T&C for users who do not have critical roles. Does this sound like a useful approach for the other changes mentioned here?

Looking at the code for multiple roles and our use case, the tables would have an additional index level of rid. The standard user would get the T&C for rid 2 (authenticated (if created)) and selected other users would get additional T&C, similar to the extra questions.

When a user first registers, they get standard T&C. When the admin assigns an extra role, the person should get the extra T&C on their next login. If they are assigned two special roles, they might get two T&C sections. In our case, there are only two special cases.

We will have only one deciding role for each T&C. There are other roles assigned to some special users but they do not need T&C.

D7 version: I have Legal almost working with separate T&C for special roles. It lets me store multiple T&C based on roles. If someone else wants to help, I can zip it here or sandbox it. It is not ready for distribution as a patch.

All the change does is insert a role id into the database and assumes role id zero is " - All roles - ". You could set up an admin option to not display the role id and the code would work exactly the same as the current code. If the default was to not display the role, current users could upgrade without seeing any difference. In the background, their data would be created with a role id of zero.

Who is using D7 version and is interested in testing a version with roles in some form? I ask because this thread is D6.

#17 is a bypass by role which could be an admin setting unrelated to the change I am making.

Some other notes. I have the profile page change working plus changes to some of the views. I have not yet touched the login page because the site already has modifications there. I will test with the profile page for a while then change the login.

There is a function to return the role name for the role id and I use that in some but not all places.

The role selection is in the middle of the T&C creation page. It should be a prior selection where you select the role first then see the standard edit form with the role at the top. A little help with these things could make the change faster.

Is it ok to move this issue to D7?

It seems like there's several variations of this theme for role-based Legal in the issue queue. I was looking because I too now have such a need. A client has a site-wide T&C for all users and an additional T&C for specific roles. And yes, we are doing it at user registration with a multi-step user register form where the visitor identifies on the first step which role they are registering for. So it is not simply a case of one T&C per role, but a site-wide T&C plus an additional one for the extra roles.

To account for the multitude of similar use cases for multiple and role-based Legal, it seems like a 2.x version needs to be written. I like Legal's features where users must accept new versions and the Views integrations. I also like Terms_of_Use's node-based solution, especially in light of some of the tickets regarding improving WYSIWYG/text format support in Legal. I'm wondering though if D7's new entity system could be utilized to provide the new functionality.

I'd like to revive this thread to see, if possible, what code has been come up with so far for this.

I've encountered a situation where a client wants to provide a customised copy of the Terms to one particular user. In our use case, this particular user is created by the admins, so a role-based solution sounds like a workable option. Would be interested to see what's been come up with so far, even if it's not ready for D7 just yet.

Gave a try to agreement, which seems to follow a different logic. Example: won't apply for new users

In my case, I'm planning to let user apply for a specific role I have.
This is done by "Auto Assign Role", so path it's path based.

Once I know that http://my_d6_site/user/Register_with_this_speficic_role will create a specific role user, It should be quite easy to expose (or not) the legal notification to new users.

So - for my use case - we can talk about a "path based switch for legal"

Feedback are welcome

Path based? Perhaps an add on module connecting to a Legal API. Themekey and Context are two modules switching things based on path.

You could copy bits of themekey to create Legal key.

Legal context would be more of a pig initially because Context is overkill and Context requires the ctools monster. If you are already using Context for the Omega theme, or some other use, Context is not an additional overhead. Part, or all, of ctools will be in D8.

interesting. got to digg this

My quick fix would be

 if (module_exists('autoassignrole')) { 
    // get autoassigntorole path
    $sql = "SELECT path FROM {autoassignrole_page}  WHERE display = 1 LIMIT 1";  //improve this if you have  multiple paths
    $path = db_result(db_query ($sql));
    if ( arg(0).arg(1) != "user".$path )  {
      return '';
    }
  } 

inside legal.module:213

Since we all love no-hack solutions, there's lot more to be done here.

more details at http://fagioli.biz/content/assign-role-new-user-website-polity-acceptanc...

After reading several of these sort of tickets, there are three observations:

1) How do you know which role to use at registration
2) How do get the "legal-module" to actually implement different versions of T&C for different roles
3) and... lots of people are interested in this.

For #1: I think that path-based is a good idea to determine the role to use at registration time. This would also work with D7's "Profile2 Registration Path," where different profile types (roles) have different registration paths. So by the time you register, you know which role it will be.

For #2: https://drupal.org/node/271943 actually had a good suggestion.
I believe this is exactly the right solution, more or less, if the legal code itself gets updated by the maintainer.
Certainly the right parts are mentioned: a new column in the DB, changing the query, and a hook_form_alter, although it would probably need more code and logic changes (it would need a new mapping table that states 'role A' uses T&C-#1, etc.)

Until this gets picked up by the maintainer as an issue, I was looking at the code, and you might also be able to do something hacky, by using hook_form_alter(s) and using maybe the language field. Let's say the language is English (en), then we might be able to introduce different condition such as 'en-role1" and "en-role2" that are stored in the legal-table, and have the hook_form_alter store and retrieve those instead of the normal language version. Total workaround, may not work, but maybe worth a shot.

As for #3: if this issue lingers in 6x any longer, it won't get any love by the maintainer, which is why I'll bump it up to 7.x next.

If this stays in 6.x, it will never get done. See my comment above in #29.

I think "role based legal" itself is illogical when needed to show on registration and reasons are already mentioned in above comments. So one option would be to show different legal text when profile2(or some other method I might have not known) is enabled and having multiple registration path.

There's now a D7 port of Legal Extras module with additional role an path restriction functionality:

#2483951: D7 port + additional functions

Attaching a patch that will hopefully help someone else out. What the patch does is expose an API that can ultimately be extended by other modules. In the base legal module, there is the ability to add different "Groups" of Terms and Conditions. These groups can be extended by other modules to accomplish what you want. The two API hooks exposed:
- hook_legal_apply_keys()
- hook_legal_apply_key_alter()
Any module can provide different groups/keys that Terms can be applied to. This is being used in a place where role based is less important, but depending on your group/signup path, you'll get a different set of terms (or none at all).

I thought this was a better approach so that Legal can expose the ability to do multiple terms, but an addon module would be needed if you want to actually have different terms - perhaps legal_extras is the place to house the role implementation.

Until this is being picked up (project seems dead), let's think of ways where we can make these changes ourselves in our own modules without having to patch/hack (gulp!) the legal-module's code TOO much.

The main legal logic as far as what is stored in the DB is run in a few key functions:
- legal_get_accept
- legal_save_accept
- legal_get_conditions
- legal_display_changes

You can intercept these at a more higher level, by intercepting the hook_users or form_alters (by writing your own hook_form_alter, or hook_module_implements) which delegate to your own logic

Or more low level: you could intercept and change these queries in your module using hook_query_alter. For example, you could extract the UID from the query, and based on for example a role you could insert more logic yourself.

For that to work, though, the queries need to have a tag. That's very simple to do with the addTag() statement in the query. I added ticket https://www.drupal.org/node/2633132 for this.

In the meantime, if you need to actually alter the module's code yourself, this is one of the most minimally invasive ways I could think of.

Given the recent release, what is the status/take from the maintainer on this issue?
(Highly relevant feature request, IMO)