GitLab

The fields item dimensions and weight won't be used anymore in the
purchasing ticket.

Allows a ticket to have up to 5 items in the same
purchasing request.

Handle the hiding/displaying of a mini form for each asset and
control display of properties that are used only in Snipe-IT.

Replicate the logic to auto-fill approver for `event` subtype.

Until now event and purchasing forms used the same template but
they were split in two - `purchasing` and `event` - after the
Snipe-IT integration that applied major changes in the purchasing
request form.

The only way I found to add a custom js file was directly in the
webroot folder. To make sure it never generate conflicts when updaitng
phab, I created an extensions folder in the js directory.

This file is called by the SnipeHelper class.

Some customization are not being used in Phabricator Apertis
instance. So some features were breaking when calling functions
in variables that were null

Make sure phab won't raise errors if the SnipeHelper methods
or API requests fail.

If a Shipping Request is edited and it has the asset id field
filled, trigger the method that will fetch the data from Snipe-IT
and fill the item details in the task.

When a Purchasing Request changes status to "To Relase" an asset
must be created in the inventory system, external from Phabricator.

Trigger the create asset method that is placed in the extensions folder.

These conditions will increase, to keep the code cleaner replace 3
if statements with a switch

Set sysadmin resquests policies according to confidentiality
chosen by the user.

Restrict the creation of a new top-level document if visibility or
edition policies are set to "All users".

See T4759

Daniel Stone authored Sep 14, 2018 and Ana Rute Mendes committed Mar 29, 2020

Phriction's view policy is ancestral: in order to access /w/foo/bar/baz,
you must be able to access /w/foo and /w/bar in addition to
/w/foo/bar/baz itself.

This is fine and makes life easy: by setting restrictive policies on
top-level pages, we can lessen the risk of someone exposing information
they shouldn't, by accidentally making
/w/cold-fusion/secret-research/funding-meeting/2018-09-14 public, when
the rest of the hierarchy is super locked down.

Phriction also recently gained Spaces support, which is nice: rather
than trying to lock down with groups and harmonise permissions, we can
just move top-level wiki pages to a particular Space, and then we don't
need to worry about groups.

Our clients don't know Spaces even exist, which is great since it avoids
us having to explain the two-tier permission model to them. The reason
they don't know it exists is because if you can only see a single Space,
then Phabricator hides the entire Spaces UI away from you. Great!

Unfortunately one detail ruins everything: /w/ is a top-level page
itself, it counts for permission checks, and it _must be in a Space_.
So, there is no way to have wiki documents in mutually-invisible Spaces
unless you also have a common Space, at which point the whole Spaces UI
suddenly becomes very visible everywhere.

In order to try to keep our wiki partitioned, but to not confuse our
clients (and give them the chance to potentially expose confidential
information!), we:
  - have a magic 'Visible to Everyone' space
  - actually hide that space from everyone with policies
  - hack policy filters to make this space visible to everyone _only
    for the purpose of checking policies on wiki objects_
  - only allow admins to change view/edit policies on the root wiki
    page (see comment for reason why)

This actual patch can obviously never go anywhere near upstream, but on
the other hand we should probably make them aware of the problem and see
if they're interested in discussing a solution, which is probably just
to bless the root page with magic semantics.
Signed-off-by: Daniel Stone <daniels@collabora.com>

Daniel Stone authored Jul 14, 2015 and Ana Rute Mendes committed Mar 29, 2020

Add a colour scheme for tagging objects in lists.

Daniel Stone authored Apr 29, 2016 and Ana Rute Mendes committed Mar 29, 2020

This is a UI tweak.

Daniel Stone authored Aug 10, 2016 and Ana Rute Mendes committed Mar 29, 2020

Encode policy, allowing patches to land on feature branches without
closing tasks.

Daniel Stone authored Apr 24, 2015 and Ana Rute Mendes committed Mar 29, 2020

It would be nice, as the comment notes, to have this customisable perhaps
per-repository, but for the meantime this is unambiguously the better
solution.

Evan Priestley authored Aug 06, 2016 and Ana Rute Mendes committed Mar 29, 2020

Sort tags alphabetically, rather than order of (PHID) appearance in the
database.

From https://secure.phabricator.com/p/epriestley at:
https://secure.phabricator.com/T11420#188498

Daniel Stone authored Aug 03, 2016 and Ana Rute Mendes committed Mar 29, 2020

