1
0
mirror of https://github.com/flarum/core.git synced 2025-07-18 23:31:17 +02:00
Commit Graph

56 Commits

Author SHA1 Message Date
Toby Zerner
d806c4491d Fix regression in permission logic: make sure admins can do everything 2015-11-04 09:27:06 +10:30
Toby Zerner
90def3f0db Fix permissions being incorrectly granted 2015-11-01 09:38:25 +10:30
Toby Zerner
415b68f84f Add flood control
closes #271
2015-10-22 16:57:48 +10:30
Toby Zerner
c08b62af80 Refactor translation and validation
We now use Symfony's Translation component. Yay! We get more powerful pluralisation and better a fallback mechanism. Will want to implement the caching mechanism at some point too. The API is replicated in JavaScript, which could definitely use some testing.

Validators have been refactored so that they are decoupled from models completely (i.e. they simply validate arrays of user input). Language packs should include Laravel's validation messages.

ref #267
2015-10-15 22:30:45 +10:30
Toby Zerner
dd67291ce0 Major refactor and improvements
- Reorganised all namespaces and class names for consistency and structure. Following PSR bylaws (Abstract prefix, Interface/Trait suffix).
  - Move models into root of Core, because writing `use Flarum\Core\Discussion` is nice. Namespace the rest by type. (Namespacing by entity was too arbitrary.)
  - Moved some non-domain stuff out of Core: Database, Formatter, Settings.
  - Renamed config table and all references to "settings" for consistency.
  - Remove Core class and add url()/isInstalled()/inDebugMode() as instance methods of Foundation\Application.
  - Cleanup, docblocking, etc.

- Improvements to HTTP architecture
  - API and forum/admin Actions are now actually all the same thing (simple PSR-7 Request handlers), renamed to Controllers.
  - Upgrade to tobscure/json-api 0.2 branch.
  - Where possible, moved generic functionality to tobscure/json-api (e.g. pagination links). I'm quite happy with the backend balance now re: #262

- Improvements to other architecture
  - Use Illuminate's Auth\Access\Gate interface/implementation instead of our old Locked trait. We still use events to actually determine the permissions though. Our Policy classes are actually glorified event subscribers.
  - Extract model validation into Core\Validator classes.
  - Make post visibility permission stuff much more efficient and DRY.

- Renamed Flarum\Event classes for consistency. ref #246
  - `Configure` prefix for events dedicated to configuring an object.
  - `Get` prefix for events whose listeners should return something.
  - `Prepare` prefix when a variable is passed by reference so it can be modified.
  - `Scope` prefix when a query builder is passed.

- Miscellaneous improvements/bug-fixes. I'm easily distracted!
  - Increase default height of post composer.
  - Improve post stream redraw flickering in Safari by keying loading post placeholders with their IDs. ref #451
  - Use a PHP JavaScript minification library for minifying TextFormatter's JavaScript, instead of ClosureCompilerService (can't rely on external service!)
  - Use UrlGenerator properly in various places. closes #123
  - Make Api\Client return Response object. closes #128
  - Allow extensions to specify custom icon images.
  - Allow external API/admin URLs to be optionally specified in config.php. If the value or "url" is an array, we look for the corresponding path inside. Otherwise, we append the path to the base URL, using the corresponding value in "paths" if present. closes #244
2015-10-08 14:28:02 +10:30
Franz Liedke
559110a83f Coding standards 2015-08-27 01:40:18 +02:00
Toby Zerner
0b8aa5c124 Add header comment; PSR-2 fixes; remove seeders 2015-08-26 16:56:32 +09:30
Toby Zerner
e091b037f3 Radically simplify user activity system
The activity system we were using was built around a separate table.
Whenever the user posted something, or deleted a post, we would sync
the table. The advantage of this was that we could aggregate activity
of all different types very efficiently.

It turns out that it came with a huge disadvantage: there was no
efficient way to enforce permissions on activity. If a user posted
something in a private tag, everyone could still see it on their
activity feed. My stopgap solution was to only sync activity for posts
that are viewable by guests, but that was way too limited.

