headers
Raymond Mancy | 7 Apr 2010 03:08
Picon
Favicon

Group ownership of systems

We have a ticket open which details the need to set the ownership of a system by the group.

Currently, all the code relevant to system ownership (and the actions allowed because of that ownership)
revolves around
the user as the owner.

The areas I can think of that would be affected by such a change are
*Changing system ownership
*Loaning the system
*Changing system details
*All searches related to system owner

Some other I've missed ?

I can think of a couple of ways to go about changing

1)Explicitly allow group ownership.
   By this I mean being able to enter in a group name in any field which would have previously asked for a user name.
   This could be problematic and not very intuitive. Do we have 'group owner' and a 'user owner' field? Are they
mutually exclusive? etc etc
   The relationship of System.owner would have to change as well.If we want to contact an owner of a machine how
do we do that if it's owned by a group?

2)Allow the owner's group to have owner'esque privileges
   Allow the owner of a machine to give full ownership rights to their group, or allow them to specify a group.
   Need to add a field in the DB.
   The code changes for this would be simpler. Searches wouldn't have to be modified (maybe addition of a
System/GroupOwner could be added).
   System would still have a single user who would ultimately be responsible for the machine.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bill Peck | 12 Apr 2010 21:59
Picon
Favicon

distro search and tags


Hello Raymond,

I made a quick fix for displaying a distro when starting from the tags 
list.  It was generating a link like this:

/distros/tagsearch/view?id=123

When it should be

/distros/view?id=123

My bigger question is should we merge the tag searching into the distro 
search proper?  I think the answer is yes.
Permalink | Reply | 0 comments |
headers
Bill Peck | 12 Apr 2010 22:09
Picon
Favicon

Re: Group ownership of systems

On 04/06/2010 09:08 PM, Raymond Mancy wrote:
> We have a ticket open which details the need to set the ownership of a system by the group.
>
> Currently, all the code relevant to system ownership (and the actions allowed because of that ownership)
revolves around
> the user as the owner.
>
> The areas I can think of that would be affected by such a change are
> *Changing system ownership
> *Loaning the system
> *Changing system details
> *All searches related to system owner
>
> Some other I've missed ?
>
> I can think of a couple of ways to go about changing
>
> 1)Explicitly allow group ownership.
>     By this I mean being able to enter in a group name in any field which would have previously asked for a user name.
>     This could be problematic and not very intuitive. Do we have 'group owner' and a 'user owner' field? Are
they mutually exclusive? etc etc
>     The relationship of System.owner would have to change as well.If we want to contact an owner of a machine
how do we do that if it's owned by a group?
>
> 2)Allow the owner's group to have owner'esque privileges
>     Allow the owner of a machine to give full ownership rights to their group, or allow them to specify a group.
>     Need to add a field in the DB.
>     The code changes for this would be simpler. Searches wouldn't have to be modified (maybe addition of a
System/GroupOwner could be added).
>     System would still have a single user who would ultimately be responsible for the machine.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Raymond Mancy | 13 Apr 2010 02:18
Picon
Favicon

Re: distro search and tags


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: Beaker-devel <at> lists.fedorahosted.org
> Sent: Tuesday, April 13, 2010 5:59:59 AM GMT +10:00 Brisbane
> Subject: [Beaker-devel] distro search and tags
>
> Hello Raymond,
> 
> I made a quick fix for displaying a distro when starting from the tags
> 
> list.  It was generating a link like this:
> 
> /distros/tagsearch/view?id=123
> 
> When it should be
> 
> /distros/view?id=123
> 

Ugh, yes. Right you are.

> 
> My bigger question is should we merge the tag searching into the
> distro 
> search proper?  I think the answer is yes.
> 

Yeah I don't see any reason not to. Unless of course there is high demand for having quick access
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond Mancy | 13 Apr 2010 05:30
Picon
Favicon

Creating user prefs.

As part of a ticket open to give users the preference of changing the default pagination setting in the
system search,
I've decided to create a new table which will store all user preferences. At the moment the only user
preferences (email and display name)
are in the main tg_user table. 

As the potential preferences could grow quite large I thought we should move all that out into a new user
preferences table which has a FK relationship
to the tg_user table.

Should we just add all the future preferences (and I can see there being a lot) into the current tg_user table?

Cheers
Raymond
Permalink | Reply | 2 comments |
headers
Jeff Burke | 13 Apr 2010 14:12
Picon
Favicon

Re: Creating user prefs.