In the Maniphest query result view, show the story points as well as the
review/CI status on each task as we currently show them in workboard
column cards, along with the project tags.

This is local UI policy; the correct fix (of rewriting hover/card views
to be more generic and extensible) is pretty much impossible to achieve,
and isn't approachable by non-Phacility contributors.

Daniel Stone authored Apr 26, 2016 and Ana Rute Mendes committed Mar 29, 2020

Show the status of every task in workboard cards using the icons
explicitly, rather than just differentiating between closed and
not-closed.

This is a local UI choice.

Daniel Stone authored Apr 26, 2016 and Ana Rute Mendes committed Mar 29, 2020

On project workboard cards, also show the status of linked code reviews;
both the review itself, and any attached Harbormaster CI buildables.

This is already taken care of in the task-detail view by 45c740ac,
and extends it to the workboard view. It should probably share more code
with the task-detail view.

It will not be accepted upstream in its current form; it was felt in
https://secure.phabricator.com/T7076 discussion that performing multiple
queries for each revision to get the current state was too much. This
makes it exceedingly unlikely that doing the same number of queries for
every task in a workboard would be acceptable.

There was discussion of how to fix that, but it was essentially
impossible, and explicitly discouraged for anyone to even try.

Daniel Stone authored Apr 01, 2017 and Ana Rute Mendes committed Mar 29, 2020

Enforce a local policy, that on purchasing tasks, the approver will be
auto-assigned if there is no assignee.

The 'correct' fix would probably be a Herald rule, if it were actually
possible to implement. An EditEngine extension might work as well, but
this was easier.

Daniel Stone authored Aug 09, 2016 and Ana Rute Mendes committed Mar 29, 2020

Enforce a local policy that all tasks must have an associated project.

Daniel Stone authored Jan 09, 2017 and Ana Rute Mendes committed Mar 29, 2020

When we attach a new diff to a Differential revision, clear out its
'Depends On' field. This is so we don't end up with dependency cycles
when we rebase/cherry-pick commits out of order.

As upstream do not use rebasing/chery-picking/multi-patch-branch
workflows, this is unlikely to be accepted.

Daniel Stone authored Aug 01, 2017 and Ana Rute Mendes committed Mar 29, 2020

This is really lame. The Ruby OAuth2 client can only pass its token in
the form data (which Phab is not prepared to accept), or as part of the
Authorization header (which PHP strips out).

Use a function only available in newer PHP to scrape the Authorization
header from the raw stream.

I have no idea what the correct fix is.

Daniel Stone authored Jul 03, 2017 and Ana Rute Mendes committed Mar 29, 2020

Mattermost OAuth requires two separate URIs, whereas the Phabricator
OAuth server only allows returning to a single URI. Special case
Mattermost and get on with life.

The correct fix is to actually allow multiple values in the OAuth
configuration. I don't know off the top of my head how this would work,
e.g. a tokenising field, or a multi-line field (which I don't know how
to achieve without Remarkup), or ... ?

Daniel Stone authored Apr 24, 2017 and Ana Rute Mendes committed Mar 29, 2020

PhabricatorApplicationTransactionEditor contains logic (inside
combineTransactions -> mergeTransactions ->
mergePHIDOrEdgeTransactions), which will combine two transactions of the
same edge type and author, then apply the operations in a deterministic
order.

This breaks our change to remove dependencies when updating a
Differential revision, since we (acting as the user who uploaded the
revision) remove the DifferentialRevisionDependsOn edge, then have the
Remarkup block parser add the dependencies from the commit message
later.

The two (simplified) transactions of:
{
    "1-from-our-change-to-differential": {
        "type": "edge",
        "-": {
	    "PHID-DREV-1234": [...], // remove previous dep
	}
    },
    "2-from-remarkup-parsing": {
        "type": "edge",
        "+": {
	    "PHID-DREV-1234": [...], // add dep from commit message
	}
    }
}

get merged into:
{
    "1-combined": {
        "type": "edge",
	"-": {
	    "PHID-DREV-1234": [...], // remove previous dep
	},
	"+": {
	    "PHID-DREV-1234": [...], // add dep from commit message
	}
    }
}

getPHIDTransactionNewValue() then returns an empty dictionary, because
it always executes the add before the remove, regardless of ordering.
The correct fix would be quite invasive to the transaction editor
(making the combine function considerably less naïve, and always
preserving order of operation WRT identical PHIDs); the quick fix for
now (at least) is to just make add operations execute after remove, thus
'fixing' it for the only case we really care about.