It also turns out that aggregating activity of different types is
really not that useful, especially considering most of it is the user
making posts. So I've gotten rid of that whole overly-complicated
system, and just made the user profile display separate lists of posts
and discussions, retrieved from those respective APIs. The discussions
page is an actual discussion list too, which is pretty cool.

It's still technically possible to aggregate different activity types
(basically just aggregate API responses together), but we can do that
later if there's a need for it.

This is probably my favourite commit of the day :)
2015-08-04 18:44:22 +09:30
Toby Zerner
cea8e7f567 Add group management actions to API 2015-07-31 20:10:49 +09:30
Toby Zerner
19fe138770 Change order of bootstrapping
See commit on flarum/flarum for explanation
2015-07-20 18:01:08 +09:30
Toby Zerner
57650fa648 Rework public API based on events 2015-07-18 22:59:47 +09:30
Franz Liedke
31e9f44dfb Rename caching setting repository implementation
I'm foreseeing another implementation that uses real caching (across requests).
2015-07-16 00:10:52 +02:00
Franz Liedke
6a7889934c Register database and cache implementations as binding for the settings repository 2015-07-15 23:54:56 +02:00
Toby Zerner
53e269fd89 Extract model validation into a trait
Also use Laravel’s ValidationException rather than our own custom one
2015-07-05 12:25:08 +09:30
Toby Zerner
a74b40fe47 Massive refactor
- Use contextual namespaces within Flarum\Core
- Clean up and docblock everything
- Refactor Activity/Notification blueprint stuff
- Refactor Formatter stuff
- Refactor Search stuff
- Upgrade to JSON-API 1.0
- Removed “addedPosts” and “removedPosts” relationships from discussion
API. This was used for adding/removing event posts after renaming a
discussion etc. Instead we should make an additional request to get all
new posts

Todo:
- Fix Extenders and extensions
- Get rid of repository interfaces
- Fix other bugs I’ve inevitably introduced
2015-07-04 12:24:48 +09:30
Toby Zerner
56932604db Refactor CoreServiceProvider
A good start I think, but still some work to do. If we go ahead with
https://github.com/flarum/core/issues/132#issuecomment-117507974 (which
I am in favour of), we can extract the entity-related stuff into some
smaller service providers (e.g. discussion repo, an event listener,
permissions, and gambits stuff could all go in
Flarum\Core\Discussions\DiscussionsServiceProvider).
2015-07-01 22:34:11 +09:30
Toby Zerner
b4dcc02520 Give author permission to delete discussion if there are no replies
Forgot to commit this part in 64e5d50533
:3
2015-06-24 09:13:54 +09:30
Toby Zerner
6db3bd9178 Refactor some APIs 2015-06-18 12:45:14 +09:30
Toby Zerner
9cb257e11d Update core permissions stuff 2015-06-18 12:38:24 +09:30
Toby Zerner
b91ca93e09 Fix LoginWithCookie middleware being ineffective
Flarum\Support\Actor needs to be a singleton. There is a comment in
LoginWithHeader - is there a better approach to the whole Actor thing?
2015-06-17 12:47:49 +09:30
Franz Liedke
1cbc60ca41 Merge branch 'master' into psr-7
Conflicts:
	src/Api/Actions/Discussions/IndexAction.php
	src/Api/Actions/SerializeAction.php
	src/Core/Formatter/FormatterManager.php
	src/Extend/ForumAssets.php
	src/Forum/Actions/IndexAction.php
	src/Forum/ForumServiceProvider.php
2015-06-17 00:52:50 +02:00
Franz Liedke
33d663bc8e Revamp routing
All routes are now stored in a RouteCollection, which is then used
for dispatching by the (reusable) RouterMiddleware.

This change also entails moving all routes to the service providers.
This may be changed again later, and is done for convenience reasons
right now.
2015-06-17 00:16:35 +02:00
Toby Zerner
f0df751465 Overhaul permissions
Get rid of Permissible - too complex and inefficient. Replace with:
- a “Locked” trait which works similarly but only evaluates logic on
hydrated models.
- a “VisibleScope” trait which also works similarly but only scopes
queries

