| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It's not required since the id is in the concerts table too. That's what
links them together.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently the AdminPage is still responsible for updating changes to any
of the concerts, but I'd like to get that into their respective classes
too. That way the AdminPage will just be a simple class to handle the
layout of the page, while all the specific functionality is in their
own classes.
This is also the first step to be able to reuse the concerts table on
the public end of the site.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We originally had a more specified query, but simplified it to:
SELECT * FROM wpg_concerts LEFT JOIN wpg_venues ON ...;
But since both the concerts table and the venues table has a column id,
the concert id would be overwritten with the venue id. MySQL/MariaDB
does not allow columns with the same name in multiple tables when using
unqualified column names in the query.
So we need to be more explicit again.
I was hoping that the following would work:
SELECT wpg_concerts.*, wpg_venues.* FROM .... ;
I think MySQL/MariaDB would handle that, but now since php turns the
result into an array, where each key must be unique, this again
overwrites the concert id with the venue id.
So thus a more verbose specification of the columns was necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
These tables are no longer being used, so let's remove them and the code
to add them.
|
| |
|
|
| |
These are no longer in use, and have been replaced by the admin screens.
|
| |
|
|
|
| |
AdminPage now references the database only through the Concert (and
Venue) models.
|
| | |
|
| |
|
|
| |
To keep track of creation and modification times for each record.
|
| |
|
|
|
| |
No need to deactivate/activate plugin to get the right version of the
tables.
|
| |
|
|
|
|
| |
As a user can only be assigned to one role at the time, we remove the
current user from any role that they may have when clearing the
assignment.
|
| |
|
|
| |
It did not return any users, but a form so name it for what it does.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The original name did not make much sense. The function didn't return a
user, but a dropdown list of users, where the user currently holding the
given role for the given concert was preselected in the list.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace the table with hardcoded strings in the AdminPage class. This
makes it a pure presentation issue, while the statuses themselves are
just mnemonics.
There's one smell here, and that is that the status values and their
textual representation is split across two modules. (Values in Concert,
and textual representation in AdminPage.) This should probably be
addressed later by refactoring both into a separate AccredStatus class
or something.
|
| |
|
|
|
| |
This will trip up any existing records in the db, but that should not
matter, since we're changing how this entire stuff works now.
|
| |
|
|
| |
Clicking the buttons don't work quite yet.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of directly accessing the database with a custom query, we now
just use the Concert::find_concerts method to fetch the concerts that
are to be displayed.
This became much easier now that we don't rely on the extra concertlogs
table.
There's still stuff missing to be functionally equivalent to the old
code, but this should be a lot easier to get in place now.
|
| | |
|
| | |
|
| |
|
|
| |
It does not make sense to have anonymous venues nowhere.
|
| | |
|
| |
|
|
| |
Also make sure we explicitly set the venue attribute in the constructor.
|
| | |
|
| |
|
|
|
| |
It's initialized to an empty array if not specified, that should be good
enough, and don't trip up iterating over it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create more of the concerts used by tests into the wpSetupBeforeClass
hook.
|
| |
|
|
|
|
|
|
|
|
|
| |
The commit changes the way we populate the database for the tests by
creating more entries up front. This reduces the amount of duplicated
code between the tests, but also introduce some challenges.
As modifications to the database done in the wpSetUpBeforeClass hook
are not cleaned up automatically by the WP_PHPUnit framework, we also
have to add a wpTearDownAfterClass hook so anything we set up in this
class does not disturb any other tests in other classes.
|
| |
|
|
|
|
| |
Since we're using our own database tables, these are not cleaned by the
default WP_PHPUnit setup. To ensure that we start on a clean slate when
running the tests, clean the env before the tests are run.
|
| |
|
|
| |
There's no need to have a separate table (concertlogs) for these fields.
|
| | |
|
| | |
|
| |
|
|
|
| |
Reduce to one find_concerts function taking a filter to limit the
selection.
|
| | |
|
| |
|
|
| |
This must have been forgotten in the previous commit.
|
| | |
|
| | |
|
| |
|
|
|
| |
Now use a Concertlog object to render the correct subform instead of
messing with the db directly.
|
| |
|
|
|
|
| |
This allows us to instantiate a Concertlogs objects just as with Concert
and Venue objects. Also add a few instance methods to get the assigned
user for a given role, and get the role assigned to a given user.
|
| | |
|
| | |
|
| |
|
|
|
| |
Now queries the user from the concertlogs table instead of going by
generating a form that is thrown away.
|
