You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@vcl.apache.org by Josh Thompson <jo...@ncsu.edu> on 2011/10/26 21:58:19 UTC
deleting user group associated with a block allocation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just discovered a problem with deleting user groups that are associated with
a block allocation. The web interface will not let you delete a user group
that is associated with a block allocation. However, block allocation entries
are kept around forever, which means that any user groups that were used for a
block allocation can never be deleted. Obviously, this is bad.
There are a few ways we can deal with this. Block allocations have a status
field that is set to 'completed' when they are done. We could allow user
groups that are only associated with completed block allocations to be
deleted. But, then, we just lost some information. What information did we
lose? Probably the most useful information would be the user group name,
however, there are other attributes associated with user groups. Since the
membership of the user group could be modified, we can't count on that as
being accurate some time down the road. If it is important to keep the
information contained in the user group name, we could create another table
named usergrouparchive into which deleted user groups would be moved. Another
option is to just add a 'deleted' flag to the usergroup table that gets
toggled when we delete a user group instead of actually deleting the entry
from the table. That option introduces unique indexing issues because we
couldn't have a unique key on the usergroup name and affiliation.
So, I'd like to know people's thoughts. Please select which option you
prefer:
(1) I don't care about the name, just delete it from the table
(2) Archive deleted user group information to another table
(3) Use a 'deleted' flag so the entry isn't actually removed from the table
(4) Other - please specify
I like #1 best as I don't really think knowing the user group name buys us
that much down the road.
Thanks,
Josh
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk6oZl8ACgkQV/LQcNdtPQPLCACfRYUGxQUjXfdG+h+LgNYLt2Qg
NRsAn2pNM7NAIwePNE66mVyrp59VPjwI
=BkDl
-----END PGP SIGNATURE-----
Re: deleting user group associated with a block allocation
Posted by Alexander Patterson <al...@csueastbay.edu>.
1 most of the information that is lost isn't important and when they
need to make another block they can redo it. We don't do as many
blocks are you do, but 1 would be ideal.
On Wed, Oct 26, 2011 at 12:58 PM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I just discovered a problem with deleting user groups that are associated with
> a block allocation. The web interface will not let you delete a user group
> that is associated with a block allocation. However, block allocation entries
> are kept around forever, which means that any user groups that were used for a
> block allocation can never be deleted. Obviously, this is bad.
>
> There are a few ways we can deal with this. Block allocations have a status
> field that is set to 'completed' when they are done. We could allow user
> groups that are only associated with completed block allocations to be
> deleted. But, then, we just lost some information. What information did we
> lose? Probably the most useful information would be the user group name,
> however, there are other attributes associated with user groups. Since the
> membership of the user group could be modified, we can't count on that as
> being accurate some time down the road. If it is important to keep the
> information contained in the user group name, we could create another table
> named usergrouparchive into which deleted user groups would be moved. Another
> option is to just add a 'deleted' flag to the usergroup table that gets
> toggled when we delete a user group instead of actually deleting the entry
> from the table. That option introduces unique indexing issues because we
> couldn't have a unique key on the usergroup name and affiliation.
>
> So, I'd like to know people's thoughts. Please select which option you
> prefer:
>
> (1) I don't care about the name, just delete it from the table
> (2) Archive deleted user group information to another table
> (3) Use a 'deleted' flag so the entry isn't actually removed from the table
> (4) Other - please specify
>
> I like #1 best as I don't really think knowing the user group name buys us
> that much down the road.
>
> Thanks,
> Josh
> - --
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
>
> my GPG/PGP key can be found at pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
>
> iEYEARECAAYFAk6oZl8ACgkQV/LQcNdtPQPLCACfRYUGxQUjXfdG+h+LgNYLt2Qg
> NRsAn2pNM7NAIwePNE66mVyrp59VPjwI
> =BkDl
> -----END PGP SIGNATURE-----
>
--
Thanks,
Alex Patterson
User Support Services
Operating System Analyst
California State University, East Bay
RE: deleting user group associated with a block allocation
Posted by "Waldron, Michael H" <mw...@email.unc.edu>.
I like option 1 as well, don't care about the groups after block allocations are done. For repeating uses from semester to semester, we just flush the membership from class groups and load new users.
Mike Waldron
Systems Specialist
ITS Research Computing
University of North Carolina at Chapel Hill
CB 3420, ITS Manning, Rm 2509
919-962-9778
-----Original Message-----
From: Josh Thompson [mailto:josh_thompson@ncsu.edu]
Sent: Wednesday, October 26, 2011 3:58 PM
To: vcl-dev@incubator.apache.org; vcl-user@incubator.apache.org
Subject: deleting user group associated with a block allocation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I just discovered a problem with deleting user groups that are associated with
a block allocation. The web interface will not let you delete a user group
that is associated with a block allocation. However, block allocation entries
are kept around forever, which means that any user groups that were used for a
block allocation can never be deleted. Obviously, this is bad.
There are a few ways we can deal with this. Block allocations have a status
field that is set to 'completed' when they are done. We could allow user
groups that are only associated with completed block allocations to be
deleted. But, then, we just lost some information. What information did we
lose? Probably the most useful information would be the user group name,
however, there are other attributes associated with user groups. Since the
membership of the user group could be modified, we can't count on that as
being accurate some time down the road. If it is important to keep the
information contained in the user group name, we could create another table
named usergrouparchive into which deleted user groups would be moved. Another
option is to just add a 'deleted' flag to the usergroup table that gets
toggled when we delete a user group instead of actually deleting the entry
from the table. That option introduces unique indexing issues because we
couldn't have a unique key on the usergroup name and affiliation.
So, I'd like to know people's thoughts. Please select which option you
prefer:
(1) I don't care about the name, just delete it from the table
(2) Archive deleted user group information to another table
(3) Use a 'deleted' flag so the entry isn't actually removed from the table
(4) Other - please specify
I like #1 best as I don't really think knowing the user group name buys us
that much down the road.
Thanks,
Josh
- --
- -------------------------------
Josh Thompson
VCL Developer
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iEYEARECAAYFAk6oZl8ACgkQV/LQcNdtPQPLCACfRYUGxQUjXfdG+h+LgNYLt2Qg
NRsAn2pNM7NAIwePNE66mVyrp59VPjwI
=BkDl
-----END PGP SIGNATURE-----
Re: deleting user group associated with a block allocation
Posted by Alexander Patterson <al...@csueastbay.edu>.
1 most of the information that is lost isn't important and when they
need to make another block they can redo it. We don't do as many
blocks are you do, but 1 would be ideal.
On Wed, Oct 26, 2011 at 12:58 PM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I just discovered a problem with deleting user groups that are associated with
> a block allocation. The web interface will not let you delete a user group
> that is associated with a block allocation. However, block allocation entries
> are kept around forever, which means that any user groups that were used for a
> block allocation can never be deleted. Obviously, this is bad.
>
> There are a few ways we can deal with this. Block allocations have a status
> field that is set to 'completed' when they are done. We could allow user
> groups that are only associated with completed block allocations to be
> deleted. But, then, we just lost some information. What information did we
> lose? Probably the most useful information would be the user group name,
> however, there are other attributes associated with user groups. Since the
> membership of the user group could be modified, we can't count on that as
> being accurate some time down the road. If it is important to keep the
> information contained in the user group name, we could create another table
> named usergrouparchive into which deleted user groups would be moved. Another
> option is to just add a 'deleted' flag to the usergroup table that gets
> toggled when we delete a user group instead of actually deleting the entry
> from the table. That option introduces unique indexing issues because we
> couldn't have a unique key on the usergroup name and affiliation.
>
> So, I'd like to know people's thoughts. Please select which option you
> prefer:
>
> (1) I don't care about the name, just delete it from the table
> (2) Archive deleted user group information to another table
> (3) Use a 'deleted' flag so the entry isn't actually removed from the table
> (4) Other - please specify
>
> I like #1 best as I don't really think knowing the user group name buys us
> that much down the road.
>
> Thanks,
> Josh
> - --
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
>
> my GPG/PGP key can be found at pgp.mit.edu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
>
> iEYEARECAAYFAk6oZl8ACgkQV/LQcNdtPQPLCACfRYUGxQUjXfdG+h+LgNYLt2Qg
> NRsAn2pNM7NAIwePNE66mVyrp59VPjwI
> =BkDl
> -----END PGP SIGNATURE-----
>
--
Thanks,
Alex Patterson
User Support Services
Operating System Analyst
California State University, East Bay