This is all we need, Permissible is overkill. There is only one
instance where we have to duplicate some logic
(Discussion::scopeVisiblePosts and Post::allow(‘view’, …)) but it’s
barely anything.

Haven’t decoupled for now, we can definitely look at doing that later.

Permissions table seeder slightly updated.

Also did a bit of a query audit, there’s still a lot to be done but
it’s much better than it was. Some relatively low-hanging fruit
detailed in EloquentPostRepository.
2015-06-16 17:33:56 +09:30
Toby Zerner
8b162344cd Lay the groundwork for translation & refactor asset compilation
Ditched the idea of having language packs as extensions. Reasoning:

1. Because we use machine keys for translations (rather than English
keys), extensions need to be able to define default translations. If
English translations are to be included in extensions and not in a
language pack extension, then it doesn’t make sense to have other
languages as language pack extensions. Inconsistency → complexity.

2. Translations should maintain version parity with their respective
extensions. There’s no way to do this if extension translations are
external to the extension.

Instead, localisation will be a core effort, as well as a per-extension
effort. Translators will be encouraged to send PRs to core + extensions.

In core, each locale has a directory containing three files:
- translations.yml
- config.js: contains pluralisation logic for the JS app, as well as
moment.js localisation if necessary
- config.php: contains pluralisation logic for the PHP app

Extensions can use the Flarum\Extend\Locale extender to add/override
translations/config to a locale.

Asset compilation has been completely refactored with a better
architecture. Translations + config.js are compiled and cached for the
currently active locale.
2015-06-10 14:23:56 +09:30
Franz Liedke
c2df8d5214 Merge branch 'master' into psr-7
Conflicts:
	composer.json
	composer.lock
	src/Api/Actions/TokenAction.php
	src/Core/Formatter/FormatterManager.php
	src/Core/Handlers/Events/EmailConfirmationMailer.php
	src/Forum/Actions/ConfirmEmailAction.php
	src/Forum/Actions/IndexAction.php
	src/Forum/Actions/ResetPasswordAction.php
	src/Forum/Actions/SavePasswordAction.php
	src/Forum/routes.php
2015-06-06 13:59:59 +02:00
Toby Zerner
aae7678cea Really rough fulltext driver implementation 2015-06-04 11:11:56 +09:30
Franz Liedke
a1f5060c05 Remove obsolete imports 2015-05-28 23:52:40 +02:00
Franz Liedke
9526dbf210 Create URL generator interface.
Also bind a default implementation to the container.
2015-05-27 23:58:43 +02:00
Toby Zerner
e5532d9618 Roughly implement change password/email, delete account modals 2015-05-26 18:03:02 +09:30
Toby Zerner
f54acebaf0 Fix bad logic in edit permission that was allowing guests to edit posts. Closes #88 2015-05-21 15:53:59 +09:30
Toby Zerner
edc59f37e3 PSR-2: Remove empty lines 2015-05-20 12:33:26 +09:30
Toby Zerner
3c7078b423 New user activity feed API.
Originally the user activity feed was implemented using UNIONs. I was
looking at make an API to add activity “sources”, or extra UNION
queries (select from posts, mentions, etc.) but quickly realised that
this is too slow and there’s no way to make it scale.

So I’ve implemented an API which is very similar to how notifications
work (see previous commit). The `activity` table is an aggregation of
stuff that happens, and it’s kept in sync by an ActivitySyncer which is
used whenever a post it created/edited/deleted, a user is
mentioned/unmentioned, etc.

Again, the API is very simple (see Core\Activity\PostedActivity +
Core\Handlers\Events\UserActivitySyncer)
2015-05-20 12:30:27 +09:30
Toby Zerner
98b3d0f89e Simplify and improve notifications API.
It turns out that the idea of “sending” a notification is flawed. (What
happens if the notification subject is deleted shortly after? The
notified user would end up with a dud notification which would be
confusing. What about if a post is edited to mention an extra user? If
you sent out notifications, the users who’ve already been mentioned
would get a duplicate notification.)