Raymond Mancy wrote:
> As part of a ticket open to give users the preference of changing the default pagination setting in the
system search,
> I've decided to create a new table which will store all user preferences. At the moment the only user
preferences (email and display name)
> are in the main tg_user table. 
> 
> As the potential preferences could grow quite large I thought we should move all that out into a new user
preferences table which has a FK relationship
> to the tg_user table.
> 
> Should we just add all the future preferences (and I can see there being a lot) into the current tg_user table?
> 
> Cheers
> Raymond
Raymond,
	I believe there is a BZ on this already. But one thing that would be 
good is to have a unique password. What I mean by that if I Take a 
machine or reserve a a system. I would like the default password to be 
unique. I do not want the default set by the system.

Thanks,
Jeff
Permalink | Reply | 0 comments |
headers
Jeff Burke | 13 Apr 2010 14:13
Picon
Favicon

Re: Group ownership of systems

Bill Peck wrote:
> On 04/06/2010 09:08 PM, Raymond Mancy wrote:
>> We have a ticket open which details the need to set the ownership of a system by the group.
>>
>> Currently, all the code relevant to system ownership (and the actions allowed because of that
ownership) revolves around
>> the user as the owner.
>>
>> The areas I can think of that would be affected by such a change are
>> *Changing system ownership
>> *Loaning the system
>> *Changing system details
>> *All searches related to system owner
>>
>> Some other I've missed ?
>>
>> I can think of a couple of ways to go about changing
>>
>> 1)Explicitly allow group ownership.
>>     By this I mean being able to enter in a group name in any field which would have previously asked for a user name.
>>     This could be problematic and not very intuitive. Do we have 'group owner' and a 'user owner' field? Are
they mutually exclusive? etc etc
>>     The relationship of System.owner would have to change as well.If we want to contact an owner of a machine
how do we do that if it's owned by a group?
>>
>> 2)Allow the owner's group to have owner'esque privileges
>>     Allow the owner of a machine to give full ownership rights to their group, or allow them to specify a group.
>>     Need to add a field in the DB.
>>     The code changes for this would be simpler. Searches wouldn't have to be modified (maybe addition of a
System/GroupOwner could be added).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marian Csontos | 13 Apr 2010 15:55
Picon
Favicon

beaker-stage machines

Hi folks, (Kevin correct me where I am wrong please)
please, do not use machines from beaker-stage for anything else but 
testing beaker and its compatibility with rhts tests.
For ordinary work there is still inventory and rhts.

Especially *do not reserve machines* via Scheduler > Reserve nor System 
 > (Take). These work and do not need much more testing.
If you feel strongly towards testing this functionality, go on, but 
return the machines ASAP - that means right after successful/failed 
installation.

Thanks a lot,

-- Marian
Permalink | Reply | 1 comment |
headers
Kevin Baker | 13 Apr 2010 19:32
Picon
Favicon

Re: beaker-stage machines

On Tue, Apr 13, 2010 at 03:55:55PM +0200, Marian Csontos wrote:
> Hi folks, (Kevin correct me where I am wrong please)
> please, do not use machines from beaker-stage for anything else but
> testing beaker and its compatibility with rhts tests.
> For ordinary work there is still inventory and rhts.
>
> Especially *do not reserve machines* via Scheduler > Reserve nor
> System > (Take). These work and do not need much more testing.
> If you feel strongly towards testing this functionality, go on, but
> return the machines ASAP - that means right after successful/failed
> installation.
> 
> Thanks a lot,

I agree. People, please do /not/ camp on machines in beaker-stage. 
If we find people doing that we will kick you off.

--

-- 
Kevin Baker
Manager Engineering Operations, Westford          +1 978 392 2442
Permalink | Reply | 0 comments |
headers
Kevin Baker | 13 Apr 2010 21:46
Picon
Favicon

Re: Creating user prefs.

On Mon, Apr 12, 2010 at 11:30:43PM -0400, Raymond Mancy wrote:
> As part of a ticket open to give users the preference of changing
> the default pagination setting in the system search, I've decided
> to create a new table which will store all user preferences. At
> the moment the only user preferences (email and display name)
> are in the main tg_user table.
> 
> As the potential preferences could grow quite large I thought we
> should move all that out into a new user preferences table which
> has a FK relationship to the tg_user table.

you could code up a user preferences object that would initially be
hardcoded with all the values. Then over time you can allow users to set
them via a UI. But then you don't have to go through all the places in
the code and convert set_pagination(rows=50) since you've already future
proofed yourself with set_pagination(rows=User.Prefs.pagination_rows).

> Should we just add all the future preferences (and I can see there
> being a lot) into the current tg_user table?
> 
> Cheers Raymond _______________________________________________
> Beaker-devel mailing list Beaker-devel <at> lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/beaker-devel

--

-- 
Kevin Baker
Manager Engineering Operations, Westford          +1 978 392 2442
Permalink | Reply | 0 comments |

Gmane