2011-07-11 17:54:22 +02:00
|
|
|
<?php
|
|
|
|
|
2011-09-14 17:02:31 +02:00
|
|
|
/**
|
|
|
|
* @group phriction
|
|
|
|
*/
|
2013-01-11 20:39:22 +01:00
|
|
|
final class PhrictionDocument extends PhrictionDAO
|
|
|
|
implements PhabricatorPolicyInterface {
|
2011-07-11 17:54:22 +02:00
|
|
|
|
|
|
|
protected $id;
|
|
|
|
protected $phid;
|
|
|
|
protected $slug;
|
|
|
|
protected $depth;
|
|
|
|
protected $contentID;
|
2011-12-17 18:19:08 +01:00
|
|
|
protected $status;
|
2011-07-11 17:54:22 +02:00
|
|
|
|
2011-07-12 00:42:12 +02:00
|
|
|
private $contentObject;
|
2013-03-08 16:12:24 +01:00
|
|
|
private $project;
|
2011-07-12 00:42:12 +02:00
|
|
|
|
2011-07-11 17:54:22 +02:00
|
|
|
public function getConfiguration() {
|
|
|
|
return array(
|
|
|
|
self::CONFIG_AUX_PHID => true,
|
|
|
|
self::CONFIG_TIMESTAMPS => false,
|
|
|
|
) + parent::getConfiguration();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function generatePHID() {
|
|
|
|
return PhabricatorPHID::generateNewPHID(
|
|
|
|
PhabricatorPHIDConstants::PHID_TYPE_WIKI);
|
|
|
|
}
|
|
|
|
|
2011-07-12 00:06:19 +02:00
|
|
|
public static function getSlugURI($slug, $type = 'document') {
|
|
|
|
static $types = array(
|
|
|
|
'document' => '/w/',
|
|
|
|
'history' => '/phriction/history/',
|
|
|
|
);
|
|
|
|
|
|
|
|
if (empty($types[$type])) {
|
|
|
|
throw new Exception("Unknown URI type '{$type}'!");
|
|
|
|
}
|
|
|
|
|
|
|
|
$prefix = $types[$type];
|
|
|
|
|
2011-07-11 17:54:22 +02:00
|
|
|
if ($slug == '/') {
|
2011-07-12 00:06:19 +02:00
|
|
|
return $prefix;
|
2011-07-11 17:54:22 +02:00
|
|
|
} else {
|
Allow slugs to contain most utf8 characters
Summary:
Ref T2632. Fixes T1466.
Currently, we normalize slugs (and thus Phriction URIs and canonical project names) to a small number of latin characters. Instead, blacklist a few characters and permit everything else (including utf8 characters).
When generating Phriction URIs, encode any utf8 characters. This means we render URIs encoded, but browsers handle this fine and display them readably in the URI and address bar, etc.
The blacklisted characters are mostly for practical reasons: \x00-\x19 are control characters, `#%?` are meaningful in URIs, `+` is sometimes configured to be interprted as space by apache, etc., `<>\\` are just silly, `&= ` are largely cosmetic.
This allows some silly stuff, like generating URIs with zero-width spaces and RTL markers in them. Possibly we should go blacklist those characters at some point.
Depends on: D5191
Test Plan: {F34402}
Reviewers: AnhNhan, chad, vrana
Reviewed By: chad
CC: aran
Maniphest Tasks: T1466, T2632
Differential Revision: https://secure.phabricator.com/D5192
2013-03-03 19:56:33 +01:00
|
|
|
// NOTE: The effect here is to escape non-latin characters, since modern
|
|
|
|
// browsers deal with escaped UTF8 characters in a reasonable way (showing
|
|
|
|
// the user a readable URI) but older programs may not.
|
|
|
|
$slug = phutil_escape_uri($slug);
|
2011-07-12 00:06:19 +02:00
|
|
|
return $prefix.$slug;
|
2011-07-11 17:54:22 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setSlug($slug) {
|
2012-04-10 23:18:20 +02:00
|
|
|
$this->slug = PhabricatorSlug::normalize($slug);
|
|
|
|
$this->depth = PhabricatorSlug::getDepth($slug);
|
2011-07-11 17:54:22 +02:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-07-12 00:42:12 +02:00
|
|
|
public function attachContent(PhrictionContent $content) {
|
|
|
|
$this->contentObject = $content;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getContent() {
|
|
|
|
if (!$this->contentObject) {
|
|
|
|
throw new Exception("Attach content with attachContent() first.");
|
|
|
|
}
|
|
|
|
return $this->contentObject;
|
|
|
|
}
|
|
|
|
|
2013-03-08 16:12:24 +01:00
|
|
|
public function getProject() {
|
|
|
|
if ($this->project === null) {
|
|
|
|
throw new Exception("Call attachProject() before getProject().");
|
|
|
|
}
|
|
|
|
return $this->project;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function attachProject(PhabricatorProject $project) {
|
|
|
|
$this->project = $project;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasProject() {
|
|
|
|
return (bool)$this->project;
|
|
|
|
}
|
|
|
|
|
Provide wiki pages for projects
Summary:
Provide tighter integration between Projects and Phriction. Partly, I have most
of a rewrite for the Projects homepage ready but it's not currently possible to
publish feed stories about a project so all the feeds are empty/boring. This
partly makes them more useful and partly just provides a tool integration point.
- When you create a project, all the wiki pages in projects/<project_name>/*
are associated with it.
- Publish updates to those pages as being related to the project so they'll
show up in project feeds.
- Show a project link on those pages.
This is very "convention over configuration" but I think it's the right
approach. We could provide some sort of, like, "@project=derp" tag to let you
associated arbitrary pages to projects later, but just letting you move pages is
probably far better.
Test Plan:
- Ran upgrade scripts against stupidly named projects ("der", " der", " der
", "der (2)", " der (2) (2)", etc). Ended up with uniquely named projects.
- Ran unit tests.
- Created /projects/ wiki documents and made sure they displayed correctly.
- Verified feed stories publish as project-related.
- Edited projects, including perfomring a name-colliding edit.
- Created projects, including performing a name-colliding create.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, btrahan
Maniphest Tasks: T681
Differential Revision: 1231
2011-12-17 20:58:55 +01:00
|
|
|
public static function isProjectSlug($slug) {
|
2012-04-10 23:18:20 +02:00
|
|
|
$slug = PhabricatorSlug::normalize($slug);
|
Provide wiki pages for projects
Summary:
Provide tighter integration between Projects and Phriction. Partly, I have most
of a rewrite for the Projects homepage ready but it's not currently possible to
publish feed stories about a project so all the feeds are empty/boring. This
partly makes them more useful and partly just provides a tool integration point.
- When you create a project, all the wiki pages in projects/<project_name>/*
are associated with it.
- Publish updates to those pages as being related to the project so they'll
show up in project feeds.
- Show a project link on those pages.
This is very "convention over configuration" but I think it's the right
approach. We could provide some sort of, like, "@project=derp" tag to let you
associated arbitrary pages to projects later, but just letting you move pages is
probably far better.
Test Plan:
- Ran upgrade scripts against stupidly named projects ("der", " der", " der
", "der (2)", " der (2) (2)", etc). Ended up with uniquely named projects.
- Ran unit tests.
- Created /projects/ wiki documents and made sure they displayed correctly.
- Verified feed stories publish as project-related.
- Edited projects, including perfomring a name-colliding edit.
- Created projects, including performing a name-colliding create.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, btrahan
Maniphest Tasks: T681
Differential Revision: 1231
2011-12-17 20:58:55 +01:00
|
|
|
$prefix = 'projects/';
|
|
|
|
if ($slug == $prefix) {
|
|
|
|
// The 'projects/' document is not itself a project slug.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return !strncmp($slug, $prefix, strlen($prefix));
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function getProjectSlugIdentifier($slug) {
|
|
|
|
if (!self::isProjectSlug($slug)) {
|
|
|
|
throw new Exception("Slug '{$slug}' is not a project slug!");
|
|
|
|
}
|
|
|
|
|
2012-04-10 23:18:20 +02:00
|
|
|
$slug = PhabricatorSlug::normalize($slug);
|
Provide wiki pages for projects
Summary:
Provide tighter integration between Projects and Phriction. Partly, I have most
of a rewrite for the Projects homepage ready but it's not currently possible to
publish feed stories about a project so all the feeds are empty/boring. This
partly makes them more useful and partly just provides a tool integration point.
- When you create a project, all the wiki pages in projects/<project_name>/*
are associated with it.
- Publish updates to those pages as being related to the project so they'll
show up in project feeds.
- Show a project link on those pages.
This is very "convention over configuration" but I think it's the right
approach. We could provide some sort of, like, "@project=derp" tag to let you
associated arbitrary pages to projects later, but just letting you move pages is
probably far better.
Test Plan:
- Ran upgrade scripts against stupidly named projects ("der", " der", " der
", "der (2)", " der (2) (2)", etc). Ended up with uniquely named projects.
- Ran unit tests.
- Created /projects/ wiki documents and made sure they displayed correctly.
- Verified feed stories publish as project-related.
- Edited projects, including perfomring a name-colliding edit.
- Created projects, including performing a name-colliding create.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, btrahan
Maniphest Tasks: T681
Differential Revision: 1231
2011-12-17 20:58:55 +01:00
|
|
|
$parts = explode('/', $slug);
|
|
|
|
return $parts[1].'/';
|
|
|
|
}
|
|
|
|
|
2013-01-11 20:39:22 +01:00
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
2013-03-08 16:12:24 +01:00
|
|
|
if ($this->hasProject()) {
|
|
|
|
return $this->getProject()->getPolicy($capability);
|
|
|
|
}
|
2013-01-11 20:39:22 +01:00
|
|
|
return PhabricatorPolicies::POLICY_USER;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $user) {
|
2013-03-08 16:12:24 +01:00
|
|
|
if ($this->hasProject()) {
|
|
|
|
return $this->getProject()->hasAutomaticCapability($capability, $user);
|
|
|
|
}
|
2013-01-11 20:39:22 +01:00
|
|
|
return false;
|
|
|
|
}
|
2011-07-11 17:54:22 +02:00
|
|
|
}
|