phpwebsite-developers

[Phpwebsite-developers] Storing user level options for modules

[Todd O. <to...@da...>]

As I posted to the website tonight I just thought about something we need
decide.  How will user level module options be stored?  I'm thinking of a
module level table as follows (assuming calendar module):

table: calendar_user_options
user_id REFERENCES users.user_id (foreign key to core users table)
option INTEGER or TEXT (as decided by the module designer)

--Todd

Re: [Phpwebsite-developers] Storing user level options for modules

[Jason C. <cam...@xp...>]

I would think the table naming should sort of be consistent so you can tell 
which tables are for modules.  Like say for the calendar it would be 
mod_calendar_user_options or just mod_calendar_opts or something like 
that.  I think thats what we have right now in place for modules.  At least 
the new calendar module and a few others I've been working with do it that 
way right now, which, to me seems like a good naming convention.

What we dicussed earlier, we were thinking about either having one table to 
have the security info for all the modules or 1 for each module.  Not sure 
which would be best right now.  I've been thinking about the modules in 
general terms.  IF each module would have a security table, it would have 
to be named like the module tables of course, say mod_calendar_admin or 
something like that and the table structure could be something like below 
to some degree.

table: mod_calendar_admin
user_id REFERENCES users.user_id (foreign key to core users table)
seclevel INTEGER
something something something else....


Some of this would depend on how involved the module actually is.  Like the 
calendar would be a major module in the overall portal and might have 
different admin features or just one global one, based on whatever the 
module writer sees fit....

-- 
Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer


> As I posted to the website tonight I just thought about something we
> need decide.  How will user level module options be stored?  I'm
> thinking of a module level table as follows (assuming calendar module):
> 
> table: calendar_user_options
> user_id REFERENCES users.user_id (foreign key to core users table)
> option INTEGER or TEXT (as decided by the module designer)
> 
> --Todd
> 
> 

Re: [Phpwebsite-developers] Storing user level options for modules

[clayton c. <cc...@ca...>]

Jason,
  im working on specs for security (actually access control). we can handle
security in a way that does not require each table to have an additional
security related table. check out Todd's website for the translations i did
of ACS's 3.x permission system. it handles security in a much more granular
way than just the "seclevel" way.

    the benefit of this approach is that the module writer simply has to
define a set of permissions for the module (maybe in a module XML
description file), and the security admin code can handle everything else in
a generic way. In other words, the module writer can simply write the module
and not have to worry about implementing his/her own code for setting up
permissions.

    while on the subject, how are we segmenting admin "levels"? my thought
is site admin, group admin, maybe module admin, and if we decide to do
multiple sites per install, "super" admin

Re: [Phpwebsite-developers] Storing user level options for modules

[clayton c. <cc...@ca...>]

Todd,
  the other thing to consider is maybe having group as well as user level
preferences. for example, if we have a group calendar, the group admin may
want to have a way of specifying preferences. so we can add a group_id
field, and we'll know which type preference it is by which field is not
NULL.

    BTW - how far along are you with the SE document you were preparing ? i
want to begin putting something together about permissions and access
control, but that depends in part on how "OU" (as you called them) are
organized.


clayton

[Phpwebsite-developers] ACS permission structure

[Todd O. <to...@da...>]

Clayton,

I downloaded ACS 4.2 last night, since Ars Digita improved the structure
since the 3.x series.  Since it's in TCL, it's taking a little longer to
review than php or java projects.

I don't think we should have a group field in the main users table because
we need a more robust system.  That's why I like NT's access control lists
over the simple UNIX file permissions (owner, group, everyone).

Stay Tuned.

--Todd

Re: [Phpwebsite-developers] ACS permission structure

[clayton c. <cc...@ca...>]

Todd,
>
> I downloaded ACS 4.2 last night, since Ars Digita improved the structure
> since the 3.x series.  Since it's in TCL, it's taking a little longer to
> review than php or java projects.
>

for the most part, you can get a fairly good overview of the system by
reading the online docs (very good) at www.arsdigita.com/doc . there is a
section that details the design considerations and requirements for the
permissions system. also look in the tarball directory
acs/packages/acs-kernel/sql for the data model. this should give you a
jump-start.

clayton