342
Quote:
This is probably too obvious, but, assuming you're using group-based permissions, you have made sure that the Registered Users group is able to view the private forum, right?
You have to treat the Registered Users group just like any other, it needs permission to whatever private forums you want it to have permission to.
I can't help with User based permissions, since we've never managed things that way.
To make it easier to deal with giving posting permission to multiple groups for you private forum, you may want to do an extra hack on the one admin file that is in the private forum hack, so that groups can post by default, and so that the group list is not so narrow. You can do that by changing a zero to a one in the right place (to turn on posting permission by default) and by commenting the width specification for the group box. If you know anything about PHP it should be easy to find the right places. If you have trouble, PM me and I can e-mail you our modified file.
--Julian
file2mail wrote:
i just created a new group to test with ... added one test user... and that user was able to access the private forum properly...
BUT using the default 'Registered Users' Group ... the default group of which all registered members are put in ... wont work with the hack...
This is probably too obvious, but, assuming you're using group-based permissions, you have made sure that the Registered Users group is able to view the private forum, right?
You have to treat the Registered Users group just like any other, it needs permission to whatever private forums you want it to have permission to.
I can't help with User based permissions, since we've never managed things that way.
To make it easier to deal with giving posting permission to multiple groups for you private forum, you may want to do an extra hack on the one admin file that is in the private forum hack, so that groups can post by default, and so that the group list is not so narrow. You can do that by changing a zero to a one in the right place (to turn on posting permission by default) and by commenting the width specification for the group box. If you know anything about PHP it should be easy to find the right places. If you have trouble, PM me and I can e-mail you our modified file.
--Julian
343
I can only help with the Flat view:
In Admin Menu->System->Preferences->Default Comment Display Mode, set it to Flat to make that the default for all new users that join your system.
Yes, it says 'comment display mode' but it affects how newBB works too.
Individual users can control this setting in their Profile. I don't believe you can alter this setting for existing users, they would have to do that themselves (unless you wanted to go into your DB and modify the setting manually for everyone).
Hope this helps, good luck,
--Julian
In Admin Menu->System->Preferences->Default Comment Display Mode, set it to Flat to make that the default for all new users that join your system.
Yes, it says 'comment display mode' but it affects how newBB works too.
Individual users can control this setting in their Profile. I don't believe you can alter this setting for existing users, they would have to do that themselves (unless you wanted to go into your DB and modify the setting manually for everyone).
Hope this helps, good luck,
--Julian
344
A good observation. XOOPS really isn't a CMS in the sense of managing content on a site. You might use WF-Sections or TinyD or some other module to do that. XOOPS is a framework within which to build applications that make use of the good security, groups, permissions, themes, etc, systems that XOOPS provides.
Mambo is definitely good at handling publishing workflow out of the box.
We have clients that need to do both. We have a XOOPS module on the drawing board that will provide traditional CMS workflow controls for static content that resides inside XOOPS, and probably also for static content that resides outside XOOPS on another website hosted in the same domain.
Essentially, you would use XOOPS as your private, internal website for knowledge sharing and collaboration, and XOOPS would also be the control panel for managing the content in your public website.
Sound cool? Don't get too excited, it's still vapourware, and we have no idea whether it would be released publically, and whether it would be GPL'd even if it were released.
If others know of full publishing workflow management modules for XOOPS, I'd love to hear about it. But so far I have uncovered none.
--Julian
P.S. Mithy, a horizontal block option would ROCK.
Mambo is definitely good at handling publishing workflow out of the box.
We have clients that need to do both. We have a XOOPS module on the drawing board that will provide traditional CMS workflow controls for static content that resides inside XOOPS, and probably also for static content that resides outside XOOPS on another website hosted in the same domain.
Essentially, you would use XOOPS as your private, internal website for knowledge sharing and collaboration, and XOOPS would also be the control panel for managing the content in your public website.
Sound cool? Don't get too excited, it's still vapourware, and we have no idea whether it would be released publically, and whether it would be GPL'd even if it were released.
If others know of full publishing workflow management modules for XOOPS, I'd love to hear about it. But so far I have uncovered none.
--Julian
P.S. Mithy, a horizontal block option would ROCK.
345
Thanks very much for all the comments and kudos tklee. 
Here's my thoughts...
Quote:
The user account creation form does check to see if the reg_codes datatable exists (ie: the module is installed) and if it does, then the registration code is asked for. If the table does not exist, then the form does not include the box for registration code.
So if you leave the hacked files in place but remove the module, then the account creation process should be exactly as if the hacked files were not present.
Quote:
Thanks!
Quote:
Good point. Security is a big concern for our sites, since clients use them for important, confidential business information, so they didn't want guessable or easily crackable codes, that's why they were made random (though only six characters doesn't make them that hard to crack, but anyway, they're not dictionary words).
I agree though, it would be a good addition if you had the option of typing in a word that you wanted to use for your code. Maybe that will go in a future version.
I've found, among other things, that the registration code box is a required field, so there's no point in having the word 'Optional' beside it. So there's a few polish-related things like that which could go in another release.
Thanks one and all for the interest!
--Julian
Here's my thoughts...
Quote:
changed? May I suggest wrapping those added codes with a condition statement so if the module is not installed, those codes will get skipped?)
The user account creation form does check to see if the reg_codes datatable exists (ie: the module is installed) and if it does, then the registration code is asked for. If the table does not exist, then the form does not include the box for registration code.
So if you leave the hacked files in place but remove the module, then the account creation process should be exactly as if the hacked files were not present.
Quote:
Registration Keys is admin-only tool so the webmasters have to do everything; Registration Codes provides the "group invitation by group member" function. That's really cool. I also found automatic expiration very useful.
Thanks!
Quote:
About the randomly generated password, I'd suggest it being optional. Making it optional allows us to use meaningful keywords to invite people.
Good point. Security is a big concern for our sites, since clients use them for important, confidential business information, so they didn't want guessable or easily crackable codes, that's why they were made random (though only six characters doesn't make them that hard to crack, but anyway, they're not dictionary words).
I agree though, it would be a good addition if you had the option of typing in a word that you wanted to use for your code. Maybe that will go in a future version.
I've found, among other things, that the registration code box is a required field, so there's no point in having the word 'Optional' beside it. So there's a few polish-related things like that which could go in another release.
Thanks one and all for the interest!
--Julian
346
Quote:
Just notices. They don't affect the operation of the module at all. Thanks,
--Julian
tklee wrote:
I turned PHP debug on and got these:
[snip]
Just notices. They don't affect the operation of the module at all. Thanks,
--Julian
347
Quote:
I believe Rossi is working on adding in this kind of feature, but I'm not certain.
We are really busy with some newly launched client sites right now, but we do have plans for some advanced administration module(s) in the near future, and this kind of registered- users-can-join-groups-themselves feature might find its way in there.
--Julian
irmtfan wrote:
any chance to develope this for registered users.
i want user can subscribe and unsubscribe for a group and approve by admin. this feature is really needed.
thank u
I believe Rossi is working on adding in this kind of feature, but I'm not certain.
We are really busy with some newly launched client sites right now, but we do have plans for some advanced administration module(s) in the near future, and this kind of registered- users-can-join-groups-themselves feature might find its way in there.
--Julian
348
You could make the welcome page available only to anonymous users, and then when people log in, they cease to be anonymous and the welcome message should disappear.
If your message is simple enough, you might want to just make a custom block and put it in the centre column, and give the anon users permission for that block, but don't let anyone else see it.
I believe you need to install the TinyD version of Tinycontent in order to have group access permissions for the stuff in Tinycontent, but I could be wrong about that.
Hope this helps,
--Julian
If your message is simple enough, you might want to just make a custom block and put it in the centre column, and give the anon users permission for that block, but don't let anyone else see it.
I believe you need to install the TinyD version of Tinycontent in order to have group access permissions for the stuff in Tinycontent, but I could be wrong about that.
Hope this helps,
--Julian
349
Yes, group permission control is a big deal once you start to divide users into lots of groups, especially if those groups represent entirely different audiences (ie: Luscious Ladies and Christians, totally different groups, as opposed to New York City Volunteers and Washington Volunteers, different groups but related to each other).
It can be a chore to manage XOOPS sites that push these groups boundaries.
--Julian
It can be a chore to manage XOOPS sites that push these groups boundaries.
--Julian
350
Quote:
I read something on another forum about .zip files opening up empty if you click on them and have your browser automatically open the file for you. But if you save them to your hard drive (right-click and save the target) and then open up the file, it contains files. Not sure if that is the problem you were having, but maybe?
PM me if it doesn't work and you really want to try the module.
Good luck,
--Julian
tjnemez wrote:
julian i just downloaded module, however, it is just directories and no files?
I read something on another forum about .zip files opening up empty if you click on them and have your browser automatically open the file for you. But if you save them to your hard drive (right-click and save the target) and then open up the file, it contains files. Not sure if that is the problem you were having, but maybe?
PM me if it doesn't work and you really want to try the module.
Good luck,
--Julian
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|