I've discovered a minor UX problem if an heading has a nice icon. Check it:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Dec 18
Sat, Dec 14
Thu, Dec 12
Wed, Dec 11
Mon, Dec 9
Sun, Dec 8
Thanks. I see, from this page is not possible:
Sat, Dec 7
Oct 9 2024
In T15947#19599, @avivey wrote:Maybe express it as allowed by Policy xxx? (Related to T15277)
So essentially this:
Maybe express it as allowed by Policy xxx? (Related to T15277)
Sep 16 2024
Dear arp, please clone and hack a lot on Phorge :) Thanks and feel free to share any question
What's the status of this one? Just curious if we should fork and hack around it ourselves for now or if it's coming soon.
Sep 6 2024
Sep 5 2024
I just discovered that sometime we can spawn warnings above the comment box.
Aug 17 2024
Aug 9 2024
@valerio.bozzolan also, triggers don't offer an option to change task space or task access.
Aug 8 2024
I wonder if "Workboard Triggers" may do the job here.
I see. So, is that functionality already a part of arc diff? In other words, if arc work T123 would have worked exactly the same way as arc work branch-name (by creating a branch that's called either T123 or branch-name), then arc diff would correctly link it?
Aug 7 2024
Yes - it works seamlessly because if the local branch has a task number in it, the diff is automatically linked to that task when you run arc diff
I'd assume that it also links the task and the diff together and optionally allows to close the task automatically on diff land?
Aug 6 2024
Just adding references
Aug 2 2024
I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.
Jul 26 2024
Jul 23 2024
OK. If you are partially mentioning nonsenses in we.phorge.it itself, you are indeed right.
Jul 22 2024
We might come from different user journeys.
Your users might be aware what the project means, and that the project (and its workboard) is archived, and they do have an initial reason to look at this archived workboard (e.g. default view is not "open tasks" but "all tasks")?
My users clicked an external link to some project tag in something called Phorge, and that project has been archived in the meantime, and that project is set to show the workboard by default, and that is now just empty columns (as the default view of workboards is "open tasks"), and that is confusing and unhelpful.
Jul 21 2024
I mean. See this archived Project (archived Milestone), that is linked from our changelogs:
Jul 20 2024
For example, some people then may ask "why my default view was changed?" and they will start manually "rollbacking" this to their desired view (e.g. showing closed tasks, from the Workboard, with a filter "Show all tasks").
Premising that I like the implementation but I think it's not the desired solution.
Jul 12 2024
Premising that the root problem is that it's difficult to understand if a project is archived just looking at other parts.
Jul 1 2024
Jun 23 2024
Jun 21 2024
Jun 18 2024
Jun 16 2024
Jun 15 2024
Jun 14 2024
Cleaner attempt in D25546 Diff 2113.
Jun 13 2024
Thanks for the pointers, I really appreciate them.
Jun 7 2024
Jun 6 2024
/settings/panel/multifactor/ requires users to add a custom Name so there is likely code to adapt/reuse for /settings/panel/apitokens/
Jun 5 2024
Jun 2 2024
I think the EditEngine is what's used to create the actions form, and it has some sense of the object's status (see for example the available actions on Revisions - these change based on the revision's state).
Maybe it can get an additional "field" for this warning, and display it based on task status.
May 31 2024
I remain unhappy with my code in D25546:
- Phorge lacks a method "give me all engines for this application".
- PhabricatorApplication offers nothing related to engines.
- PhabricatorEditEngine::getApplication() does what I want exactly the other way round: it returns the application for a given engine.
- PhabricatorEditEngine::getAllEditEngines() is confusingly named. It only returns EditEngine keys like calendar.export or maniphest.task but not actual engines or engine classes. ($engines = id(new PhabricatorEditEngineQuery())->setViewer($this->getViewer())->execute(); returns the actual engines, as already used by this code.)
- I cannot find some mapping between EditEngine keys (like maniphest.task) and either PhabricatorPHIDTypes (like ManiphestTaskPHIDType) or their TypeConstants (like TASK) either.
- getEngineClassName() exists but only in a SearchEngine/SearchQuery context, not in a EditEngine content (and I cannot find its constructor)
May 10 2024
May 7 2024
Something I stumbled upon few months ago (via forgejo): agit-flow[^1]. Maybe worth sharing here -- for teh record? It does have some CLI client (git-repo) but it's optional and push via git push origin HEAD:refs/for/<target-branch>/<session> would trigger the Code Review process, without gerrit's Change-Id hack.
May 2 2024
To implement this, you may want to start from this 🌈
Apr 28 2024
Apr 16 2024
In T15749#16629, @avivey wrote:Maybe put the warning above the box, so it catches all actions, not just comments?
:p
I was responding to the previous comment which...
Our company uses the Phorge, and we use Keycloak as IAM. Keycloak is a very popular OAuth2/SAML provider now.
Apr 14 2024
Maybe put the warning above the box, so it catches all actions, not just comments?
Apr 13 2024
GitHub/Facebook is already supported as a Login/Registration providers.
Apr 2 2024
Yes will be great to see a SAML or Oauth support for external authorities like:
- Keycloak
- Entra ID
- Github
- WeChat / WeCom
Mar 30 2024
Mar 28 2024
Mar 9 2024
Interesting. I see. Maybe expanding its controller that should be this one:
Mar 8 2024
Yeah, in this one special place it doesn't matter; But that page already have a special body, so we can save even the extra click by putting the message right there...
OK I see. Indeed we should not put any similar button anywhere else.
But in Diffusion, that button is hidden behind a "Actions -> Manage" button, inside a screen that also has dozens of other admin actions. The clutter cost there is minimized.
I see. Maybe the root problem is that I'm in love with that Diffusion popup 🤔
In that case, we don't even need another button - just add a line to the "deleted message" that says something like "To completely remove the history from the database, contact your admin".
Premising the user already have an Delete Document button.
I feel that adding such a button would clutter the UI.
Users should generally "know" that in order to really delete things, they need to go to the admin, because they don't have the permissions anyway; And adding that just for the once-in-a-while that the admin needs this...
I mean, we can maybe have a "Delete" button that just shows the related CLI command, like I've seen around (Diffusion maybe)
I don't think we actually allow "deleting" from the web ui, only hiding it (in the sense that the data is not removed from the database).
This feature request could also be expanded to: