- 04 Jan, 2022 4 commits
-
-
James Addison authored
-
James Addison authored
-
James Addison authored
-
James Addison authored
-
- 10 Jun, 2021 36 commits
-
-
Ana Rute Mendes authored
-
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
-
Ana Rute Mendes authored
this avoids javascript errors of object not found when switching between form types that don't have all the fields displayed.
-
Ana Rute Mendes authored
-
Ana Rute Mendes authored
make sure it's called only when the ticket has its status changed
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
in progress points were hard to spot
-
Ana Rute Mendes authored
every item has an asset tag that can now be mannually edited from phab
-
Ana Rute Mendes authored
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%
-
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
The fields item dimensions and weight won't be used anymore in the purchasing ticket.
-
Ana Rute Mendes authored
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
Some customization are not being used in Phabricator Apertis instance. So some features were breaking when calling functions in variables that were null
-
Ana Rute Mendes authored
Make sure phab won't raise errors if the SnipeHelper methods or API requests fail.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
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.
-
Ana Rute Mendes authored
These conditions will increase, to keep the code cleaner replace 3 if statements with a switch
-
Ana Rute Mendes authored
-
Ana Rute Mendes authored
Set sysadmin resquests policies according to confidentiality chosen by the user.
-
Ana Rute Mendes authored
Restrict the creation of a new top-level document if visibility or edition policies are set to "All users". See T4759
-
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>
-
Add a colour scheme for tagging objects in lists.
-
This is a UI tweak.
-
Encode policy, allowing patches to land on feature branches without closing tasks.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-