phpgroupware-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Phpgroupware-users] New Users and Calendar questions


From: Brian Johnson
Subject: RE: [Phpgroupware-users] New Users and Calendar questions
Date: Thu, 05 Feb 2004 15:27:19 +0000

Don Graver (dgraver) (address@hidden) wrote:
>
> Thanks Dave.  What I will probably do is run a query on all the calendar 
> events and if a
> cal_user in the phpgw_cal_user database table is a group that the user was 
> assigned to,
> then I will update the phpgw_cal_user table to have that user added also.  
> Sounds like
> the easiest way to me.

That's the problem.  Calendar events are not stored with group id's.  When a
group is invited, the id's from the current members of that group are obtained
from the db.  Then info for each user id is obtained from the db (such as
whether they want to get email updates and what their email address is).  Then
the event is added to each user's calendar.  The group id is never saved!

So from the information that is available, there is no way to get the group id
of the original group that was invited.

There would still be the need to store a copy of the event for each user, but
you could look at also creating an additional calendar event for the group id

>
> As for Brian's response about every user wants to know the status of what 
> people are
> attending an event via email, I would think that is the reason for the the
> "Participants" field when a user views an event.
>

I'd didn't say every, I said some.  If we do away with the current action, you
can bet there will be someone wanting us to change it back.  So anything you
change should be provided as a user option that can be selected or not.

> I was also wondering if there is a way to shut down a site quickly?  In other 
> words lock
> out all users except for maybe admin, or block all IP addresses except 
> certain ones.  I
> know I can do the ip address through an htaccess, but was curious if it is 
> implemented
> anywhere else.

I see in the user admin pages that you can set an account as inactive.  If you
figure out what that does to the db tables, you could write a script to do
that using sql.

>
> Also, is there a quick way to kill all sessions except the one you are using 
> (i.e.
> admin).  We had a situation yesterday where I needed to have everyone logout 
> and
> re-login, and going through 50 current user sessions was a pain.  By the way, 
> I don't
> have root access on the hosted server unfortunately (don't ask)...so I 
> couldn't just
> remove the sess_ files with a 'rm' command since the apache server owned the 
> files.

This one I don't know

>
> By the way, does phpGW work with register_globals=off??  I think this was an 
> issue in
> the past.  I am using the xx.512 build I think...not sure...I haven't done 
> the latest
> cvs update since savannah went down a while back.
>

Some apps work with it off.  I think all the supported apps work.

> Thanks for the help.
>
> Don
> -----Original Message-----
> From: address@hidden on behalf of Dave Hall
> Sent: Thu 2/5/2004 9:48 AM
> To:   address@hidden
> Cc:
> Subject:      Re: [Phpgroupware-users] New Users and Calendar questions
> Brian Johnson <address@hidden> wrote:
>
> > Don Graver (dgraver) (address@hidden) wrote:
> > >
> > > I have a couple of questions that seem to have come up since
> > launching> my beta site.
> > >
> > > 1.  How do you add new users to an event without having an email
> > being> sent to all other users indicating you have "edited" the
> > event, but
> > > still emailing the new user that he has been invited?
> >
> > No.  It doesn't work that way
> >
> >
> > > 2.  When creating an entirely new user via the admin interface, and
> > > assigning that user to a particular group, should the new user's
> > > calendar be updated with all the events that the group was
> > invited to?
> >
> > No. It doesn't work that way.
>
> It is something that a few people have asked for, but is not easy to do.
>  Events are stored by uid, and no gid info is stored in the db.
> Changing it so gids are stored when a group is selected, instead of it
> being expanded to uids would be a great feature imho, but will cause a
> lot of changes in the code.
>
> Cheers
>
> Dave
>
>
>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]