The underlying structure makes use of foreign keys. During
the original design, we felt that it didn't make sense to
delete the companies in a production system because it would
require a cascade and delete all the history of any work
that might have been done to be deleted also.
Edit functionality hasn't been added yet. This can be edited
without adverse affects in phpMyAdmin.
Would you please elaborate what you mean by "existing data
clutter the administrative view". Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with your assumptions. However, our experience has
been that users get annoyed after a while, and request some
kind of archival/filter of older data.
I am supposing that, via permissions, I can ensure that users
do not even know that the companies exist.
"Clutter:" In the admin view, they are just data that don't
mean anything...
Is ther an acceptable way to get a "clean" database?
Perhaps the installation can have two modes, "demo"
and "live?" The second mode could have a few query screens
to get primary company and core users into it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with your assumptions. However, our experience has
been that users get annoyed after a while, and request some
kind of archival/filter of older data.
I am supposing that, via permissions, I can ensure that users
do not even know that the companies exist.
"Clutter:" In the admin view, they are just data that don't
mean anything...
Is ther an acceptable way to get a "clean" database?
Perhaps the installation can have two modes, "demo"
and "live?" The second mode could have a few query screens
to get primary company and core users into it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That was exactly how we were planning on 'hiding' unwanted
data - by revoking permissions to the company.
The permissions model actually assumes that you will start
by only associating a user with one company initially,
therefore they will not see the other companies until either
explicitly granted access to the company or granted admin
rights. Users will only see companies that they are
'members' of.
I'll gladly build you a clean database. Say just the admin
user and the necessary configuration data to get started and
log in? Is there anything that you either want to see or
specifically do NOT want to see in this 'live' database?
I'll build it specifically for you as long as it doesn't
violate the underlying foreign key requirements.
I like your suggestion on the 'demo' and 'live' modes and
will plan on implementing that. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are going to go to all of that effort, consider the
installation model that is used by some other apps that I have
used (Mambo, phpBB) that drive the install from a php
installation script. The installer loads the web onto the site
and then browses to the install page/directory.
Person installing gets a (series of) query window(s) that get
mandatory data (mySQL access info, config values), initial
data for system (in c-y-a, would that be primary company
info and primary sysadmin?), whatever ensures that the core
system runs w/o fault. They also have pages that check on
the PHP and MySQL config to ensure it is correct...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haven't had a chance to build an install script, so here is
the alternative. I have built the install scripts to load
data in two phases. First the base system without demo data
and then the demo data.
Check the readme that has been included.
Unzip the file in the install directory, replacing the
existing contents.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=844043
The underlying structure makes use of foreign keys. During
the original design, we felt that it didn't make sense to
delete the companies in a production system because it would
require a cascade and delete all the history of any work
that might have been done to be deleted also.
Edit functionality hasn't been added yet. This can be edited
without adverse affects in phpMyAdmin.
Would you please elaborate what you mean by "existing data
clutter the administrative view". Thanks.
Logged In: YES
user_id=951349
I agree with your assumptions. However, our experience has
been that users get annoyed after a while, and request some
kind of archival/filter of older data.
I am supposing that, via permissions, I can ensure that users
do not even know that the companies exist.
"Clutter:" In the admin view, they are just data that don't
mean anything...
Is ther an acceptable way to get a "clean" database?
Perhaps the installation can have two modes, "demo"
and "live?" The second mode could have a few query screens
to get primary company and core users into it.
Logged In: YES
user_id=951349
I agree with your assumptions. However, our experience has
been that users get annoyed after a while, and request some
kind of archival/filter of older data.
I am supposing that, via permissions, I can ensure that users
do not even know that the companies exist.
"Clutter:" In the admin view, they are just data that don't
mean anything...
Is ther an acceptable way to get a "clean" database?
Perhaps the installation can have two modes, "demo"
and "live?" The second mode could have a few query screens
to get primary company and core users into it.
Logged In: YES
user_id=844043
That was exactly how we were planning on 'hiding' unwanted
data - by revoking permissions to the company.
The permissions model actually assumes that you will start
by only associating a user with one company initially,
therefore they will not see the other companies until either
explicitly granted access to the company or granted admin
rights. Users will only see companies that they are
'members' of.
I'll gladly build you a clean database. Say just the admin
user and the necessary configuration data to get started and
log in? Is there anything that you either want to see or
specifically do NOT want to see in this 'live' database?
I'll build it specifically for you as long as it doesn't
violate the underlying foreign key requirements.
I like your suggestion on the 'demo' and 'live' modes and
will plan on implementing that. Thanks.
Logged In: YES
user_id=951349
If you are going to go to all of that effort, consider the
installation model that is used by some other apps that I have
used (Mambo, phpBB) that drive the install from a php
installation script. The installer loads the web onto the site
and then browses to the install page/directory.
Person installing gets a (series of) query window(s) that get
mandatory data (mySQL access info, config values), initial
data for system (in c-y-a, would that be primary company
info and primary sysadmin?), whatever ensures that the core
system runs w/o fault. They also have pages that check on
the PHP and MySQL config to ensure it is correct...
Logged In: YES
user_id=844043
Sorry for the delay.
Haven't had a chance to build an install script, so here is
the alternative. I have built the install scripts to load
data in two phases. First the base system without demo data
and then the demo data.
Check the readme that has been included.
Unzip the file in the install directory, replacing the
existing contents.
Revised installation scripts