xoops-trackers Mailing List for XOOPS Web Application System

Patches item #1019464, was opened at 2004-08-31 08:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1019464&group_id=41586

Category: XOOPS 2.0.x
Group: Patches
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre-Eric MENUET (pemen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extended renderldap function in class criteria

Initial Comment:
extended function to run with 'IN' SQL operator and 
others.

    function renderLDAP(){
        if ($this->operator == '>') $this->operator = '>=';
        if ($this->operator == '<') $this->operator = '<=';    
  	
    	if ($this->operator == '!=' || $this->operator == 
'<>')
    	{
    		$operator = '=';
        	$clause = "(!(" . $this->column . $operator . 
$this->value . "))";
    	}
        else
        {        	
	        if ($this->operator == 'IN')
	        {	        	
	        	$newvalue = str_replace(array('(',')'),'',
$this->value);        	
	        	$tab = explode(',',$newvalue);
	        	foreach ($tab as $uid)
	        	{
	        		$clause .= '(' . $this->column . '=' . $uid 
.')';
	        	}	 
	        	$clause = '(|' . $clause . ')';
	        }
	        else
	        	$clause = "(" . $this->column . 
$this->operator . $this->value . ")";
        }
		trigger_error('renderLDAP = '.$clause,
E_USER_NOTICE);	        	
        return $clause;
    }


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1019464&group_id=41586

Feature Requests item #1018218, was opened at 2004-08-28 12:35
Message generated for change (Comment added) made by matr8x
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: david folen (matr8x)
Assigned to: Nobody/Anonymous (nobody)
Summary: selective block theme removal/edit

Initial Comment:
ok.  There are certain times where in your overall 
site that you may want a block to be different from 
your overall style which usually involves border/
padding/tile differences.

Is there a way to add the option to selectively edit 
the display of title, border, padding,etc. of a 
particular block or at least the complete removal of 
style to a block.

Hope I explain enough that someone will understand 
what I mean.

----------------------------------------------------------------------

>Comment By: david folen (matr8x)
Date: 2004-08-30 04:04

Message:
Logged In: YES 
user_id=605738

Yes.  It's just not an intuitive way of adding simple html 
block(s) using the administive block interface.  Well at 
least one which you want special considerations beyond 
the current style/theme without hand editing files beyond 
the block interface.

----------------------------------------------------------------------

Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-30 03:24

Message:
Logged In: YES 
user_id=441189

The template editing interface _is_ available under the
blocks administration. And that's where the block markup
should be anyway, not in the theme.html file. It's not a
case of a missing feature, but of propper use of the
existing ones.

Herko

----------------------------------------------------------------------

Comment By: david folen (matr8x)
Date: 2004-08-29 17:26

Message:
Logged In: YES 
user_id=605738

Yes.  I'm aware this is available for editing the templates 
however, I was hoping of a way to do this in 
administrative interface under blocks.

When you start playing more with other templates and 
trying to get a certain look, this feature becomes more 
apparent.

----------------------------------------------------------------------

Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-29 05:39

Message:
Logged In: YES 
user_id=441189

This is already possible by moving all block markup to the
block templates, and have no block markup in the theme.html
and associated files.

Herko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Feature Requests item #1018218, was opened at 2004-08-28 18:35
Message generated for change (Comment added) made by herkocoomans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: david folen (matr8x)
Assigned to: Nobody/Anonymous (nobody)
Summary: selective block theme removal/edit

Initial Comment:
ok.  There are certain times where in your overall 
site that you may want a block to be different from 
your overall style which usually involves border/
padding/tile differences.

Is there a way to add the option to selectively edit 
the display of title, border, padding,etc. of a 
particular block or at least the complete removal of 
style to a block.

Hope I explain enough that someone will understand 
what I mean.

----------------------------------------------------------------------

>Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-30 09:24

Message:
Logged In: YES 
user_id=441189

The template editing interface _is_ available under the
blocks administration. And that's where the block markup
should be anyway, not in the theme.html file. It's not a
case of a missing feature, but of propper use of the
existing ones.

Herko

----------------------------------------------------------------------

Comment By: david folen (matr8x)
Date: 2004-08-29 23:26

Message:
Logged In: YES 
user_id=605738

Yes.  I'm aware this is available for editing the templates 
however, I was hoping of a way to do this in 
administrative interface under blocks.

When you start playing more with other templates and 
trying to get a certain look, this feature becomes more 
apparent.

----------------------------------------------------------------------

Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-29 11:39

Message:
Logged In: YES 
user_id=441189

This is already possible by moving all block markup to the
block templates, and have no block markup in the theme.html
and associated files.

Herko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Feature Requests item #1018909, was opened at 2004-08-30 09:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018909&group_id=41586

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: zoullou (zoullou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add color select at XoopsForm class

Initial Comment:
It will be great to have a XoopsFormSelectColor in
Xoops form class.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018909&group_id=41586

Feature Requests item #1018218, was opened at 2004-08-28 12:35
Message generated for change (Comment added) made by matr8x
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: david folen (matr8x)
Assigned to: Nobody/Anonymous (nobody)
Summary: selective block theme removal/edit

Initial Comment:
ok.  There are certain times where in your overall 
site that you may want a block to be different from 
your overall style which usually involves border/
padding/tile differences.

Is there a way to add the option to selectively edit 
the display of title, border, padding,etc. of a 
particular block or at least the complete removal of 
style to a block.

Hope I explain enough that someone will understand 
what I mean.

----------------------------------------------------------------------

>Comment By: david folen (matr8x)
Date: 2004-08-29 17:26

Message:
Logged In: YES 
user_id=605738

Yes.  I'm aware this is available for editing the templates 
however, I was hoping of a way to do this in 
administrative interface under blocks.

When you start playing more with other templates and 
trying to get a certain look, this feature becomes more 
apparent.

----------------------------------------------------------------------

Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-29 05:39

Message:
Logged In: YES 
user_id=441189

This is already possible by moving all block markup to the
block templates, and have no block markup in the theme.html
and associated files.

Herko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Feature Requests item #1005187, was opened at 2004-08-07 18:46
Message generated for change (Settings changed) made by herkocoomans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1005187&group_id=41586

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: phppp (phppp)
Assigned to: Nobody/Anonymous (nobody)
Summary: private message management

Initial Comment:
This is not talking about bugs but 

The private message management should have such 
features:

pagenav
order selectable
batch processing: delete, mark as read


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1005187&group_id=41586

Feature Requests item #1018218, was opened at 2004-08-28 18:35
Message generated for change (Comment added) made by herkocoomans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: david folen (matr8x)
Assigned to: Nobody/Anonymous (nobody)
Summary: selective block theme removal/edit

Initial Comment:
ok.  There are certain times where in your overall 
site that you may want a block to be different from 
your overall style which usually involves border/
padding/tile differences.

Is there a way to add the option to selectively edit 
the display of title, border, padding,etc. of a 
particular block or at least the complete removal of 
style to a block.

Hope I explain enough that someone will understand 
what I mean.

----------------------------------------------------------------------

>Comment By: Herko Coomans (herkocoomans)
Date: 2004-08-29 11:39

Message:
Logged In: YES 
user_id=441189

This is already possible by moving all block markup to the
block templates, and have no block markup in the theme.html
and associated files.

Herko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Feature Requests item #1018218, was opened at 2004-08-28 12:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: david folen (matr8x)
Assigned to: Nobody/Anonymous (nobody)
Summary: selective block theme removal/edit

Initial Comment:
ok.  There are certain times where in your overall 
site that you may want a block to be different from 
your overall style which usually involves border/
padding/tile differences.

Is there a way to add the option to selectively edit 
the display of title, border, padding,etc. of a 
particular block or at least the complete removal of 
style to a block.

Hope I explain enough that someone will understand 
what I mean.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1018218&group_id=41586

Bugs item #1017868, was opened at 2004-08-27 13:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1017868&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin menu lost on language change

Initial Comment:
I've checked this several times, in two machines, and
seen it consistently happen. If I change the language
of the site using the preferences option, the redirect
page shows a lot of notices indicating some language
constantes are already defined in the modinfo.php
language file. Then the admin interface changes
language ok, but the menus lose their defined content.
On mouseover, all they show is the "Preferences" setting.

Herko mentioned elsewhere this might be due to language
constants missing, but I checked with all language
constants correctly translated, and did it even with no
modules installed. At first I thought one of my modules
was faulty, but then I saw this happen with only the
System module in place.

The way out of this is simple in practical terms. You
go to preferences, change the theme and then change
back. The changing of the theme does whatever is
necessary to recover the menu options.

I've checked what happens in the cached adminmenu.php
file. It changes size, in one case, from 28k to 15k.
All menu options, instead of showing:

   moveLayerY(\Lxx\, currentY,event) ; popUpLxx();

show only

   shutdown()

This I checked in a 2.0.7 and in a 2.0.7.1 installation.

hsalazar

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1017868&group_id=41586

Feature Requests item #1017741, was opened at 2004-08-27 13:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017741&group_id=41586

Category: User Interface
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Highlight menu links to show where user is

Initial Comment:
It's really nice the way XOOPS uses the stylesheet to
present a clean and neat looking usermenu and main menu
with attractive roll over effects.  

However, when you click a link, the link does not
change to acknowledge that you are currently viewing
that part of the site.  It would be nice if the
stylesheet (and the system logic) allowed you to
specify another set of colours/options for the menu
links and those colours/options would be used for the
menu link that corresponds to the part of the site
you're currently viewing.  So if you're in the forums,
then the menu link for forums would look different from
all the other links, but different also from how the
rollover effect looks.

Thanks for reading,

--Julian



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017741&group_id=41586

Feature Requests item #1017438, was opened at 2004-08-27 04:12
Message generated for change (Comment added) made by jegelstaff
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017438&group_id=41586

Category: Administration
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow sys, module admin perms to be assigned direct to users

Initial Comment:
This is a related to another request I have made:  1017432.

Right now, XOOPS has no way of assigning permissions to
users directly.  You can "fake" it by making a group
with the permission you're concerned with and assigning
only one user to that group.  Essentially, you're
creating a group that acts as a permission container.

But that's a lot of fiddling around in the system to
accomplish something.  Instead of one step, assigning a
permission to a user, you have to go through three
steps:  make the group, assign the perm to the group,
assign the user to the group.  That's a real drag.

Also, if you are forced to use groups as permission
containers in this way, it can be a really confusing
thing for some sites.  Here's why:  Suppose you have a
lot of groups in your system already, but your existing
groups are being used as content containers -- they are
groups that are used to control what content users can
see, ie: what modules they can access, and what content
in those modules they can view.

If your site is full of content groups, then your
admins are used to working with a list of groups that
means something in terms of the org chart for your
company/club/department/whatever.  That's what groups
in your site *are*, they represent something about how
the real-life people in your organization deal with
each other in the real world, and through the groups
system, you're mapping those relationships onto your site.

So if you then use the groups system to create
permission containers, things get very confusing, since
all of a sudden there are special groups in the system
which have nothing to do with how your other groups
(and your real people) are organized.

The same is true in reverse.  If you've made a whole
bunch of groups in your system to control the
permissions people have to edit and administer things,
and then you go and create groups that control access
to content, you have the same confusion.

Essentially, I think the XOOPS group system is being
stretched in two directions:  it's both a content
control system, and a permission control system, and
for some sites, depending on how things are organized,
this can be a problem and confusing.  It would be best
in those cases to have the option of giving system
admin permissions, and ideally module admin permissions
too, directly to users.

I don't think the ability to give admin perms to groups
should be removed (I think handling content and
permission control both by groups can be very elegant
for some sites).  But I would really like to see the
ability to give admin perms directly to users.  It's a
missing feature for a lot of business uses to which
XOOPS could be put.

I don't see a big need for access permissions to be
given to users, though if it were possible, I'm sure a
use for that flexibility would be found by someone.

----------------------------------------------------------------------

>Comment By: Julian Egelstaff (jegelstaff)
Date: 2004-08-27 04:20

Message:
Logged In: YES 
user_id=1109439

If it becomes possible to assign permisisons to users
directly, then it would be very, very nice if it were
possible to restrict the groups on which those users could
use their admin permissions.  This is where this request
relates to request 1017432.  If the Edit User page had a
list of all the groups on it, then you could select a series
of groups in the list and then for each admin permission a
user had, they would only be able to execute that permission
in relation to the groups selected in the box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017438&group_id=41586

Feature Requests item #1017432, was opened at 2004-08-27 03:55
Message generated for change (Comment added) made by jegelstaff
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017432&group_id=41586

Category: Administration
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let certain users be admins of only certain groups

Initial Comment:
Right now, if someone has system admin access to the
Groups page, for instance, then they can edit the
permissions for all the groups, and alter user
memberships in all the groups.

Similarly, if someone has system admin access to the
Blocks page, then they can alter the block
configurations for all groups.

In sites with a large number of groups, and in which
you want to push administration tasks down the food
chain to power users in different departments, or
certain key managers, you need the ability to hand out
these kind of system admin tasks, but limit the scope
of these tasks to only certain groups in the system. 
(You don't want the manager of the Documentation group
being able to edit the permissions for the Programming
group, but she should be able to edit the permissions
for the Documentation group).

A suggested approach for implementation, as far as the
interface goes:  As part of the Modify/New Group page,
you could have a multi-select box of the groups in the
system.  For each system admin permission that this
group is given, the group can only use that permission
to modify settings related to the groups that are
selected in the multi-select box.


----------------------------------------------------------------------

>Comment By: Julian Egelstaff (jegelstaff)
Date: 2004-08-27 04:12

Message:
Logged In: YES 
user_id=1109439

This request is related to another request I have made:  1017438

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017432&group_id=41586

Feature Requests item #1017438, was opened at 2004-08-27 04:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017438&group_id=41586

Category: Administration
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow sys, module admin perms to be assigned direct to users

Initial Comment:
This is a related to another request I have made:  1017432.

Right now, XOOPS has no way of assigning permissions to
users directly.  You can "fake" it by making a group
with the permission you're concerned with and assigning
only one user to that group.  Essentially, you're
creating a group that acts as a permission container.

But that's a lot of fiddling around in the system to
accomplish something.  Instead of one step, assigning a
permission to a user, you have to go through three
steps:  make the group, assign the perm to the group,
assign the user to the group.  That's a real drag.

Also, if you are forced to use groups as permission
containers in this way, it can be a really confusing
thing for some sites.  Here's why:  Suppose you have a
lot of groups in your system already, but your existing
groups are being used as content containers -- they are
groups that are used to control what content users can
see, ie: what modules they can access, and what content
in those modules they can view.

If your site is full of content groups, then your
admins are used to working with a list of groups that
means something in terms of the org chart for your
company/club/department/whatever.  That's what groups
in your site *are*, they represent something about how
the real-life people in your organization deal with
each other in the real world, and through the groups
system, you're mapping those relationships onto your site.

So if you then use the groups system to create
permission containers, things get very confusing, since
all of a sudden there are special groups in the system
which have nothing to do with how your other groups
(and your real people) are organized.

The same is true in reverse.  If you've made a whole
bunch of groups in your system to control the
permissions people have to edit and administer things,
and then you go and create groups that control access
to content, you have the same confusion.

Essentially, I think the XOOPS group system is being
stretched in two directions:  it's both a content
control system, and a permission control system, and
for some sites, depending on how things are organized,
this can be a problem and confusing.  It would be best
in those cases to have the option of giving system
admin permissions, and ideally module admin permissions
too, directly to users.

I don't think the ability to give admin perms to groups
should be removed (I think handling content and
permission control both by groups can be very elegant
for some sites).  But I would really like to see the
ability to give admin perms directly to users.  It's a
missing feature for a lot of business uses to which
XOOPS could be put.

I don't see a big need for access permissions to be
given to users, though if it were possible, I'm sure a
use for that flexibility would be found by someone.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017438&group_id=41586

Feature Requests item #1017432, was opened at 2004-08-27 03:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017432&group_id=41586

Category: Administration
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let certain users be admins of only certain groups

Initial Comment:
Right now, if someone has system admin access to the
Groups page, for instance, then they can edit the
permissions for all the groups, and alter user
memberships in all the groups.

Similarly, if someone has system admin access to the
Blocks page, then they can alter the block
configurations for all groups.

In sites with a large number of groups, and in which
you want to push administration tasks down the food
chain to power users in different departments, or
certain key managers, you need the ability to hand out
these kind of system admin tasks, but limit the scope
of these tasks to only certain groups in the system. 
(You don't want the manager of the Documentation group
being able to edit the permissions for the Programming
group, but she should be able to edit the permissions
for the Documentation group).

A suggested approach for implementation, as far as the
interface goes:  As part of the Modify/New Group page,
you could have a multi-select box of the groups in the
system.  For each system admin permission that this
group is given, the group can only use that permission
to modify settings related to the groups that are
selected in the multi-select box.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017432&group_id=41586

Feature Requests item #1017424, was opened at 2004-08-27 03:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017424&group_id=41586

Category: Administration
Group: XOOPS 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assign/Remove permissions to/from multiple groups at once

Initial Comment:
If you have a lot of groups in your site, it is a real
pain to have to add (or remove) a permission to a whole
bunch of groups.  An example:  You've got a series of
private forums on your site.  You've configured your
forum module so that each group that needs its own
forum has one.  But now you also need to go to
System->Groups and pick each group and give each one
access to the Forum module.

Depending on the number of groups you have this is
either a slight pain in the neck, or totally mind numbing.

It would be great if you could pick a series of
permissions to assign (or remove) and then pick a
series of groups, and apply your permission selections
to those groups.

Related to this:  it would be nice if there were a
General Preference that controlled which groups
automatically receive access to a module when it is
installed (ie: a way to turn off the automatic
assigning of access rights to the Registered Users
group).  For some sites where users are highly
regimented into groups, we find we are always going
into the Registered Users group and removing the
default access permission that gets assigned there,
since all content in such sites is handed out based on
membership in specific groups.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017424&group_id=41586

Feature Requests item #1017053, was opened at 2004-08-26 13:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017053&group_id=41586

Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dennis Heltzel (dheltzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: xoopsModuleConfigUser

Initial Comment:
There should be a standard way to store user
preferences in Xoops core. Something like
xoopsModuleConfig but with settings saved for each user
(with a default value permitted).

This would require a new table with columns similar to
the existing configuration table plus the following info:

1) uid (obviously)
2) "security" info

The security info would be used to determine which
values a user can modify directly, which can be
modified only by an admin, and which are only modified
programmatically (by custom code in the modules that
define them).

These user modifiable settings could then be
automatically displayed and edited in the view/edit
pages. This would nicely handle the often requested
ability to change the fields on these pages.

Preferences that are only admin modifiable could be
used for rank info for example.

Those prefs that are only modified by the module code
could store module preferences that simple remember the
last settings for a user, for example.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1017053&group_id=41586

Patches item #1015560, was opened at 2004-08-24 17:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1015560&group_id=41586

Category: XOOPS 2.0.x
Group: Patches
Status: Open
Resolution: None
Priority: 5
Submitted By: phppp (phppp)
Assigned to: Nobody/Anonymous (nobody)
Summary: better rendering [ code ][ /code ]

Initial Comment:
in class/module.textsanitizer.php, use:
--------------------------------------

	function codeConv($text, $xcode = 1, $image 
= 1){
		if($xcode != 0){
			$patterns = "/\[code](.*)
\[\/code\]/esU";
			if ($image != 0) {
				// image allowed
				$replacements 
= "'<pre 
class=\xoopsCode\>'.MyTextSanitizer::codeSanitizer
('$1').'</pre>'"; // hack for [code] rendering by <pre> -- 
phppp
				//$text =& $this-
>xoopsCodeDecode($text);
			} else {
				// image not 
allowed
				$replacements 
= "'<pre 
class=\xoopsCode\>'.MyTextSanitizer::codeSanitizer
('$1', 0).'</pre>'"; // hack for [code] rendering by 
<pre> -- phppp
				//$text =& $this-
>xoopsCodeDecode($text, 0);
			}
			$text =  preg_replace
($patterns, $replacements, $text);
		}
		return $text;
	}


then add following to xoops.css or 
themes/yourtheme/style.css, styleNN.css, styleMAC.css 
-----------------------------------------------
pre.xoopscode {
	background: #fffff8;
	border: 1px solid #6C87B0;
	color: #385a72;
	width: 500px;	
	height: 200px;
	margin: 1em;
	overflow: auto;
	padding: 3px 6px 6px 6px;
}


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1015560&group_id=41586

Bugs item #1014203, was opened at 2004-08-23 18:15
Message generated for change (Comment added) made by domifara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: toshimitsu (domifara)
Assigned to: Nobody/Anonymous (nobody)
Summary: xoops2.0.7.1 "Administration Menu" link of "user menu"

Initial Comment:
xoops2.0.7.1 "Administration Menu" link of "user menu" 

not what happens is that this menu became "context-
sensitive".

It is if it is why.
As for $xoops_isadmin, the value is set by 
$xoopsUserIsAdmin.

Related sauce 
include/common.php line 220
$xoopsUserIsAdmin = $xoopsUser->isAdmin();

and 
assign 

header.php about line 91 etc

$xoopsTpl->assign(array('xoops_isuser' => 
true, 'xoops_userid' => $xoopsUser->getVar
('uid'), 'xoops_uname' => $xoopsUser->getVar
('uname'), 'xoops_isadmin' => $xoopsUserIsAdmin));

---------
It is if you want to make it "context-sensitive."
I think that a change of include/common.php  should 
also be made.

maybe 
 In include/common.php  the last place

Changing is also set to "context-sensitive" like add lines
-----------
	if (is_object($xoopsUser)) {
		$xoopsUserIsAdmin = $xoopsUser-
>isAdmin();
	}
-----------

----------------------------------------------------------------------

>Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:14

Message:
Logged In: YES 
user_id=926983

OK, I'll take care of this one personally. 

----------------------------------------------------------------------

Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:14

Message:
Logged In: YES 
user_id=926983

Thank you jegelstaff
I investigated and looked at . 
Although the condition which is writing is different
However, it was surmised that a cause was the same. 
Surely, the condition like [1109439] is also caused.
Is it better to set this report status to "close"?  

----------------------------------------------------------------------

Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:08

Message:
Logged In: YES 
user_id=926983

OK, I'll take care of this one personally. 

----------------------------------------------------------------------

Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:08

Message:
Logged In: YES 
user_id=926983

Thank you jegelstaff
I investigated and looked at . 
Although the condition which is writing is different
However, it was surmised that a cause was the same. 
Surely, the condition like [1109439] is also caused.
Is it better to set this report status to "close"?  

----------------------------------------------------------------------

Comment By: Julian Egelstaff (jegelstaff)
Date: 2004-08-24 00:15

Message:
Logged In: YES 
user_id=1109439

I think this is talking about the same thing I talk about
in: 1014403

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Bugs item #1014203, was opened at 2004-08-23 18:15
Message generated for change (Comment added) made by domifara
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: toshimitsu (domifara)
Assigned to: Nobody/Anonymous (nobody)
Summary: xoops2.0.7.1 "Administration Menu" link of "user menu"

Initial Comment:
xoops2.0.7.1 "Administration Menu" link of "user menu" 

not what happens is that this menu became "context-
sensitive".

It is if it is why.
As for $xoops_isadmin, the value is set by 
$xoopsUserIsAdmin.

Related sauce 
include/common.php line 220
$xoopsUserIsAdmin = $xoopsUser->isAdmin();

and 
assign 

header.php about line 91 etc

$xoopsTpl->assign(array('xoops_isuser' => 
true, 'xoops_userid' => $xoopsUser->getVar
('uid'), 'xoops_uname' => $xoopsUser->getVar
('uname'), 'xoops_isadmin' => $xoopsUserIsAdmin));

---------
It is if you want to make it "context-sensitive."
I think that a change of include/common.php  should 
also be made.

maybe 
 In include/common.php  the last place

Changing is also set to "context-sensitive" like add lines
-----------
	if (is_object($xoopsUser)) {
		$xoopsUserIsAdmin = $xoopsUser-
>isAdmin();
	}
-----------

----------------------------------------------------------------------

>Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:08

Message:
Logged In: YES 
user_id=926983

OK, I'll take care of this one personally. 

----------------------------------------------------------------------

Comment By: toshimitsu (domifara)
Date: 2004-08-24 08:08

Message:
Logged In: YES 
user_id=926983

Thank you jegelstaff
I investigated and looked at . 
Although the condition which is writing is different
However, it was surmised that a cause was the same. 
Surely, the condition like [1109439] is also caused.
Is it better to set this report status to "close"?  

----------------------------------------------------------------------

Comment By: Julian Egelstaff (jegelstaff)
Date: 2004-08-24 00:15

Message:
Logged In: YES 
user_id=1109439

I think this is talking about the same thing I talk about
in: 1014403

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Bugs item #1014577, was opened at 2004-08-23 12:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014577&group_id=41586

Category: Modules - News
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Image Manager (Alignment)

Initial Comment:
In the image manager when adding an image.

There's a three option beside it:

Align it left, center and right buttons.

None of those option or functions work.

As I can see the links of all three are the same.


Image Alignment not working!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014577&group_id=41586

Bugs item #1014438, was opened at 2004-08-23 08:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014438&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin popup menu when mouse over.

Initial Comment:
I dunno if this does the problem to any other browser or 
just internet explorer 6

All I see when I mouse over the modules the menu 
popup and sometimes it appear at the top and the 
browser hide it. The more modules installed the worst 
menu will popup ended up at the top top top. Can't see 
it.

I suggest you make the menu static to the icon when 
mouse over it (just beside it by not just set the menu 
will appear by percentage or honrizontal center of the 
vertical modules listed down.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014438&group_id=41586

Bugs item #1014432, was opened at 2004-08-23 08:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014432&group_id=41586

Category: Modules - Forum
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Message box

Initial Comment:
Firstly the forum has a bug on adding text or word to 
the message box.

In the comment like in the news one, it work well by 
adding word with bold, italic and colors to the message 
box. I mean if I have the whole text full of messages 
and want to add a word or sentences with bold and 
color between the message or middle of the message 
(All I do is click where I want the text to be add in) 
then I click add.

But in the forum it doesn't do it, I made the same step 
like in the news comment and word or sentences always 
ended up at the end of the messages and I have to 
drag it up or copy paste.

Some of my members or guest are confused by adding 
test and did not know where did it go and it's at the 
bottom of the messages.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014432&group_id=41586

Bugs item #1014203, was opened at 2004-08-23 05:15
Message generated for change (Comment added) made by jegelstaff
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: toshimitsu (domifara)
Assigned to: Nobody/Anonymous (nobody)
Summary: xoops2.0.7.1 "Administration Menu" link of "user menu"

Initial Comment:
xoops2.0.7.1 "Administration Menu" link of "user menu" 

not what happens is that this menu became "context-
sensitive".

It is if it is why.
As for $xoops_isadmin, the value is set by 
$xoopsUserIsAdmin.

Related sauce 
include/common.php line 220
$xoopsUserIsAdmin = $xoopsUser->isAdmin();

and 
assign 

header.php about line 91 etc

$xoopsTpl->assign(array('xoops_isuser' => 
true, 'xoops_userid' => $xoopsUser->getVar
('uid'), 'xoops_uname' => $xoopsUser->getVar
('uname'), 'xoops_isadmin' => $xoopsUserIsAdmin));

---------
It is if you want to make it "context-sensitive."
I think that a change of include/common.php  should 
also be made.

maybe 
 In include/common.php  the last place

Changing is also set to "context-sensitive" like add lines
-----------
	if (is_object($xoopsUser)) {
		$xoopsUserIsAdmin = $xoopsUser-
>isAdmin();
	}
-----------

----------------------------------------------------------------------

Comment By: Julian Egelstaff (jegelstaff)
Date: 2004-08-23 11:15

Message:
Logged In: YES 
user_id=1109439

I think this is talking about the same thing I talk about
in: 1014403

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014203&group_id=41586

Bugs item #1014408, was opened at 2004-08-23 11:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014408&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: XoopsGroupPermForm forms req. sys admin rights to use

Initial Comment:
If your module has a group permission form generated
from the XOOPS api (XoopsGroupPermForm), the form
cannot be used except by users with system admin
permissions.  If a user has admin perm for the module
but no sys admin rights, then the get a message saying
they don't have permission when they submit the form.

This has been replicated several times in the
Formulaire module.

It seems that as long as one sys admin right is
present, the form works (we give similies rights to
make this work).

What ought to happen:  As long as you have module admin
rights on the module that has the form, then you should
be able to submit the form.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014408&group_id=41586

Bugs item #1014403, was opened at 2004-08-23 11:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014403&group_id=41586

Category: Core -  Core
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Julian Egelstaff (jegelstaff)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin Menu link has no text but is present

Initial Comment:
1.  A user has admin rights on some but not all modules
on a site.  User also has at least one system admin
right (in our case it's smilies).

2.  User logs in, views content in a module where they
have admin rights.  The admin menu link in the user
menu shows up just like normal.  No problem.

3.  User views content in a module where they have no
admin rights.  The admin menu link in the user menu is
still there, but it has no text (based on the theme
used in our site, this results in a thin, text-free,
box in the user menu which is clickable and which takes
the user to the admin menu.

==========

What ought to happen...?

Option 1:  The admin menu link disappears completely
when viewing content in modules that the user has no
admin rights for.

Option 2 (preferred):  The admin menu link is always
visible as long as the user has some admin rights
somewhere in the system.  They ought to be able to
click through to the admin menu at any point in time
since they may decide they are done whatever they are
doing and need to do some admin task now, and their
ability to follow through on wanting to do the admin
task shouldn't be restricted by the fact they may or
may not have admin rights in the particular module they
are viewing at that moment.

To put it another way, the admin menu itself only lets
a user access things they are able to admin, so why
remove the link to the menu based on which module the
user is viewing currently?  It's not a security issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1014403&group_id=41586