Currently, if the role expiration date is left blank, role_expire will set role expiration for that role to the default role duration specified on the role admin page. This means that if there is a default role duration, there is no way to set an unlimited role expiration for a role.
I believe better would be to automatically fill in the role expiration text field with a date that corresponds to the default role duration. Then the admin user has the option of setting it to be blank (unlimited) or keeping the default expiration date.
Looking at the code, this is a pretty easy change to implement.
Comments
Comment #1
stewsnoozeAre you thinking that they should type "unlimited" when on the edit role page?
Comment #2
sharplesa commentedNo, the edit role page is fine. It's the edit user page I'm talking about. So, if you have specified a default duration on the edit role page, roles on the edit user page come up filled in with dates that correspond to that default duration. And then you can override that default as you like, even to the point of erasing it, which then sets the expiry to unlimited.
Sample workflow:
Setup:
1. Go to admin/people/permissions/roles
2. Specify role name "tester" and click "Add role"
3. Click the "edit role" link next to tester and specify a default duration of 100 (days).
4. Click "Save role".
5. Go to user/#/edit and check the "tester" role checkbox.
The new desired feature:
6. The "Tester role expiration time" text area would come up prepopulated with a date that is 100 days from today, corresponding to the setting at step #3.
7. The help text would say, "Enter date and time in format: yyyy-mm-dd hh:mm:ss or use relative time i.e. 1 day, 2 months, 1 year, 3 years. Leave blank for unlimited duration."
7.a. Leave the field unchanged, OR
7.b. Blank the field.
8. Click "Save".
9. Go to user/# corresponding to the user edited in step #5.
10.a. For case 7.a., the user's "My account" page would show the role expire date.
10.b. For case 7.b., the user's "My account" page would not show any role expiration because "Tester" was set to unlimited duration by blanking the field.
Does that make sense?
Comment #3
stewsnoozeMy gut feel is that this would provide a complication to the users and the editing interface that isn't obvious. I think that site owners have a mix of roles, those that expire and those that don't.
Why do you think this use case is important? When I think about the typical use cases for role expire I think about the following things.
1) A subscription site where access to extra privileges is gained by assigning a role that expires when the subscription has ended.
2) Temporary access to site features. For instance a guest author is given a role that can create stories temporarily.
I'm not saying no here, I just want to understand why the general audience would care about such a feature. Also I think the implementation isn't that easy without additional per user data storage. Right now the trigger for assigning the default expiry duration is a blank expiration date. This runs every time the user is saved. If someone blanks it intentionally how is that different from simply selecting the role as a new role and not filling in the expiry, expecting the default to kick in.
How will you deal with that and what extra interface and storage would you want ?
Comment #4
sharplesa commentedThis functionality isn't complicating to users, but revealing, with no additional storage requirements.
There's currently no indication on user//edit of what the role expiry would be when the role granter accepts the default (or if there even *is* a default), correct? Role setter has no visibility into the number of days nor into what the expiration date would be...until after he saves and views user/#. All I'm saying is to pre-load the default duration and compute the default role expiration date into the field (if there's not a value there already), so the role setter can see what he's getting when he gives the person the role. (Isn't that how people are generally accustomed to defaults working?) If the role setter accepts that value, the storage requirements are no different than setting a custom expiration date that was not pre-populated with a default duration.
Are you concerned about tracking whether the expiration date was custom or came from accepting the default duration? I don't think anyone cares whether a user's role expiration came about by accepting the default value or by specifying a custom value, so there's no need to track that. I do think people care about the ability to say, "Yes, I know there's a default (and I see what that duration is, and what the resulting end-date would be), but I want the value to be THIS instead." Or, and this is currently impossible if a role has a default expiry, "I want this user to have this role indefinitely."
Comment #5
stewsnoozeoh I understand now. That does sound like something we could do. You just want to alter the form value on display if it is blank.
Comment #6
sharplesa commentedThis should be addressed (for D6) by the patch at #649256: Default expiration when creating new users - http://drupal.org/node/649256#comment-5291110. Please test with D6. Once it's proven there, I'll update for D7.
Comment #7
sharplesa commentedUpdate: rolled patch at http://drupal.org/node/649256#comment-5291110 into new version 6.x-1.12. Ready to create 7.x version.
Comment #8
jukka792 commentedIs this change described abowe already implemented to D7 version of role expire module?
Shortly, logged in user has an extra role which default duration is set to 10 days.
When user logs in after 2 days, where and how he/she can see that there is 8 days left for this extra role.
(extra role is just an additional role which grants more access to user)
Comment #9
rcodinaPlease, If you are already interested on this feature open a new issue with and updated patch.