its a many-to-many. We store project tags in IDF_Tag with a project
id "0" (this has minimal to no impact on existing code) and therefor
only need to ensure that the new relation table exists in the migration.
Then just the project summary configuration and the admin's project
create and project update forms and views needed to be adapted to
be able to render, create and update project tags.
table names and relations accordingly.
Start with a resource and resource revision model and add migrations for
that as well.
Note in NEWS.mdtext that we need a more recent Pluf version to take
advantage of the MySQL introspection implementation.
Changes with respect to the original patch:
- use Gconf instead of separate table / data scheme
- better form validation for URLs and emails
- no htmlentity-encoded contents in the database (pluf automatically safe-encodes
stuff before it writes out contents into templates)
- add visual separators in the form views to have a distinct view of basic
(important) data and other data which are only displayed in the public profile
- give a hint about the maximum display size of 60x60 px^2 and use max-width and
max-height in the templates to avoid nasty distortions by the browser
- use target=_blank and rel=nofollow on the twitter and website links in the profile
- some whitespace / formatting / code style fixes
to the same signal also for the initial setup, since the memberships
haven't been added at the time the create signal is thrown
* my array references goo was slightly stupid (the usage of foreach
is of course hazardous in cases like this)
* always insert a trailing new line in write-permissions and skip
read-in newlines from being processed
when new revisions arrive. this still needs some more tests, but
its a start.
- refactor out the monotonerc template from SyncMonotone.php and
place it in a separate template file (access control hooks are
still missing from there)
project creation and adds the new server to the running usher instance.
If everything goes well, the usher instance is told to reload its
configuration, so the new server / database is picked up and started
automatically.
We do not need to have the extra tags and modifiers in the configuration
as a signal is taking care of that. That way we can add new tags,
modifiers without the need to update the configuration settings.
We now have a limited support of the code review. Still some work to be
done to allow the submission of new patches on a given review and update
the status. For the moment, only pre-commit review is supported.
