James Addison authored Mar 30, 2021 and Ana Rute Mendes committed Jun 10, 2021

This change is intended to visually distinguish Collabora's Phabricator Maniphest web interface, reducing the risk that staff confuse it with any other instances they use that are configured with the default theme

The change is applied to the `indigo` theme.

Maniphest Tasks: T27069

this avoids javascript errors of object not found when
switching between form types that don't have all the fields
displayed.

make sure it's called only when the ticket has its status changed

phabricator creates xactions as previews when someone is editing
the tickect through the comments section. We do not want to trigger
the asset creation in Snipe IT in theses cases, otherwise we will
end up with duplicated items in snipe IT.

After creating items in Snipe-It we need to save in the ticket
(maniphest task) the created ids and tags. So instead of receiving only
the ids list, the SnipeIt extension will return transactions or
validation errors.

If it returns an errror, append it to the list. If not, it's
an array of transactions so add them to the results array to update the
purchasing request.

in progress points were hard to spot

every item has an asset tag that can now be mannually edited from phab

If the task has no children it doesn't make much sense
to display the progress bar as the progress can only be 0 or 100%

Daniel Stone authored May 21, 2020 and Ana Rute Mendes committed Jun 10, 2021

If we have a child task which we can't access, ManiphestTaskQuery will
raise an exception; trying to view the workboard, this will bubble up as
a policy exception which will (incorrectly) tell the viewer they can't
access the project.

Catch any exceptions whilst trying to calculate overall progress, and
ignore those restricted child tasks.

Based on the custom field `std:maniphest:collabora:rag-status`
display the RAG indicator in the task card as well as a progress
bar that exposes the task children points.

To make the assets field searchable, add choices.js lib to the field,
adapt its style to look like a native phabricator field and dynamically
display the items details.

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 Jun 10, 2021

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 Jun 10, 2021

Add a colour scheme for tagging objects in lists.

Daniel Stone authored Apr 29, 2016 and Ana Rute Mendes committed Jun 10, 2021

This is a UI tweak.

Daniel Stone authored Aug 10, 2016 and Ana Rute Mendes committed Jun 10, 2021

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

Daniel Stone authored Apr 24, 2015 and Ana Rute Mendes committed Jun 10, 2021

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 Jun 10, 2021

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 Jun 10, 2021

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 Jun 10, 2021

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 Jun 10, 2021

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 Jun 10, 2021

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.