| Author |
 Topic  |
|
|
AnonJr
Moderator
United States
5768 Posts |
 Posted - 11 August 2005 : 13:34:50
|
This post got me thinking...
Right now I am working on integrating two parts of the LMS I developed for the hospital into the Snitz forum I have running there.
The fun part is figuring out how to handle the various permission problems.
I have a "Class Flyers" system that provides ads for all of the classes that are currently offered in-house - complete with the various people who will need to be able to Admin. the various flyers - but I do not want to allow to admin the fourm or other areas.
I have another system for managing online tests. Some people will need to be able to add presentations/tests to the system, some will only need to analize the logs, and some will only need to be able to find specific entries.
Right now the various systems outside the forum use the "Security through obscurity" method of management. That is one of the several reasons I am merging the systems together.
That long-winded explanation leads me to my question:
Would I be better of making new mLevs for the various levels of administration, or creating some switches in the profiles that I can turn on and off to indicate the various levels of permission?
Thoughts?
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 11 August 2005 : 22:41:44
|
It is just a matter of opinion, of course, but with the scenario that you're talking about, I would separate the permissions. Snitz permissions would be handled by Snitz, as it is now. Other apps permissions would be dealt with on its own, adding the appropriate info to the member's table and accessing the info whenever needed.
Just MVHO. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 11 August 2005 : 23:08:17
|
Yeah, the more I think about it, the more that seems the way to go. I just have this nagging feeling in the back of my mind that I'm missing something that would make it so much easier... I just wish I could figure it out.
I thought that if I posted the question up here, I'd either be told one of three things (or all at onece):quote:
1. Play with the mLevs
2. Play with the member profiles and use a bunch of booleans
3. You're an idiot ... (and hopefully this is followed by "and this is better than either option...")
|
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 11 August 2005 : 23:17:43
|
Why the feeling?
Thinking a bit more about your problem, I guess I would do create a table to register people's access permissions to the different parts of the non Snitz systems. Considering that only a few people will get admin access to those systems, all you'd probably need would be to register the id of the members that would get admin access and the system that admin access applies to. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 11 August 2005 : 23:51:51
|
The "other job duties as assigned" have me running in so many different directions that I haven't been able to focus as well lately.
As to the people that would need various permissions,
- All of Training and Development would need full access to all flyer and ed. testing functions
- All the Clinical Educators (a different department, don't ask), all department managers, and all service line directors would need to search the test logs
- Some of the above and misc. other will need spot access to either add tests/presentations and/or flyers
Fun stuff.
At least here I'm not the only programmer... I work in the Training and Development department as the "Computer Based Training Programmer" - IS won't help me (I'm a security risk), and few are reasonably computer literate let alone programmers...
I say that only to qualify the fact that I am grateful for some programmers to bounce ideas off of  . |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 12 August 2005 : 05:29:09
|
Things are never as easy as they seem  .
If you are in a situation where most people have a default access level regardless of the department where they come from (say, read access to all the stuff), you can just maintain info on who has access needs different than the default, and what needs are those. If this is not the case, then you may need to maintain access info for each user for every item needing access control, or at least for each user group, if you have user groups.
Of course, the latter is much more complex and you should avoid it if possible. Regardless of that, I wouldn't use the Snitz member level system to maintain access restrictions. It was designed with a specific scenario in view, not very similar to yours. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
|
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 12 August 2005 : 11:24:01
|
I think I might look into the User Groups MOD and see if that will help any...
At any rate, I have resolved any doubts about using the Snitz memeber levels. I don't plan on going down that road.
Thanks for the help. Like I said, I really appreciate having some programmers available to help flesh out ideas. |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 12 August 2005 : 11:41:53
|
The User Groups mod basically allows you to manage much more easily permissions to access a given forum, doing it from a group point of view, instead of a single user point of view, which is the way Snitz handles it. Nikkol, in the readme file for the mod, wrote:
Forum administrators can assign members to UserGroups and the use the UserGroups to restrict access to "Allowed Member List" forums based on three permission settings: Deny, Read-Only, and Allow.
Forums that are not an "Allowed Member List" forum can have Deny and Read-Only permissions for each UserGroup.
UserGroup visibility by members and moderators is configurable by forum administrators.
Individual UserGroups can be set as Hidden.
Auto-Join UserGroups on member registration.
Being a great tool to manage permissions on a group basis, it does not got beyond Snitz permissions, since it does not add to those permissions (this should not be seen as a demerit of the mod, which I personally find one of the overall best Snitz mods I've seen). So, if this suits your needs, the mod surely will go to a great length ensuring a easier management of your users and their permissions regarding forum access. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
Edited by - ruirib on 12 August 2005 11:42:22 |
|
|
|
Shaggy
Support Moderator
Ireland
6780 Posts |
Posted - 12 August 2005 : 12:06:26
|
But, if Anon did as you suggested and create a new table to store who has what permissions outside the forums, that table would become a lot more manageable and easier to maintain if he assigned permissions by group. Then it would just be a case of adding and removing members from the relevant usergroups and he may never need to touch that new table again once he gets it setup.
|
 Search is your friend
“I was having a mildly paranoid day, mostly due to the
fact that the mad priest lady from over the river had
taken to nailing weasels to my front door again.” |
|
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 12 August 2005 : 16:05:53
|
ruirib, I will probably need the extra features for the forum access. Now that people are finally starting to see what can be done, I'm getting more complex requests.
And I think Shaggy's got the rest of my thoughts summed up in that I think I'll probably Mod the MOD to manage the other permissions which I'll either store in another table or along with the rest of the user's profile (not sure which of those options would be better).
This has been great for clarifying just how much I would (or would not) want to use the mLev for things other than Snitz-specific stuff.
This is why I love you guys
|
|
|
|
Shaggy
Support Moderator
Ireland
6780 Posts |
Posted - 15 August 2005 : 05:04:56
|
Ay, if you've got multiple permissions to manage, using M_LEVEL and mlev would be a bit of a headache but, if you've only got one additional access level to add, as I have with MeTV and Woo.ie, I actually find it easier to use M_LEVEL rather than creating a new, custom method.
|
Search is your friend
“I was having a mildly paranoid day, mostly due to the
fact that the mad priest lady from over the river had
taken to nailing weasels to my front door again.” |
|
|
|
gelliott
Junior Member
USA
268 Posts |
Posted - 15 August 2005 : 10:49:22
|
| I came across this last year - I added a separate field to my Members table called M_BoardLevel (for my Board of Directors who needed more global rights but were not computer savy enough to have moderator or admin rights - saves me having to specifically grant them read rights to all the various private forums each year as they rotate). I found the code in the includes that sets the mLev value, and I simply set a BoardLev value at the same time. Then, anywhere I wanted to test for it, I did. I added it to the pop_profile page to display for admins only, I added it to the default, topic, and forum pages to control display of various hidden forums, etc... I agree with Shaggy and Ruirib - if I had more that one additional value to set, I'd probably have moved it all to a different table, and utilized the groups mod, but for my one group this worked best. |
* The optimist says the cup is half full. The pessimist says it's half empty. But the engineer knows the truth - the cup's design is incorrectly sized.  |
|
|
|
AnonJr
Moderator
United States
5768 Posts |
Posted - 15 August 2005 : 11:46:17
|
quote:
for my Board of Directors who needed more global rights but were not computer savy enough to have moderator or admin rights
Do I know that feeling!
As I haven't had the time yet to look more closely into the User Groups MOD, that is the first order of buisness...
I was thinking of tacking 4 boolean fields on to the profile table, and editing the pop_profile page so that only I could turn them on and off.
I may also look at adding the extra mLev for certain people to read some of the private fourms, but at this point its been easier to grant access on a case-by-case basis.
|
|
|
| |
Topic |
|
Topic Locked
