| 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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
No functional change, just trying to make sense of it.
|
| |
|
|
|
| |
Also add a `get_status` method to the Concertlogs class, returning the
press status for a given concert_id.
|
| | |
|