The correct fix is more time than worthwhile to achieve, especially
since it's extremely difficult to achieve without code modifications.

Emanuele Aina authored Jun 29, 2015 and Ana Rute Mendes committed Mar 29, 2020

This is completely broken with modern transactions. It should also be
rewritten to match Phabricator's coding style.

Daniel Stone authored Aug 10, 2016 and Ana Rute Mendes committed Mar 29, 2020

If a transaction has an object that a particular user cannot see, then
mark the transaction as hidden for the default transaction view. This
particularly elides 'foo moved this task from Restricted Workboard
Column to Restricted Workboard Column on the Restricted Project board'
messages in the timeline, which are not hugely useful.

This would need a fair bit more work to go upstream, especially eliding
notifications for restricted-only transactions as well.

Daniel Stone authored Aug 09, 2016 and Ana Rute Mendes committed Mar 29, 2020

If the viewer doesn't have permission to see something a task has been
tagged with, then don't show it to them in the Maniphest task list view,
the task detail view, or the workboard view.

This should be extended further to also eliminate it from the
transaction history (in the task detail view) and also from
notifications, but it's a start.

This would need quite a bit more work to go upstream.

Daniel Stone authored Mar 30, 2017 and Ana Rute Mendes committed Mar 29, 2020

Add a 'subtype' parameter to custom fields, which means they will only
be visible on (and validated with) tasks of a particular subtype.

Suitable for upstream after much rework:
https://secure.phabricator.com/D17593

Emanuele Aina authored Jul 09, 2015 and Ana Rute Mendes committed Mar 29, 2020

By taking the story time from the transaction creation date we ensure that the times reported in the feed view match the ones reported in the item-specific change lists.

Quinn Ebert authored Jan 11, 2016 and Ana Rute Mendes committed Mar 29, 2020

This implements an Applications > Phriction configuration option that allows the administrators to specify default view and edit ACL policies for root-level Phriction documents.

Test Plan:
  1. Create a clean test install of Phabricator, login as the admin user
  2. Go to Applications, configure settings for Phriction, set up the ACL you want
  3. Upon creating the first document in Phriction, the ACL chosen by default should be the one you configured in step 2.

Daniel Stone authored Jul 03, 2017 and Ana Rute Mendes committed Mar 29, 2020

As setValueFromStorage() notes, we can accept either JSON strings or arrays for PHID-type custom fields. Handle this in decodeValue by passing through an array if we've received one.

Test Plan:
  - Add Maniphest custom field with PhabricatorPeopleDatasource
  - Create task with field filled
  - Go to Maniphest task detail view
  - Observe no errors in DarkConsole / PHP error log

Daniel Stone authored Sep 14, 2015 and Ana Rute Mendes committed Mar 29, 2020

Ref T13042. Updating blocked tasks creates a new ManiphestTransactionEditor instance from within the current transaction application, which fails to carry over all of the current properties. Failing to update silent means that mails will be generated for updates to blocked tasks, regardless of the setting for the original transaction editor.

Failing to preserve the time can also give large time deltas in corner cases, such as running an importer which pulls tasks from yesteryear.

This equally applies to inverse-edge transactions, though I don't have a ready-made usecase for those.

Summary:
Fixes T5427. See PHI1630. See also T13160 and D20568.

In the full HTML table syntax with "<table>", respect linebreaks as literals inside "<td>" cells.

Test Plan: Previewed some full-HTML tables with and without linebreaks, saw what seemed like sensible rendering behavior.

Maniphest Tasks: T5427

Differential Revision: https://secure.phabricator.com/D20971

Summary: Ref T10635. An install with large blocks of remarkup (4MB) in test details is reporting slow page rendering. This is expected, but I've mostly given up on fighting this unless I absolutely have to. Degrade the interface more aggressively.

Test Plan:
  - Submitted a large block of test details in remarkup format.
  - Before patch: they rendered inline.
  - After patch: degraded display.
  - Verified small blocks are not changed.

{F7180727}

{F7180728}

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Maniphest Tasks: T10635

Differential Revision: https://secure.phabricator.com/D20970

Summary: Ref T13486. Currently, "Zarbo" sorts above "alice", but this isn't expected for a list of (mostly) human usernames.

Test Plan: Loaded a task with subscribers with mixed-case usernames.

Maniphest Tasks: T13486

Differential Revision: https://secure.phabricator.com/D20969