Instead, I’ve introduced the idea of notification “syncing”. Whenever a
change is made to a piece of data (e.g. a post is created, edited, or
deleted), you make a common notification and “sync” it to a set of
users. The users who’ve received this notification before won’t get it
again. It will be sent out to new users, and hidden from users who’ve
received it before but are no longer recipients (e.g. users who’ve been
“unmentioned” in a post).

To keep track of this, we use the existing notifications database
table, with an added `is_deleted` column. The syncing/diffing is
handled all behind the scenes; the API is extremely simple (see
Core\Notifications\DiscussionRenamedNotification +
Core\Events\Handlers\DiscussionRenamedNotifier)
2015-05-20 12:24:01 +09:30
Toby Zerner
811df6c278 Fix errors in DeleteAvatarAction/Command 2015-05-19 09:27:04 +09:30
Franz Liedke
dd54803aaf Fix remaining PSR-2 issues. 2015-05-19 01:07:22 +02:00
Franz Liedke
7885c9a002 Fix coding standards to conform to PSR-2 2015-05-19 01:03:12 +02:00
Toby Zerner
a577910d04 New object-based extension APIs 2015-05-17 10:19:54 +09:30
Toby Zerner
b4e5f0e6e5 Simplify permissions and add API to register configurable ones
Lots of thought has gone into this; it will show up later when I do the
admin permissions interface / category permissions :)
2015-05-15 17:05:46 +09:30
Toby Zerner
b4fd662000 Remove BasicFormatter; add LinkifyFormatter 2015-05-11 12:11:19 +09:30
Toby Zerner
f2056c4acf Clean up post type API 2015-05-05 14:28:40 +09:30
Toby Zerner
3726c97d5c Remove old code 2015-05-05 09:17:00 +09:30
Toby Zerner
d966c9831a Add event for registering user search gambits 2015-05-03 12:06:01 +09:30
Toby Zerner
60e69ae7b9 Add an event to register discussion gambits 2015-05-02 08:12:30 +09:30
Toby Zerner
3886efffef Turns out putting a . there breaks Laravel 2015-03-29 22:27:37 +10:30
Toby Zerner
40a6d77e74 Big front-end asset/filestructure refactor
- Extract shared Ember components into a “flarum-common” ember-cli
addon. This can be used by both the forum + admin Ember apps, keeping
things DRY
- Move LESS styles into their own top-level directory and do a similar
thing (extract common styles)
- Add LESS/JS compilation and versioning to PHP (AssetManager)
- Set up admin entry point

(Theoretical) upgrade instructions:
- Delete everything in [app_root]/public
- Set up tooling in forum/admin Ember apps (npm install/update, bower
install/update) and then build them (ember build)
- php artisan vendor:publish
- Upgrade flarum/flarum repo (slight change in a config file)
- If you need to trigger a LESS/JS recompile, delete the .css/.js files
in [app_root]/public/flarum. I set up LiveReload to do this for me when
I change files in less/ or ember/

Todo:
- Start writing admin app!
- Remove bootstrap/font-awesome from repo and instead depend on their
composer packages? Maybe? (Bower is not an option here)
2015-03-29 22:13:26 +10:30
Toby Zerner
bc9be30a02 More powerful/extensible notifications
- Notifications can be delivered in multiple ways (alert, email)
- Different notification types can implement interfaces to allow
themselves to be delivered in these various ways
- User preferences for each notification type/method combination are
automatically registered
2015-03-28 15:43:58 +10:30
Toby Zerner
49c3fa09e6 Change "renamed" post type to more descriptive "discussionRenamed" 2015-03-28 15:43:58 +10:30
Toby Zerner
359f44552e Implement user preferences API
Preferences must be registered (optionally with a callback to transform
data, and a default value) on the User model.
2015-03-28 15:43:57 +10:30
Franz Liedke
18ccec4190 Pass newly configured filesystem disk to upload handler. 2015-03-26 22:01:58 +01:00
Franz Liedke
e4ed057557 Wire up instantiation of Flysystem adapter for avatar storage. 2015-03-25 14:26:38 +01:00