[v9.0.1] Recent Uploads Broken After Folder Delete

After deleting a folder that contained a "recent upload" the Choose File dialog throws an error.
To Replicate:

Create a folder in the Access Dashboard -> Files
Create a new folder
Upload a file to that new folder
Delete the folder
Go to any page on the frontend of the site and attempt to add an Image block (or any block that has an image picker) when the Choose File dialog opens you will get this error:

Call to a member function getTreeNodePermissionsNodeID() on null

Details

/app/concrete/src/Permission/Assignment/FileAssignment.php(68): Error->null
/app/concrete/src/Permission/Key/Key.php(641): Concrete\Core\Permission\Assignment\FileAssignment->getPermissionAccessObject
/app/concrete/src/Permission/Key/FileKey.php(20): Concrete\Core\Permission\Key\Key->getPermissionAccessObject
/app/concrete/src/Permission/Response/Response.php(111): Concrete\Core\Permission\Key\FileKey->validate
/app/concrete/src/Permission/Response/Response.php(111): null->call_user_func_array
/app/concrete/src/Permission/Response/Response.php(121): Concrete\Core\Permission\Response\Response->validate
/app/concrete/src/Permission/Checker.php(52): Concrete\Core\Permission\Response\Response->__call
/app/concrete/controllers/backend/file/chooser.php(73): Concrete\Core\Permission\Checker->__call
/app/concrete/src/File/FileList.php(130): Concrete\Controller\Backend\File\Chooser->Concrete\Controller\Backend\File\{closure}
/app/concrete/src/File/FileList.php(130): null->call_user_func_array
/app/concrete/src/File/FileList.php(119): Concrete\Core\File\FileList->checkPermissions
/app/concrete/src/Search/Pagination/Pagination.php(117): Concrete\Core\File\FileList->getResult
/app/concrete/controllers/backend/file/chooser.php(231): Concrete\Core\Search\Pagination\Pagination->getCurrentPageResults
/app/concrete/controllers/backend/file/chooser.php(75): Concrete\Controller\Backend\File\Chooser->buildFileListFractalResponse
/app/concrete/src/Controller/AbstractController.php(318): Concrete\Controller\Backend\File\Chooser->getRecent
/app/concrete/src/Controller/AbstractController.php(318): null->call_user_func_array
/app/concrete/src/Routing/ControllerRouteAction.php(64): Concrete\Core\Controller\AbstractController->runAction
/app/concrete/src/Http/RouteDispatcher.php(37): Concrete\Core\Routing\ControllerRouteAction->execute
/app/concrete/src/Http/Middleware/DispatcherDelegate.php(39): Concrete\Core\Http\RouteDispatcher->dispatch
/app/concrete/src/Http/Middleware/MiddlewareStack.php(86): Concrete\Core\Http\Middleware\DispatcherDelegate->next
/app/concrete/src/Http/DefaultDispatcher.php(127): Concrete\Core\Http\Middleware\MiddlewareStack->process
/app/concrete/src/Http/DefaultDispatcher.php(60): Concrete\Core\Http\DefaultDispatcher->handleDispatch
/app/concrete/src/Http/Middleware/DispatcherDelegate.php(39): Concrete\Core\Http\DefaultDispatcher->dispatch
/app/concrete/src/Http/Middleware/FrameOptionsMiddleware.php(39): Concrete\Core\Http\Middleware\DispatcherDelegate->next
/app/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\FrameOptionsMiddleware->process
/app/concrete/src/Http/Middleware/StrictTransportSecurityMiddleware.php(36): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/app/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\StrictTransportSecurityMiddleware->process
/app/concrete/src/Http/Middleware/ContentSecurityPolicyMiddleware.php(36): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/app/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\ContentSecurityPolicyMiddleware->process
/app/concrete/src/Http/Middleware/CookieMiddleware.php(35): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/app/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\CookieMiddleware->process
/app/concrete/src/Http/Middleware/ApplicationMiddleware.php(29): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/app/concrete/src/Http/Middleware/MiddlewareDelegate.php(50): Concrete\Core\Http\Middleware\ApplicationMiddleware->process
/app/concrete/src/Http/Middleware/MiddlewareStack.php(86): Concrete\Core\Http\Middleware\MiddlewareDelegate->next
/app/concrete/src/Http/DefaultServer.php(85): Concrete\Core\Http\Middleware\MiddlewareStack->process
/app/concrete/src/Foundation/Runtime/Run/DefaultRunner.php(125): Concrete\Core\Http\DefaultServer->handleRequest
/app/concrete/src/Foundation/Runtime/DefaultRuntime.php(102): Concrete\Core\Foundation\Runtime\Run\DefaultRunner->run
/app/concrete/dispatcher.php(45): Concrete\Core\Foundation\Runtime\DefaultRuntime->run
/app/index.php(2): null->require

Not sure what's going on here, but you might have to do some extra cleanup manually.

Retrieve a list of all files that are joined to file folders that no longer exist:

select fID from Files f left join TreeNodes tn on f.folderTreeNodeID = tn.treeNodeID where tn.treeNodeID is null;

For each fID value in that list, delete it manually from the FileVersions and Files table:

delete from FileVersions where fID = {fID}
delete from Files where fID = {fID}`.

I have this issue too. The manual cleanup helps until I delete a folder with files :(

Same issue too. And had another problem if the deleted folder is a favorite one.
After deleting it in FileVersions and Files we have to do the same with UserFavoriteFolders...
delete from UserFavoriteFolders where treeNodeFolderId={fID}

Fixed by https://github.com/concrete5/concrete5/issues/10144


[SPARK-18961][SQL] Support SHOW TABLE EXTENDED ... PARTITION statement

What changes were proposed in this pull request?
We should support the statement SHOW TABLE EXTENDED LIKE 'table_identifier' PARTITION(partition_spec), just like that HIVE does.
When partition is specified, the SHOW TABLE EXTENDED command should output the information of the partitions instead of the tables.
Note that in this statement, we require exact matched partition spec. For example:
CREATE TABLE show_t1(a String, b Int) PARTITIONED BY (c String, d String);
ALTER TABLE show_t1 ADD PARTITION (c='Us', d=1) PARTITION (c='Us', d=22);

-- Output the extended information of Partition(c='Us', d=1)
SHOW TABLE EXTENDED LIKE 'show_t1' PARTITION(c='Us', d=1);
-- Throw an AnalysisException
SHOW TABLE EXTENDED LIKE 'show_t1' PARTITION(c='Us');

How was this patch tested?
Add new test sqls in file show-tables.sql.
Add new test case in DDLSuite.

Test build #70470 has started for PR 16373 at commit d5ce86a.

Test build #70470 has finished for PR 16373 at commit d5ce86a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70470/
Test PASSed.

@yhuai @hvanhovell @gatorsmile Would you please review this PR when you have time? Thanks!

Test build #72575 has started for PR 16373 at commit 0020c16.

Test build #72575 has finished for PR 16373 at commit 0020c16.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72575/
Test FAILed.

Test build #72579 has started for PR 16373 at commit 0424edd.

Test build #72579 has finished for PR 16373 at commit 0424edd.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/72579/
Test PASSed.

Test build #74090 has started for PR 16373 at commit 1b2a41c.

Test build #74090 has finished for PR 16373 at commit 1b2a41c.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74090/
Test FAILed.

Test build #74091 has started for PR 16373 at commit fa93c80.

Test build #74091 has finished for PR 16373 at commit fa93c80.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74091/
Test PASSed.

@gatorsmile Does this PR looks good?

@cloud-fan @hvanhovell @gatorsmile Would you please look at this PR please?

Will review this today. :)

What is the reason why we only have the negative one in the newly added test cases?

@gatorsmile Added the positive test cases.

Test build #74451 has started for PR 16373 at commit 77ca941.

Test build #74451 has finished for PR 16373 at commit 77ca941.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74451/
Test FAILed.

Test build #74481 has started for PR 16373 at commit b46d771.

Test build #74481 has finished for PR 16373 at commit b46d771.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74481/
Test PASSed.

Test build #74506 has started for PR 16373 at commit bede7ae.

Test build #74510 has started for PR 16373 at commit 62aee59.

Test build #74510 has finished for PR 16373 at commit 62aee59.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74510/
Test PASSed.

Test build #74506 has finished for PR 16373 at commit bede7ae.

This patch fails PySpark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74506/
Test FAILed.

retest this please.

Test build #74520 has started for PR 16373 at commit 62aee59.

Test build #74520 has finished for PR 16373 at commit 62aee59.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/74520/
Test PASSed.

LGTM

Thanks! Merging to master.


Automated cherry pick of #9657: fix(monitor): monitor notify international and 3.6 bugfix

Cherry pick of #9657 on release/3.7.
#9657: fix(monitor): monitor notify international and 3.6 bugfix

Codecov Report

Merging #9659 (2f11e60) into release/3.7 (ef30d23) will increase coverage by 2.06%.
The diff coverage is 0.00%.

@@               Coverage Diff               @@
##           release/3.7   #9659       +/-   ##
===============================================
+ Coverage         6.00%   8.07%    +2.06%
===============================================
  Files              845     107      -738
  Lines           131233   12968   -118265
===============================================
- Hits              7879    1047     -6832
+ Misses          122653   11801   -110852
+ Partials           701     120      -581

Flag
Coverage Δ

aFlag
8.07% <0.00%> (+2.06%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/monitor/alerting/eval_context.go
37.00% <0.00%> (-1.15%)
:arrow_down:

pkg/monitor/alerting/notifier.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/statusdomainresource.go

pkg/util/k8s/kubeadm/kubeadm.go

pkg/compute/models/syncutils.go

pkg/compute/models/skus.go

pkg/monitor/models/alertdashboard_panel.go

pkg/keystone/models/project_resources.go

pkg/keystone/models/passwords.go

pkg/compute/models/scaling_group_resource.go

... and 726 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef30d23...2f11e60. Read the comment docs.

/lgtm
/approve


Cleanup doesn't happen on SIGINT for docker usecase

I tried to stop the deploy script and re-run it, but it failed with
Starting prometheus container
docker: Error response from daemon: Conflict. The container name "/prometheus" is already in use by container "54dd73e6ae4eed154f04793ef555515575ec948b5558b7aac43ac091615eaf6b". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
Error: prometheus did not start up

As the process is interrupted with SIGINT the containers are left unstopped.

Aaah! Sorry haven't checked the -t option. Jus had a look at deploy.sh and found that terminate option is given.
Closing this issue.

I see the PR related to this issue is been merged. Closing this issue


Fix extra parenthesis (typos)

Just a few extra hanging ) that were cleaned up.

@qJake : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good. Thanks @qJake


Add check for if the owner is trying to open the locked vehicle

still have a low chance of triggering, 10% or so

once this is implemented we can use SetVehicleIsStolen when a vehicle crime is committed and IsVehicleStolen to integrate it with a check in esx_policejob


 I don't know why but if I had to guess I would say it is getting all the model counts for the Records column on the index page. Other ideas/option to disable that maybe?

Encountered the same problem. There is a related issue #2392
I, [2016-07-09T12:08:39.392183 #10]  INFO -- : Started GET "/" for <IP_ADDRESS> at 2016-07-09 12:08:39 +0800
I, [2016-07-09T12:08:39.409836 #10]  INFO -- : Processing by RailsAdmin::MainController#dashboard as HTML
I, [2016-07-09T12:11:32.838041 #10]  INFO -- :   Rendered /var/lib/gems/2.1.0/gems/rails_admin-0.6.3views/rails_admin/main/dashboard.html.haml within layouts/rails_admin/application (665.6ms)
I, [2016-07-09T12:11:32.894939 #10]  INFO -- :   Rendered /var/lib/gems/2.1.0/gems/rails_admin-0.6.3views/layouts/rails_admin/_secondary_navigation.html.haml (1.7ms)
I, [2016-07-09T12:11:33.155430 #10]  INFO -- :   Rendered /var/lib/gems/2.1.0/gems/rails_admin-0.6.3views/layouts/rails_admin/pjax.html.haml (41.7ms)
I, [2016-07-09T12:11:33.168918 #10]  INFO -- : Completed 200 OK in 173759ms (Views: 996.9ms | ActiveRecord: 275.0ms)

@dgobaud If you want to disable the statistics on the index page, you can just add this config:
RailsAdmin.config do |c|
  c.actions do
    dashboard do
      statistics false
    end
  end
end

As in: https://github.com/sferik/rails_admin/wiki/Dashboard-action#disabling-record-count-bars


RHIROS-437 - skip RBAC for prometheus endpoint

lgtm! only ask can we add a JIRA for this or may be add this as a refs PR for any existing JIRA?

+1, make sense! Thanks @apuntamb. Done!

Thanks @kgaikwad! Merged!


chore: build image for digest and release on workflow_dispatch

Definition of Ready

[ ] I am happy with the code
[ ] Short description of the feature/issue is added in the pr description
[ ] PR is linked to the corresponding user story
[ ] Acceptance criteria are met
[ ] All open todos and follow ups are defined in a new ticket and justified
[ ] Deviations from the acceptance criteria and design are agreed with the PO and documented.
[ ] No debug or dead code
[ ] My code has no repetitions
[ ] Critical parts are tested automatically
[ ] Where possible E2E tests are implemented
[ ] Documentation/examples are up-to-date
[ ] All non-functional requirements are met
[ ] Functionality of the acceptance criteria is checked manually on the dev system.

tried to test it on a fork and looks like the secrets are not passed correctly:

https://github.com/zitadel/zitadel/actions/runs/5746648907/job/15576561849?pr=6311


TakeLast optmization for when count <= 0

As well we have for SkipLast.

I think this needs re-basing as TakeLast implementation got completely refactored in dc89b81?

done


[PDI-18333] Null Pointer Exception when using Carte in a clustered mo…

…de- with partitioning schemas

at end of TransSplitter.splitOriginalTransformation() changed logic from
hard setting orignal Transformation partitionSchemas
to append, as to not undue newly created target partitions

:white_check_mark: Build finished in 34m 24s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3677, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message


Add dtype and order to asarray and asanyarray definitions

[x] Closes #8105
[x] Tests added / passed
[x] Passes black dask / flake8 dask / isort dask

I'll leave this here for when @pentschev gets back.

Thanks Julia! 😄 This makes a lot of sense 🙂

@jrbourbeau do you have thoughts on whether we should include this in the upcoming release ( https://github.com/dask/community/issues/180 )?

I realize it predates this PR, but should we be forwarding like, dtype, etc. keywords for the case when the input a is from xarray?

Good point. We should be forwarding all the kwargs IMO.

Thanks Peter! 🙂

All credit goes to @jsignell , thanks Julia! 😄


Greenkeeper/husky 2.3.0

Merging in a safe dependency version bump identied by the Greenkeeper bot

:tada: This PR is included in version 2.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Changed from QueryEscape to standard base64 encoding

Closes #48
Not sure if this is what you were looking for or not, but seemed possible :)

Seems to be OK :)
Thank you very much for contribution!


Add Financial Overview Visualizations to Collective Profile Pages

Kick off and plan
Recording (TBC)
We spoke about the proposal below, the issues with respect to rendering and the possibility of sending reports by email to contributors instead, classification of expenses and the risk that we end up with a lot of fragmentation and our strategic design priorities around profile pages. Generally, the plan is to initially focus on use of funds:

To drive the classification of expenses through tags (which we can rename if needed)
To allow submitters to include tags when expenses are submitted
To limit the ability of submitters to modify tags once submitted
To show the most-used tags in the tag picker to encourage homogenisation but allow freedom
To add visualisations to the 'budget' section that show expenses by tag and type, hidden behind the 'expenses' tab to remove issues with load times.

We acknowledge that there's value in showing information on how users are contributing (recurring contributions are much better for projects, so encouraging that behaviour is a priority), but for the moment, the focus is on how projects are using money.
Some quick sketches of how this might look:

Expenses page

Incidentally that graph is made with real data from the 'webpack' project. Note that metabase automatically accumulates tags that have a small %age representation into 'other' automatically. I think this is a pretty decent pattern.
If we wish to see (we may) how the project is changing it's spending over time we might want to show something a little more like this:

Expenses by year

Background & Context
This proposal emerged from:

Research into open-source projects hosted by OSC about what can be done to make it easier for corporate funders to fund open-source projects. One of the core needs that were identified was to gradually provide funders with more information about the impact of their investments.
A followup inquiry into tagged expenses on the OC platform (seed pitch and discussion ).
A proposal that surfaced on slack on how to visualize contributions.

Proposal
Add visualizations that provide an effective overview of a collective's contributions (incoming funds) and expenses (outgoing funds).
When a funder is considering funding an open-source project hosted as a collective on OC, they want to get a sense of how the project is doing financially (among other signals and indicators). They are trying to decide if the project is capable of handling funding. The current collective profiles provides:

overall totals
current balance
a speculative (not clearly explained) yearly budget
open/transparent ledger
number of recurring funders at each funding tier

This information is insufficient and difficult to integrate into a coherent financial view that answers questions such as:

How long has the project been actively raising money?
Is the funding that it has consistent or erratic - what part of it is recurring and what part is one-time?
How does the project spend the funding that it currently has?

Ultimately, a funder is looking for funding opportunities that are most like to be impactful. These visualizations will not in and of themselves answer this question but they are one step in the right direction. Just having this data visualized clearly is a kind of badge of trustworthiness that a collective is managing its finances. The recently redesigned ESLint website and its donate page  exemplify what this can look like.
Providing this as a given service on OpenCollective to collectives is also a badge of trustworthiness for the platform itself.
The proposal includes two visualizations:

Expenses
Contributions

It is probably preferable to offer the two together, however from the OSC perspective, expenses are currently more important.
Expenses
1: Data integrity preparations
At this point in time this proposal builds upon the existing tagging capability with the following modifications:

Signal "accounting" - change the label "tags" to "categories" in order to change the narrative from "just tag this with whatever seems relevant to you" to "select a sensible accounting category"
Limit categorizing to collective admins - collective admins are the ones creating context and order within the expenses. Currently this can be disrupted by expense submiters (payees) being able to modify expense tags. In the future, in order to protect the data integrity shaped by collective admins it may be necessary to limit payees ability to tag expenses (especially after expenses have been approved and tagged by a collective admin). This is NOT in the scope of this pitch.
Default Tags - in order to account for expenses that are not yet tagged, default tags should be added to them. This will ensure that all visualizations will have and provide some context - even for collectives that have not tagged their expenses or done so only partially. As collective admins encounter the visualizations they will be able to go back and tag expenses and witness the visualizations change. The default categories are derived from the way the expenses were submitted:

Receipts
Invoices

First Tag - in order to prevent double spending (when an expense is assigned to more than one category) we need to:

Only use the first tag when creating the visualizations.
Communicate in documentation that this is the case.
Consider making it possible to indicate in the UI "this is the first tag" by mechanisms such as :

Adding a visual queue to highlight the first tag (to emphasize that this is the one that will be used for accounting).
Drag and drop manipulation to drag a tag to make it first.

Transactions within the platform to other collectives should be incorporated into this;
1. Transactions from other collectives should be incorporated as contributions.
2. Transactions to other collectives should be incorporated as expenses.

2: Visualization

By default the visualization is a pie-chart showing the aggregation of expense categories for the selected period.
By default the graph should appear loaded for the current fiscal year.
Enable the user to select a fiscal year (or all time accumulation).
Optional: enable the user to switch between pie-chart and bar-graph presentations.

Contributions

By default the visualization is set to "all time" + "summary" + "quarterly."
The user can choose to focus on a given year, to alternate between number of contributions and value of contributions and to change resolution "quarterly, monthly, weekly"
Both visualizations (count/summary) discern between one-time and recurring contributions.

Integration in Profile Page

Integrate both visualizations into one new profile section - "Financial Overview.;"
Select default placing in the profile page.
Default to displaying the section.

OSC Community Engagement
attention @RichardLitt

Add to documentation guidance about an initial set of suggest categories (+ crediting Nicholas Zakas and referencing the ESLint website as an implemented example) and make sure those categories are already in the platform (correctly typed) so that collective admins can easily find and utilize them.
Engage with first cohort of admins of collectives who have and use funding and tag their expenses (/ESLint, /transaidcymru, /webpack, /agora, /wwcodeportland, /wwcode) to communicate new feature and talk about how to complete or recategorize in order to communicate effectively with funders.
Select and prepare to engage with a second cohort (5-10) of admins of collectives who have and use funding but do not tag their expenses (after engagement and outcomes from first cohort) who have funding but are not yet tagging and invite them to also utilize this capability.

Future Potentials

Tools for customizing (scope, colors) and embedding visualizations on other websites.
Clicking on graph elements as direct links into the ledger to see the details of expenses and contributions.
Further refinement of visualizations to portray project expenses.
Emphasizing LARGE one-time contributions in relation to many small one-time contributions.

I love this! I think an issue I previously submitted, https://github.com/opencollective/opencollective/issues/5553, can also be an input into this work.
I think an idea to hold as we shape this proposal is that other kinds of organizations will want other kinds of metrics, so I would love for the way this is built to have flexibility around that. The above issue lists a bunch of metrics that are useful for organizations - though some would perhaps be more useful internally rather than for the public.

@natehn

can you add to this pitch specific proposals for increasing clarity on the "estimated yearly budget" field. If you wish, I'm happy to connect and talk this through
I agree, there is potential for more metrics. My intention is that the initial capabilities described in this pitch become a doorway into being able to do and offer more.

thank you @Memo-Es :)
1. Wow!!!
Great looking designs which means that if prioritized we even have designs roughly in place.
2: Process

I would have liked the work you did on #3998 to surface sooner.
I don't feel that issues are a good home for mature works like this, I feel it gets lost ... this issue is even labeled as "stale."
I would like to find ways to get better at holding this kind of information. Seeing 3998 made me wonder what else is out there designed that I don't know about.
If there are more such works buried in our issues, perhaps you can surface them by tagging them with something like "design-concept" and creating a board that presents them?
I would have liked to see "fat-marker" versions of this packed as pitches and offered into our collective space BEFORE committing precious design resources to the detailed work you've already done. In my mind, this detailed work should typically take place after prioritization and tightly coupled with the development implementation work (especially with detailed graphic work like this that will ultimately depend on what components dev will decide to use to implement the designs).

3: Strategy/Priority/Sequence
I agree with you that this will not directly solve the problem space. It is one piece of many - especially in the context of OSC (we  have an extensive research document that we are currently summarizing into a strategy for the coming year that will soon be published).
I also agree with you that it would be better to implement this as part of a wider move of rethinking the budget section.
However:

There are more changes I would like to explore in the budget section (which are not currently reflected in the designs in 3998) regarding access to the ledger itself (which is not necessarily directly tied in with the overview visualizations).
I feel that an overhaul of the budget section would be better served after we take on the challenge you have raised numerous times of redesigning for a logged-in/logged-out user experience with clear differentiation between public facing profile and an "internal" work area.

I think that overview graphs can be approached as a contained scope and integrated into the existing collective pages as is. I think it will have immediate impact AND it will enable us at OSC to move forward with plans to engage with projects to tag their expenses accordingly. Then we can re-integrate and evolve the visualizations as/when we progress on the revamp of the collective profile page and the logged-in/logged-out experience.
I would be happy to allocate time already in the coming weeks to start shaping a pitch for the logged-in/logged-out strategy so that it is well defined and scoped and can be pitched for Q3S2. Then, during Q3S2 we can do a similar process for a revamp of profile pages that can be pitched for Q4S1. If, as was the case in this issue, you have already done some work on these subjects please do share it with me and lets get it ready for pitching :)
For OSC, waiting 3-5 months (2 or 3 cycles) with the overview graphs is too long.

What's the benefit of having that on the public profiles? To me, these look like admin stats that are usually not helpful for random contributors visiting the page. I understand that having this as public info, can be nice for transparency, but I would separate it to a different page (like /transactions or /expenses) as charts can significantly impact the page's load times.

@Betree the research into OSC funders revealed that they look at collective pages as part of their funding-process. They look to see if a project is able to receive money (=on the platform) and if they are able to handle funding well (=the funding is more likely to be used effectively). These visualizations are intended to address the second point. The current available information (totals + ledger) do not address  this well.
I think (though have not researched this outside of the context of OSC) that this can have a positive impact for other collective and funders. The ability to "at a glance" see a historical perspective of a collective's fundraising & spending says a lot about the sustained vitality and viability of a collective. I think that even private/individual sponsors may be interested in this in their decision to contribute to a project.
Also, as you point out, I think that visualizing information this way (verse manually digging into past expenses and transactions) amplifies the commitment to transparency.
As for its location on the collective page, that may change as we delve deeper into two related projects that @Memo-Es  has been holding:

Separating a public-view and a workspace view.
The collective profile revamp.

As these two projects mature these visualizations (along with many other things) may change (but continue to be a valuable building block both in the present and in the future).

We should always default to things being public unless there is a strong reason something needs to be hidden.

I realize my previous message wasn't clear, so to clarify: my concern is not that the charts will be public (I agree we have no reason to hide them), but I'm trying to understand the added value of having that on the profile page instead of a separate one, like /transactions.
My concern here is the fact that charts have a significant impact on pages load times. To me, the goal of the profile page is not to give full transparency on the collective's activity but to be a funnel to redirect people to the info they want to see (for most of them, /contribute).
To caricature my thinking, would you prefer:

Having a profile page with 3 charts that nicely summarize the collective's financial activity but load in 3 seconds
Or having a page with a small link like "View our financial activity" that renders instantaneously

I tend to prefer the second approach. Many (most?) people who arrive there are looking for a way to quickly contribute and already know the project for the page they're visiting. How many of them need to see a historic view of the financial activity before contributing? How many are going to be turned down if we increase the load time of the page? How many (mobile users) are going to be confused because the page they ended up on is too complex and "Contribute" ends up being hidden in a sea of information?

I would agree about putting it on a separate page and linking from the main profile

@Betree thank you for surfacing the issue of performance price.
1: Performance
For me a good starting point for a solution would be something like a gradual page loading mechanism. The initial page could load as is with a placeholder indicating "loading financial overview" ... and then, whenever that is ready populate the page with the visualizations.
I feel this capability may serve us well in the future as we serve more processing intensive results (which are already visible on the OSC roadmap - see for example #5745 ) ... and if I've not mistaken I think already exists on some of our pages (I think I recall blank gray "card elements" loading before being populated with actual content.
2: User Experience
For OSC institutional funders these visualizations are more useful then almost everything else on the current profile page. I suspect this may also be true for some individual sponsors. Anyone who is asking "will my contribution" be impactful is currently in the dark. These visualizations will shed a lot of light into this darkness.
Moving these visualizations to another page will demand more work (finding where to click and clicking to a new page) from the people who can benefit from them and decrease the likelihood of people discovering it.
I also prefer to defer changing our page structures for after we've developed some kind of overall strategy (a project that @Memo-Es is holding and I hope we can advance soon).
Solving for performance by decreasing the odds of this information reaching eye-balls does not feel to me like a good trade-off ... it almost feels like it defeats the purpose of making it available.
3: Caching
In addition to the gradual page loading, I want to suggest thinking (longer term) about some kind of archival caching mechanisms that can reduce loads and increase load times. I am happy to talk more about this.

@iamronen We already have intensive caching on this page. The reason why I was referring to load/render time is that not only do we need to fetch the data (that part can be optimized, even though it's additional work) but we also need the client's device to render it. This cost can be a small delay until the page becomes interactive or the device being slowed down.
Another approach that @opencollective/design took in the past with host reports was to hide the heavy charts under a View historical data collapsable section. It helped to contain the performance impact (the data gets loaded when you click on View) and also simplifies the UI.
I understand the need for OSC and the assumption that it will help their hosted collectives (at least the large ones) seem reasonable to me. I have some doubts that this will benefit smaller collectives, especially the ones under different hosts.
Overall adding them on the collective page is not a blocker for me, but please consider these issues seriously: this is the most fetched page of our website and loading/rendering time/complexity have an impact on project revenues.

@Betree I want to make sure I understand you correctly: are you saying that the 3 second delay would be due to client rendering load (and NOT backend data processing/)?
I will also give more thought to the collapsible pattern you mentioned. It may be possible to couple that with some kind of low-load preview that tells a "preview story" of what can be expected inside  ... something like summary information / useful stats that have value in their own right (instead of just "view historical data") ... so users can make an informed decision  if they want to go deeper.
Another option to explore would be how to roll this out. Maybe we can find a set of criteria for collectives for whom this would be on by default and others would need to explicitly add it to their pages. This may (substantially) reduce initial loads as we roll out this feature.  But I think a mid/long term working assumption should be that this is operational for most collectives aspiring to be real operational collectives (raising and spending money).

The "3 seconds" thing was a caricature, I can't estimate the impact without more precise specs. But surely:

There will be an impact on the loading time (mostly when the page is not cached yet or when we clear the cache)
There will be an impact on the rendering time (esp. on mobile devices)

The two solutions that you mentioned above seem to go in the right direction:

Have an efficient design that takes these concerns into account and tries to reduce the complexity
Rolling out the feature only for the right people, analyze the impact for different kinds of host/collectives

I won't be there to discuss this for the kickoff as it has been planned on a Wednesday afternoon, but @kewitz will be there to provide some engineering perspective.

@poohlaga mentioned that it might be helpful for you all to see some of the math in action. Here are some of the metrics calculated (with my limited skills) in Metabase (note: the dates have to be manually updated)

Q3S2W2 update
Last week we had a couple of conversations about this project, I confirmed that it is indeed our intention to deliver something this sprint. @Memo-Es has pushed on with the design, based on previous thoughts and the pitch by Ronen. I would love for us to be able to start development this week if possible so my goal is getting to a place where engineering is happy to proceed.

[ ] reviewing the deisgns with @znarf @Betree
[ ] discuss further work on expenses process to support
[ ] discuss mods needed from eng side
[ ] ? discuss engineering on the project

Design update
This is the first design proposal I presented on the demo day on August 5th: https://around.co/playback/965e723a-161e-4825-ba24-39ffeefc9596?sharedKey=0b1fa27a-b031-4d9d-8194-1222738d7a14
After today's review meeting, I did some updates to ensure consistency in the experience and interface:

Expenses
Contributions

Takeouts

We are releasing this feature for OSC only for the MVP
We are including this feature as an opt-in, folks are invited to start using it and tag their expenses up to the point they are ready to display the data and turn it on
This sprint cycle the engineering work will focus on spec out the project, including optimization strategies
We should schedule the front-end development for the next sprint cycle

Next steps

We will work on a complimentary design for the turned-off visualizations
We will focus on having the design ready for implementation this sprint cycle
On the engineering side, we will work the following weeks to spec-out the project

1: Design
Thank you for these designs memo, they look good and feel promising.

We discussed the possibility to remove time filtering from the bar charts. They show an effective all time view. This would make implementation easier both in terms of UI and performance.
The time filtering feels like it is necessary for the pie-charts since it provides context to what is being displayed. I would limit this filter to "all time" or one selected year from the past.
I think we can avoid showing the index twice (once for each graph) on the same page. The two graphs have the same index and I think it can be designed as one element along the bottom ... which may also give space to showing more elements.
For expenses I think we should aspire to be able to show 5 or 6 tags + other.
Can the bar-chart on the contributions also be updated to include the tiers (and also relying on the same index)?
I feel like the tabs "expenses/contributions" could use better visual containment ... since they encompass a lot of screen real-estate (the graphs + leader boards). Not sure if this is a priority for this cycle ... maybe we can tend to this when we do the profile page revamp?
To my understanding we do not need a complementary design for collectives that do not opt-in - they will continue to see the same element that is currently displayed on profile pages.

2: Tags
I'd like to re-iterate the constraints we have around tags:

There should be no disruption to the way tags currently operate so as not to take away freedom from collectives/hosts who do use tags (however they use them).
For accounting purposes we need to have one tag which acts as an accounting category.

Here is a proposal for how to handle this on the UI:

Transform the "x" control (for deleting tags) into a dropdown.
In the dropdown display a "remove tag" control and add a "use for accounting" option.
Automatically select the "use for accounting" option for the first tag that is added.
Add a visual queue (eg: highlight) to indicate the tag that has been selected to be used for accounting.
When there is only one tag and the user tries to disable the "use for accounting" option respond with guidance "one tag has to be selected for accounting purposes"
When there are multiple tags, another tag can be selected to be used for accounting and that removes the selection from the previously marked tag.

@Betree / @znarf I suggest adding a field to the database for the one selected field (and this would require some data initiation choices to populate that field for past expenses).

I like the proposal above for tags uniqueness, the UX looks simple and the engineering part should be rather straightforward.
I however think that it's out of scope for this project. This feature still has a lot of unknowns (how are we going to motivate people to use this new tagging strategy? will they do it? how long will it take until people end up with meaningful values there?) and needs to be processed and iterated on by design, possibly with some user testing and feedback gathering first.
To simplify the design and implementation of this project, I strongly think we should proceed in smaller steps and not try to solve everything at once:

How can we display the data that we already have in a meaningful way
How can we improve the way we collect transaction metadata (incl. the tags uniqueness proposal above)
Update the charts to use this new data only on collectives that are using the new tagging strategy

In my opinion, this issue/project should be solely focused on (1). That way:

We reduce the complexity of the project
We can release (and thus try and learn) earlier in the process
We have a fallback solution for all collectives that won't be using the new tagging strategy

Ideas for making sense of the current data
Tags breakdown
We can use a chart type meant to display a collection of non-unique values, like a Polar area chart. Compared to the pie chart, I don't feel like we're losing a critical aspect of the feature here.

Radar charts can also work

Historic view
A line chart can be used to represent the tag's breakdown, without requiring their uniqueness.

A bar chart (with optional line combo) also works.

Great work on these visualizations!

Can it say 'Other/No tag' ?
IMO, 'Today's Balance' is more important than 'Estimated Annual Budget' and should be the one in gray - I'm not sure if this is true for OSC's groups.  But it took me a while before I realized I'd been looking at the wrong number when determining a collective's true budget.
I think that adding these visualizations will help incentivize people to use tags on expenses- when they see these images, they'll want to see a more accurate representation.

That being said, my bank has options for tags for visualization, and I still don't use them, its too many expenses to try to keep up with. I do appreciate the auto-tagging they do as a rough estimate of my breakdown.
Is auto-tag or 'suggested tag' something that's do-able? That way people don't have to keep track of terms for consistency, especially if they have multiple Admins who might make it complicated. And they can just click on an existing tag instead of typing and searching
Or, we set ~7 categories for tags, they have to choose from those (maybe that's already what's proposed here?)

What do visualizations look like for Contributions? Tags aren't relevant here, correct?

@iamronen

I feel like the tabs "expenses/contributions" could use better visual containment ... since they encompass a lot of screen real-estate (the graphs + leader boards). Not sure if this is a priority for this cycle ... maybe we can tend to this when we do the profile page revamp?

Yes, I didn't want to propose a lot of new stuff, so, as you say, I would wait until we tackle the Collective page redesign to do these kinds of UI updates

To my understanding we do not need a complementary design for collectives that do not opt-in - they will continue to see the same element that is currently displayed on profile pages.

Showing the current budget overview falls short of meeting the main goals for this project. I think there's a way of meeting those goals with a graph-less design.
@Betree

Can you help me understand the difference between the charts we have in the proposal and those you propose? I did a small research and found no clear answer on what's the difference between unique and non-unique values

I agree with you that we should focus on rendering what we currently have in a more meaningful way.

I will iterate on this design and present it in this Friday's demo.

@Betree
First on behalf of OSC I can say:

There are collectives that are already tagging expenses and we are going to be approaching them as role models for the community of open-source projects.
We are working at the community level to offer open-source projects training, guidance, and possible services to help with tagging expenses (as one of many other issues).
Your question "How can we display the data that we already have in a meaningful way?" is missing context - meaningful to whom, when and why? In the context of OSC the answer that is guiding us is so that open-source projects can communicate effectively that they are serious about how they use their funding and that they can trusted to use funds effectively in order to make it easier for funders to contribute more funds to them. For maintainers, being able to raise more funds in order to be available to working on the open-source projects they care about is a powerful driver. Funders on the other hand are allies of open-source that want to increase the funding that goes into open-source. To do this they need to be able to "sell" open-source funding within their organizations. This project is a first step (with many more coming) to support this mutual interest  and need.
A "single accounting category" is a critical piece of presenting reliable and trustworthy and unbiased information about expenses. Tags are an inappropriate solution for this. However it is what we have and we need to make the best of it. For this reason, the scope of this project includes a minimal and non-intrusive investment in identifying an "accounting category" from the  data that we have.
The polar area and radar charts are not intuitively clear to me - I don't know how to read them without making an effort to understand what they are displaying. I am assuming that most people will have a similar response to them.
The other charts you suggested answer other potential curiosities about how funding is used such as "how much have we spent on webservices over time?" which may be legitimate questions ... but they categorically avoid the question of the budget as a whole. And it is the budget as a whole that needs to be reliably accounted for in this scenario.
This is why I've asked that the tag-uniqueness be in the scope of this project.

@kaylarep
Yes, there are different potential approaches to explore assistive tagging but this is not in the scope of this project. We may decide to invest in this more in the future, if the circumstances are right. At the top of this discussion thread is a link to some work around categorizing expenses that touches on some of these potentials.
Yes, tags are NOT relevant in contributions. At minimum contributions will be differentiated using one-time/recurring. We are aiming to enhance that by breaking down recurring contributions based on tiers.
@Memo-Es

Showing the current budget overview falls short of meeting the main goals for this project. I think there's a way of meeting those goals with a graph-less design.

I think it is better to invest in tag-uniqueness than in a graph-less alternative.

Can you help me understand the difference between the charts we have in the proposal and those you propose? I did a small research and found no clear answer on what's the difference between unique and non-unique values

@Memo-Es Sorry, I didn't choose the right term - unique was not the clearest here; I should have used "mutually exclusive".
Pie chart
A pie chart is great to represent the repartition of mutually exclusive values among a collection. A count of all the fruits I have in my fridge, for example, would be a great fit because each fruit can only have one family: it's either an apple, a banana, or a peach. It cannot be an apple and a banana.
Layed out on a pie chart, this dataset would help me to clearly visualize that half of the fruits in my fridge are apples.

Why it doesn't work with tags
Tags are a different beast because they're not mutually exclusive. It's a very permissive system where people can put whatever they want. If we look at what we have today on Open Collective, folks submit their travel spending bundles as one expense, and we, therefore, end up with some tagged with food, transportation and accommodation.  food and accommodation are not mutually exclusive, it's fine to have both sets on an expense.
Let's take an example: Open Potatoes has the policy to tag all expenses coming from the core team as core team and from other people as contributors. They also do some categorization, with tags such as food, tools, and travel.
In this context, they have expenses tagged like [core team, food, tools] (when the core team members organized an event where they bought food and kitchen tools at the same shop). Summarizing their 10 expenses, we end up with raw data like:

Core team
Contributors
Food
Tools
Travel

8
2
9
2
1

10 expenses were submitted
8 were from the core team, 2 from contributors
9 expenses included some food shopping
2 expenses included some tools shopping
1 was about travel expenses

If we put that on a pie chart, we end up in this situation:

This chart is fundamentally wrong because it lets me think that about half of the expenses were from the core team, while in practice it's 80%.
Why a polar char works
A polar chart doesn't try to communicate any sense of repartition, it just shows how frequent each item is by making it larger or smaller. Having more of one item doesn't reduce the size of the others.
Applying the same data as before:

Now, this graph tells me that most expenses were coming from the core team, and most of them were about food. I still have the main information displayed, but there's no risk of misinterpreting the repartition.
Stacked bar chart
A stacked bar chart serves the same purpose as a pie chart, only it's meant to display it across time. This graph will not work with the tags as they're used today, because it would create the same false sense of repartition mentioned above:

The lines + bar char combo proposed above, while ugly (I used the quickest tool I could find to generate it), doesn't lie about the data: increasing the count of a given tag won't reduce the size of the others.

Your question "How can we display the data that we already have in a meaningful way?" is missing context - meaningful to whom, when and why? In the context of OSC the answer that is guiding us is so that open-source projects can communicate effectively that they are serious about how they use their funding and that they can trusted to use funds effectively in order to make it easier for funders to contribute more funds to them. For maintainers, being able to raise more funds in order to be available to working on the open-source projects they care about is a powerful driver. Funders on the other hand are allies of open-source that want to increase the funding that goes into open-source. To do this they need to be able to "sell" open-source funding within their organizations. This project is a first step (with many more coming) to support this mutual interest  and need.

This is where our goals differ: your goal is to solve a specific problem for OSC. My goal is to make sure that, while solving this problem for OSC, we don't release a feature that will look trashy for other fiscal hosts and collectives. This is a good situation; if we successfully find a consensus we'll have a solution that we can proudly release for everyone.
I will keep pushing until I'm confident that the proposed solution will be useful for everyone, and I hope you'll continue pushing if the choices we make don't provide satisfying answers to OSC.

A "single accounting category" is a critical piece of presenting reliable and trustworthy and unbiased information about expenses. Tags are an inappropriate solution for this. However it is what we have and we need to make the best of it. For this reason, the scope of this project includes a minimal and non-intrusive investment in identifying an "accounting category" from the  data that we have.

I'm not saying we shouldn't do it, I'm proposing incremental steps to get there with two goals in mind:

Offer a solution that works for everyone
Continuous release

We used to have giant projects where we tried to do everything at once, and we learned with time that this is not the best approach to solve things: we get into technical rabbit holes, and by shipping later we're losing an opportunity to learn with user testing, therefore missing regressions with existing users. Working with incremental steps served us well in the past and I stand with the idea that it's necessary to do it here.

The polar area and radar charts are not intuitively clear to me - I don't know how to read them without making an effort to understand what they are displaying. I am assuming that most people will have a similar response to them.

You're projecting your biased opinion on others, this kind of assumption needs to be verified with user testing and feedback loops.
And even if a pie chart ends up being a better option for displaying expenses usage (I too, prefer to see a pie chart) you're obscuring the fact that most collectives won't use this new tagging strategy and that the graph will be meaningless for them. We need a fallback solution that works for everyone, not just a few collectives that will collaborate with OSC to tag their expenses with this new strategy.

This is why I've asked that the tag-uniqueness be in the scope of this project.

Again, I never said we shouldn't do it. In the plan proposed above, I clearly state that (2) and (3) should be about improving the way we collect and display tags in these charts.

Thank you for the radar chart explanation @Betree - that was informative. However, now that I somewhat understand it, I can't see how it is useful. The real story, as you told it had two tiers: internal/external & utility. The visual presentations tells neither of those stories nor that there are two tiers. It is a visualization of raw-data with no narrative to it. I think narrative is critical in user experience.
The second chart "lines+bar" is interesting and creative and I will mull over it some more. I am concerned that there is a narrative issue - that the visualization implies that things should add up when they don't.
Regarding "useful for everyone":

I am not sure this is a valid requirement. Not every feature is useful for everyone.
I don't think our goals differ (in this case), I think the drive in this case is coming from OSC but I think the feature is as valid for any collective and or fiscal host that wants to take advantage of it (personally, I think it is long overdue).
How many will actually use it is indeed an unknown (though I suspect that, as least for now, probably more then oAuth) and as with many investments we make it is a gamble.  In this case it depends more on social dynamics then technology. It is also important to view this question in a long term perspective: initially only a few may use it but hopefully, over time, more collectives will find their own incentives to do so.
Since this is opt-in, there is no reason this should look "trashy" for anyone. Collectives that choose to use this feature have complete control over how it appears by tagging their expenses.
I take your point on past giant risky projects and I subscribe to the approach of gradual release and development that is iterative and responsive to real needs. I don't think this is the case here.
Per my bias on the charts, you are right, however I believe that in this case "this kind of assumption needs to be verified with user testing and feedback loops" would be much more expensive than tending to the "accounting-tag-category."

Most importantly though: do you feel that we have decision making mechanisms to properly address these apparent differences in value or priority?

I am not sure this is a valid requirement. Not every feature is useful for everyone.

If executed right, I think this feature can be useful for many people. I'd love to see this data for our internal collectives, I'd love to see that data for collectives I'm a core contributor of, and I'd love to see that for old projects I'm contributing to. Why limit the feature for OSC when we already identified that we were missing simple ways to visualize budgets for all collectives?

How many will actually use it is indeed an unknown (though I suspect that, as least for now, probably more then oAuth)

Can you explain why we're comparing it to oAuth? I fail to see the relationship between the two projects.

I think the feature is as valid for any collective and or fiscal host that wants to take advantage of it (personally, I think it is long overdue).

With the current proposal, yes, anyone can take advantage of it. With a very high cost for host admins and collective admins.
The solution I'm proposing above offers a fallback for all people who are not ready to invest the time it takes to update their full expense history and adopt new practices while, for OSC, resulting in the exact same final deliverable proposed in the issue.

Do you feel that we have decision making mechanisms to properly address these apparent differences in value or priority?

Yes. We're using a feedback-seeking process. It's the responsibility of project owners to gather feedback, review it and make decisions that - in their views - represent the best compromise for the project. According to the issue assignees, the project owners here are @BenJam and @Memo-Es. I trust their judgments, even if that means going against my views of how this project should be conducted.

from what I've seen and heard here and in previous conversations:

the need to show how projects are using their money, both in general and over time is valuable for Open Source Collective and Open Collective Foundation
we're leaning into patterns that we already see (people are using tags, people who use tags a lot are using them to categorise expenses)

Yes there's a wrinkle around using >1 tag, and yes we should try to ship something that doesn't involve additional complexity. We can and will prove that doing this is useful for projects before suggesting others spend the time to categorise expenses like this.
@Betree on the visualisations presented:

they should all be $ amount rather than frequency if we're going to provide something useful (I dont think the polar chart meets the use case here)
I think people would still misinterpret those graphs and read them as a double count if they were $ based.

for me an MVP is 'show the first tag, work with collectives that want to categorise their expenses, show the data, see whether there's interest from both collectives and funders'. And I think that's the approach we should take.

Example of an actual graph I use to track spending in one of my OC hosts. Not sure it's the best design, just what was accessible in metabase easily.

Some thoughts before the demo

I strongly agree with @Betree on the goal of designing this feature to be useful for everyone; this feature is very powerful to design for one host only. Not to mention my job is to grow the design of the platform having all users in mind.
I acknowledge the issue of having more than one expense. I think we can solve that with a tag solution like the one @iamronen proposed here.
I agree with @BenJam that the data we show should be based on money to be meaningful. I -  lean towards the first set of graphs proposed originally; anyway, I'm exploring variations anyway

I will show my proposal after taking these points into account tomorrow in the demo.

Design update
Proposal presented on the August 12 demo day. Here are some main ideas I used to build this proposal:

List design first: In this proposal, we leave behind the tabs to swipe between "Expenses" and "Transactions," and instead, we have both Exs and Txs displaying both in columns, each with controls to set a specific time or change the visualization of the data you see on the list, a pie chart, and a historical view. The list view helps us to project the implementation strategy. We can start with an updated budget overview section without any chart visualization and add the pie chart and the historical view later in the dev timeline.
About the tags: For the pie chart and the historical view, we have 2 ways of dealing with tags now as I see it:

Option 1: We implement a solution like the one @iamronen proposed here and we use only one tag for the budget display, or...
Option 2: We let multiple tags be accounted for the visualizations, and when we display the total amount per tag, we add up all expenses with that tag. In addition, explicitly say to the user that the amounts shown per tag include expenses that will reflect their amounts in two different tags and compare that with the frequency to display an accurate pie chart and historical view.

About the consolidated budget I think that the budget of projects and events should be a total and be displayed in the "Today's budget" stat, i.e., if I raise 10k and decide to invest it in 10 different projects, we should show as the total budget of the Collective the total 10k, perhaps with a hint that it's split into 10 projects. @znarf feel free to add more details to this.

Budget / Expenses-List
Budget / Expenses-Pie chart
Budget / Expenses-Bar chart

.
.

Next steps

Decide how we are displaying tags
Decide how we will invest dev time going forward. My vote is to do the infrastructure work first regarding the consolidated budget plus the scoping of the final proposal to be ready to start the front-end part of the next sprint cycle.

[ ] respond with last feedback on above design, before working on mobile design
[ ] hack up a prototype based on expense tag stats (API/frontened)

@Memo-Es discussed on the call today — I don't think the frequency information is that valuable in the above. Proportions should value based in my opinion.

Week 5 update:

[ ] Empty states, finalize production-ready file
[ ] Call out to get feedback from users

Design update
About the settings page

If we only display both options, and those options are boolean (on/off) I think a switch would be a better option than having dropdown menus
The only one that actually makes sense as a dropdown menu is this new 'Overview' option because we would have the old version and a new version, so the second element @kewitz added is not necessary, nor is the mutual exclusiveness of those two elements.
BTW this section of the settings will likely change after we do the Collective page update

Settings page

Some design fixes

I should limit the number of tags displayed to 4 - 5, and after that, bundle the rest to 'Other' and 'No tag' after that
I added lines recurring and one-time in the contribution breakdown
To make it clearer, I added a subtitle to indicate one-time vs recurring and breakdown per tier on the contributions side, and the breakdown per tier on the expenses side
Having in mind the budget consolidation conversation, I included as well a small help text under the main stats to account for the project and events under that Collective's  budget, with a hide and show button

Details hidden
Details shown

cc @alanna @znarf

@Memo-Es

These designs feel overwhelming to ingest ... so many numbers and so much structure to figure out on the page. This almost has the opposite effect that we initially experienced  when you first demo'ed this design "look at all the purdy colors" ... this variation is "eeeek"
I think that 4-5 tags may be too little, I would try to raise that up to 6-7 + other (and I think that other can include untagged). See for reference ESLint
Displaying the tiers separate from the recurring & onetime lines creates overload and disassociation. I would prefer to see one list that includes the tiers + one time contributions.
Regarding extended overall budget information to show projects and events:

While I appreciate you tending to this it feels to me like feature creep, It is not in the scope of the original pitch and I feel that the experience it generates diminishes the experience that the original pitch seeks to create, it feels like a distraction.
It may be better to revisit this somewhere in the revamp process, when we find better containers and correct placement for everything.
Just in case, I've included below a proposal (ignore numbers!) for a more quiet and informative layout for showing budget details for events and projects.

Design update
After the first round of user testing calls, we did a simplification round and changed the layout to ease a load of information a person needs to process while going through the budget overview:
Note: If a Collective doesn't have projects or events active, it doesn't get displayed in the tabs

Expenses
Contributions
Projects
Events

I'm still polishing some design aspects, like adding empty states and mobile views.
cc @BenJam @alanna

Nice integration @Memo-Es :)

I like that the time filter is encompassing the whole thing, but I am not sure that is clearly communicated in the layout. I guess most people will figure this out once they interact with it, but I feel there is some friction there.
Are "today's balance" and "estimated annual budget" effected by the time filter? I am assuming they are not. If that is the case, maybe there can be some kind of visual cue (eg: slightly darker background shade?) that indicates that?
In expense tags why have you chosen to show both "other" and "untagged"?  Given that the number of tags is limited, I think those two can be integrated and leave space for another actual tag.
In expenses and contributions  - what does the "historical view / 1 / 2" control do?
What happens when the number of projects or events increases? (though it may be less of an issue with events because there are less likely to be many active events)
The colors on individual events seem redundant since they are not reflected in the visualization.

@memo @iamronen

From a technical side, I like the previous design where there was only tabled data as the initial render. I think that reduces the loading time and burden on the user's device. Graphs take much more time to render and load than structured text.

If displaying tabled data is not necessarily what we want to go with, it would be nice if there was a way for us to render the graphs on demand meaning the user would need to expand the section to display the graphs.

Related to Untagged/Other combination I think it is worth leaving untagged since it will only display in the table if it is really not being used. It also gives an incentive to tag everything.
Unasked opinion: I'm not sure if I dig the centralized time filter and tabs picker. I don't think there's anything else centralized on the collective page.

Do the main expense and contributions views include events and projects, and then you can further break it down and see events and projects separately? I think the top desired use case will be an integrated view of the entire budget, and if the first screen does not show event and project funds by default it will be misleading.
I think a simpler design would be just contributions and expenses, drop the events and projects tab, and filter options at the top where you can select all (default), or select the existing events and projects from a list to view just that one in the graphs. Similar to the Collective filter at the top of the Host reports screen. If a Collective doesn't have projects or events this selector can not show.
Please add a tooltip telling people how they add tags to expenses or link to that page in docs so they can find out.

Thanks for your latest comments! That was a WIP I'm not really sure to push to dev yet. That is why I wanted more feedback. I will work on the feedback I'm gathering from you and user tests and post an interaction soon.

Some quick feedback:

this is really exciting to have visualizations like this! great work :)
For the 'Time' drop down, would it be possible to also have an option for 'Date Range'?
In the Bar Graph view, when you hover over the specific year, could it hover the total amount? (Recurring + One- Time)?

my instincts told me that the small icon images should also have descriptions of what they are when you hover over them (maybe at a slight delay? like after hover for 2 seconds, the description appears). I know its a bit obvious, but it could still be helpful.

Also here:

Can we change the colours to something more OC, they are quite bright and seem a little tacky to me.

On the 'Profile Page' in the settings can we change the language of the toggl to turn this on? aka. Standard Budget, Visualisation Budget?

I'm doing a design refining round and leaving it published here tomorrow, it will mainly be polishing, and we can do some testing rounds and iterate on the usability on a future release. One important thing to note is that we use a graph library. That's where the small controls and typography use comes from, going forward I would like us to be able to generate those graphs ourselves.
cc @kewitz @kaylarep @shannondwray

I have reached out to ESLint and asked for feedback ... and what follows is a combination of his (Nicholas Zakas) and mine:

The first thing Nicholas asked about was a tool to easily go back and tag expenses.
It seems that the limit on the number of tags displayed has not been implemented (see OCF for example).
It seems that the colors repeat themselves at a certain point (I'm not sure how many unique colors are currently defined) making it difficult to visually discern between tags.
I consider it a loss that the initial display does not show graphs. I think that makes a better impression, is more useful and is what most people will want to see thus forcing them to interact with the page instead of bringing them directly to where they want to get.
The zoom controls that appear in the line-graph mode are unnecessary here and therefore redundant and distracting.
Contributions do not show grouping by Tiers, adding tiers would make this much more useful.
The time periods in the filters are a bit ambiguous. For example: does "this month" mean the current calendar month or the last 30 days . This is somewhat clarified with the x-axis on the line and bar charts, but is not clear on pie charts. (I can imagine there are numerous ways to address this ambiguity).
Nicholas asked for more resolution in contributions - eg: see top sponsors - I think this would be somewhat mitigated if we incorporate tiers.
I think that integrating into this component top contributors / top paid people (incorporated into the time filtering) would greatly complement it and address some more of the things Nicholas asked to see.

I feel like the fiscal hosts' budget should also show how much revenue/contributions they are receiving from the fees they charge

See #5967

@iamronen @BenJam I think we can close this issue and follow up on the feedback issue posted above

Followup feedback issue: #5967


Nonmodal dialog support for web NewWindow Dialogs

If sizeclass is Expanded, single-window web apps support "NewWindow" desktop-like experience with modal dialogs.
Fixed the problem of events leaking through the modal dialog.  Need to be on the lookout for any regressions from these event changes -- will test more thoroughly.

@kkoreilly how do we get tags here to be able to open new window dialog from struct tags:
core/value.go:118
	wb.OnClick(func(e events.Event) {
		if allowReadOnly || !wb.IsReadOnly() {
			wb.setFlag(e.HasAnyModifier(key.Shift), widgetValueNewWindow)
			openValueDialog(v, make, after...)
		}
	})

also shouldn't the same Expanded size class logic apply to mobile platform too (i.e., ipad)?


[chip_if] tap_strap_if.pins as high-Z makes IOs unknown.

chip_if adds muxes to MIOs for JTAG interface. __enable_jtag becomes high-Z when tap_straps_if is disconnected.

The tap_strap_if pins are also connected to IOC5, IOC8 MIOs.

yeah this one is a bit problematic.
we can't really rely on the pins directly for tap strap validity. It should be a combination of life cycle states, only tap-strap0 is more or less dedicated in function.

yeah this one is a bit problematic. we can't really rely on the pins directly for tap strap validity. It should be a combination of life cycle states, only tap-strap0 is more or less dedicated in function.

Yup... I could not think of nice solution here as I do not know the details of the chip interface. So I just skip those pins from testing candidate.

should we just decouple __enable_jtag with tap_straps_if.pins, and let user decide to connect the jtag or not, like this?
  bit enable_jtag;

  assign ios[IoR0] = enable_jtag ? jtag_if.tms : 1'bz;
  assign jtag_if.tdo = enable_jtag ? ios[IoR1] : 1'bz;
  assign ios[IoR2] = enable_jtag ? jtag_if.tdi : 1'bz;
  assign ios[IoR3] = enable_jtag ? jtag_if.tck : 1'bz;
  assign ios[IoR4] = enable_jtag ? jtag_if.trst_n : 1'bz;

So, the assumption is, always TB decides the JTAG connection (by driving IOC5, IOC8)? Then adding bit seems to be good.

So, the assumption is, always TB decides the JTAG connection (by driving IOC5, IOC8)? Then adding bit seems to be good.

yes, TB needs to decide that.

should we just decouple __enable_jtag with tap_straps_if.pins, and let user decide to connect the jtag or not, like this?
  bit enable_jtag;

  assign ios[IoR0] = enable_jtag ? jtag_if.tms : 1'bz;
  assign jtag_if.tdo = enable_jtag ? ios[IoR1] : 1'bz;
  assign ios[IoR2] = enable_jtag ? jtag_if.tdi : 1'bz;
  assign ios[IoR3] = enable_jtag ? jtag_if.tck : 1'bz;
  assign ios[IoR4] = enable_jtag ? jtag_if.trst_n : 1'bz;

IMO setting the TAP straps should be enough intent to enable JTAG. I have fixed this in #15017.


[c9y] Adds new port

Describe the pull request

What does your PR fix?

Adds c9y 0.3.0

Which triplets are supported/not supported? Have you updated the [CI baseline]

all

Does your PR follow the [maintainer guide]

I hope so.

Yes

New port checklist:

Review the code ✅
Check the name against https://repology.org/ / No hits
Check the name against Bing/Google. /  No relevant hits for c9y, but c9y c++ matches.
Check the source code for optional find_packages
Check that the versioning scheme and license match what upstream says / Assumed OK because the port author is also the upstream maintainer.
Check that the source code comes from the upstream project's authoritative source. / Ditto
Check that the generated usage is accurate. / None generated.

You may want to add a usage file in a subsequent PR. Thanks for the new port!


Support border style

Currently, the border style (solid, dashed, dotted, etc) can be set, but the border is always rendered as solid.

This needs to be implemented.

I implemented all important border styling options (solid, dotted, dashed, and none). The other ones can be implemented at some point if there is ever an actual use case for them. There is currently a minor issue with dotted border rendering, but there is another issue to track that (#785).


Validate chia plot.

Hello, i compile plotter for windows, work fine, but if i check plot via original chia.exe:
2021-05-15T05:58:03.707  chia.plotting.plot_tools         : ERROR    Failed to open file E:\test\plot.plot. Invalid number of bytes 31 Traceback (most recent call last). What can i do?  How i can use that plots compiled by my own plotter for original chia gui, harvester etc. Thanks!

We don't support plotting directly with the plotter and not via python. You will have to debug this yourself.

It's my understanding, that you must include combination of farmer public key and pool public key into memo:
https://github.com/Chia-Network/chia-blockchain/blob/7012ca9e07cf0e3e0c82efc73d442ae707ee5a73/chia/plotting/create_plots.py#L82
Not sure if this is right approach but we'd love to use the binary directly as well instead of python bindings.


AoT compilation issue

Hi !
I'm submitting you an issue i'm currently facing when i use your module.
Here is the error log :

Error: ENOENT: no such file or directory, open '/home/nicolasa/project/dummy/dist/node_modules/angular2-busy/index.metadata.json'
at Object.fs.openSync (fs.js:651:18)
at Object.fs.writeFileSync (fs.js:1300:33)
at MetadataWriterHost.writeMetadata (/home/nicolasa/project/dummy/node_modules/@angular/tsc-wrapped/src/compiler_host.js:120:22)
at MetadataWriterHost._this.writeFile (/home/nicolasa/project/dummy/node_modules/@angular/tsc-wrapped/src/compiler_host.js:97:23)
at Object.writeFile (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:67339:132)
at Object.writeFile (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:9117:14)
at printSourceFileOrBundle (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:64234:16)
at emitSourceFileOrBundle (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:64185:21)
at Object.forEachEmittedFile (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:9083:17)
at Object.emitFiles (/home/nicolasa/project/dummy/node_modules/typescript/lib/typescript.js:64170:12)
Compilation failed
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>build: ngc -p ./tsconfig-aot.json && npm run rollup
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/nicolasa/.npm/_logs/2017-09-14T07_54_44_533Z-debug.log

You'll be able to find a small project that reproduce this issue at : https://embed.plnkr.co/IdODE3Wyz9oNuINfnYp7/
Can you give me a hand to know if it comes from your module or one of my config file ?

It seems like ng2-busy breaks AOT compilation. Is there a fix planned?

@Mattnmoore: This was fixed in this unmerged PR: https://github.com/devyumao/angular2-busy/pull/67.

Any plans to merge it in?

ngx-busy
https://www.npmjs.com/package/ngx-busy


How to check vm rebooting status

Our pipeline has a VM restart step in between and downstream steps have dependency on successful rebooting of the VM. How can we verify if the VM has completed rebooting through API?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: be8729fb-9c09-1872-be3f-8a0dc1a93d38
Version Independent ID: 51bba8e0-91a8-38c0-5ec2-9309687985b9
Content: Lifecycle and states of a Windows VM in Azure
Content Source: articles/virtual-machines/windows/states-lifecycle.md
Service: virtual-machines-windows
GitHub Login: @shandilvarun
Microsoft Alias: vashan

Thanks for the feedback! We are currently investigating and will update you shortly.

You can find the REST API commands to restart the VM here:
https://docs.microsoft.com/en-us/rest/api/compute/virtualmachines/restart
After issuing that command, once the restart is complete you will be issued a response of Accepted once the command has started and OK once it has completed

Name
Type
Description

200 OK

OK

202 Accepted

Accepted

Sometimes though, for example if running Windows the OS might take a bit longer after the operation has completed before the OS is back up and running.
You can use the instance view to get better info on the OS state at that point in time
https://docs.microsoft.com/en-us/rest/api/compute/virtualmachines/instanceview#virtualmachineinstanceview
https://docs.microsoft.com/en-us/rest/api/compute/virtualmachines/instanceview#instanceviewstatus
Another suggestion would be to add a pause to allow the OS to fully come up. Something like wait 2 mins before moving on to the next step.
There is not an ideal way to get the Guest OS status using API as the APIs just check the status from a platform perspective. So adding a wait would be my suggestion.

I will close this but if you have further questions let me know and we can always reopen and continue the discussion.


Fix the readMe so that is has valuable info

I want to see a better description and maybe a roadmap.

Working on this now

Included in pre-release v0.0.1-alpha


error with .vue component

Hello! Can you help me please?
Vue.js version
2.1.10
vue-loader: 11.0.0
vue-template-compiler: 2.1.10
<template>

        <textarea :value="content"></textarea>

</template>

works fine, but
<template>

        <textarea :value="content"></textarea>

</template>

throw me an error:
[Vue warn]: Error when rendering component  at c:\OpenServer\domains\aqproject\frontend\vue\wysiwyg.vue:
TypeError: _vm._v is not a function
whats wrong with this core?

Thanks for filing the issue. Please follow the Issue Reporting Guidelines and provide a minimal JSFiddle or JSBin containing a set of reproducible steps that can lead to the behavior you described.
Why is this required?

sorry, this was because of library conflicts. ty


As a Project Coordinator, I want to see a list of the uploaded files for a project so that I can easily see all relevant documentation

Description:
As a Project Coordinator, I want to see a list of the uploaded files for a project so that I can easily see all relevant documentation
Acceptance Criteria:
Given I am a CIF user
When I view a project
Then I can see a list of all the attachments
Given I am a CIF user
When I list the attachments from a project
Then I can access the details of each attachment: title, description, project phase
Given I am a CIF user
When I list the attachments from a project
Then I can access metadata for each attachment: submission date & time, user, attachment category, file size
Development Checklist:

[x] Attachments table has the following columns

[x] Title
[x] Description
[x] Date and time submitted
[ ] Project state

[x] Attachments table can be paginated, filtered and ordered
[x] Wireframe completed and linked to this ticket
[x] Meets the DOD

Personas:

Operations Team

Design:

Do we need a UX Design ticket to wireframe how this should look to support the development of this ticket?

Tagging @rajpersram

Tagging @rajpersram

Yes, I think a wireframe is necessary for all the main pages or tabs with co-design sessions needed for most of the busier pages. I don't think this one in particular necessarily needs a co-design with CIF but certainly input from the devs would be great.

Thank you for the clarification @rajpersram . Could you ensure there is a ticket in the backlog for designing the wireframes that support this user story. Depending on capacity and need, this may be something we can start fleshing out in more detail next sprint.

Set 113 as a prerequisite.

Adding applicable Personas to the ticket
Operations Team - Persona

Do we want to differentiate Uploads from Attachments? Currently a subtab of a project is Attachments and the wireframe for that exists on the Co-Design Miro board.

See ticket 72 for wireframe of the attachments screen.

Hey team! Please add your planning poker estimate with ZenHub @AlexZorkin @dleard @pbastia

the form to upload attachment metadata still needs to be built in #478

Thank you @pbastia ! Closing this ticket and will test with #483, which will implement on dev.


Make sure that getOutputStream() has not been called when using getWriter()

##When Undertow writes an error, it always calls getWriter(). The method can throw an exception if getOutputStream() has been previously called in the response's lifecycle.
This PR proposes to use getOutputStream() in that case to avoid any error thrown by the servlet container.

Can one of the admins verify this patch?

I have addressed this in a different way (by resetting the writer state before doing an error dispatch). See https://issues.jboss.org/browse/UNDERTOW-654

Ok great.


pytorch version

I followed the instructions for installation.
It seems that environment.yml does not automatically help me install pytorch -- so after I activate the pytorch-all environment, I install manually with pip install pytorch (which is 1.4).
Then I got this error "pytorch_points/_ext/torch_batch_svd.cpp:18:75: error: ‘THCState_getCurrentBlasHandle’ was not declared in this scope".
I believe this could be caused by wrong version of pytorch. Any suggestions for solving this issue?
Thanks.

For pytorch 1.2 I got
pytorch_points/_ext/torch_batch_svd.cpp:59:33: error: expected primary-expression before ‘float’
const auto d_A = A.data_ptr();

Updated the installation instruction, now the environment is created from pytorch_points subfolder.
Also updated pytorch_points, which uses pytorch 1.4.0 and should have these compilation errors resolved.
commit https://github.com/yifita/deep_cage/commit/f012fdadbdb0306562e09f364d0f2af243624fb2

Thanks!


[Bug]: MaxListenersExceededWarning caused by process.on('exit')

Minimal, reproducible example
import puppeteer from "puppeteer"

const browsers = []
for (let i = 0; i < 10; i++) {
	const browser = await puppeteer.launch()
	browsers.push(browser)
}

console.log('All running...')

Error string
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit.
Bug behavior

[ ] Flaky
[ ] PDF

Background
I want to run multiple browsers concurrently, with a different configuration for each one.
Expectation
To let me run multiple browsers concurrently.
Reality
I get MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
After some research, I found out it's because each browser is adding an on exit event listener to the main process, and max listeners is set to 10 by default. @puppeteer/browsers/lib/esm/launch.js:104
I'm not sure if it's a bug, or there is a workaround to merge all listeners to avoid the warning and possible memory leaks.
This could be a solution, altought it's not very clean:
import puppeteer from "puppeteer"

const browsers = []
const listeners = []
for (let i = 0; i < 10; i++) {
	const browser = await puppeteer.launch()
	browsers.push(browser)

	const lastListener = process.listeners('exit').at(-1)
	process.off('exit', lastListener)
	listeners.push(lastListener)
}

process.on('exit', () => {
	listeners.forEach(listener => listener())
})

console.log('All running...')

Another way could be adding the opt to avoid handling of process on exit event (just like handleSIGINT, for example), and handle it manually:
import puppeteer from "puppeteer"

const browsers = []
for (let i = 0; i < 10; i++) {
	const browser = await puppeteer.launch({ handleExit: false })
	browsers.push(browser)
}

process.on('exit', () => {
	browsers.forEach(browser => browser.kill())
})

console.log('All running...')

Puppeteer configuration file (if used)
No response
Puppeteer version
22.6.2
Node version
20.12.0
Package manager
pnpm
Package manager version
8.15.5
Operating system
Linux

Also, you can use process.setMaxListeners to set the number of instances you expect to launch. I don’t think it’s a bug, Puppeteer needs those listeners per launched process.

Also, you can use process.setMaxListeners to set the number of instances you expect to launch. I don’t think it’s a bug, Puppeteer needs those listeners per launched process.

First of all, there must be a reason why the warning is set to 10 by default. Disabling it isn't my cup of tea.
The listeners are not from the launched processes, but from the main proccess where node is running. Each browser is creating an event listener on the main process to kill himself on exit. But too many browsers means too many listeners, and that's why the warning is being triggered.
The solution is merging all browsers to the same event listener that kills them all, and not creating a new event listener for each one.

First of all, there must be a reason why the warning is set to 10 by default.

I actually don’t know why 10 is okay but more than 10 warrants a warning. I would be curious to learn.
It sounds like it’d be better to work around the warning on Puppeteer side.


Delete a file in a bucket

The users of my web-app have the ability to upload a few files. Our app needs to process them before uploading then a GCP bucket, in a small folder hierarchy. Today the Spring Resource API of GoogleStorageResource allows it to create them.
Our users also need to be able delete those files when they are not longer used.
Giving my users direct access to GCP is of course not a viable option.
I cannot find an API in GoogleStorageResource  that would allow deleting them or the folders they are stored in. When our resource storage facility is backed with the local file system instead of GCP, I can use getFile() to get to File.delete().
Would it be possible to add a deletion API to GoogleStorageResource  so I can delete those files and folders?

Have you tried using the Blob?
GoogleStorageResource file = ...;
file.getBlob().delete();

I did miss that, so thank you.
Unfortunately when I tried it getBlob() returned null for folders, so I also learned that folders are not first class citizens.
Instead I now iterate over all the blobs in the bucket of my folder and delete those whose blobName starts with my folder's blobName. When all the blobs in the folder are deleted, the folder magically dissappears!
Thanks for the pointer, it did take me out of my dead-end.


[ci] prevent graphviz tests from leaving behind files

Contributes to #6361
Prevents the following files from being left behind when the Python tests are run:

Tree4.gv
Tree4.gv.pdf

The graphivz artefacts from tests/python_package_test/test_plotting.py now go to the pytest tmp_path and are deleted after test run.

Noted and adressed your comments @jameslamb thanks for the prompt review

Please update this branch to the latest master (to pull in recent CI fixes), and fix the issues reported at https://github.com/microsoft/LightGBM/actions/runs/10605651987/job/29394936451?pr=6626.
You can fix those by running the following from the root of the repo:
pip install pre-commit
pre-commit run --all-files

@borchero According to https://github.com/microsoft/LightGBM/issues/6361 these are the last two causes of test "leftover" files. I am okay with merging the two PRs.

Have not merged #6627 as the total code diff is small and they share the same purpose. I let the moderators close the other PR.

Thanks for the approvals. I am very pleased with this first minor contribution to a package I have been using with enjoyment and satisfaction! Let's see if I can add more to it in the future.


Make DeltaTable clonable

Description
Simply add Clone attribute to DeltaTable as well as the contained DeltaTableConfig (see #1172 for motivation).
Related Issue(s)
Closes #1172
Documentation

While in principle a minor change, I am not 100% certain the we can promise to maintain that going forward. Cloning the internal state is potentially very expensive, in some cases for e.g. streaming ingest prohibitively so. And we are currently looking into some potentially significant changes to our state handling.
That said, we are eager to support anyone adopting delta.rs - especially on the Rust side. However I am not entirely sure I understood the issue. In our tests we use the register_table methods - at lest on the context object - with relative ease. In which scenario would we update the registered table? When the underlying table got updated?
Would it also be sufficient to make DeltaTable::new_with_state a public method, so you could clone the state directly and create a new table from that?
Then again, maybe I am overthinking this :)

Cloning the internal state is potentially very expensive, in some cases for e.g. streaming ingest prohibitively so.

Oh I see. I was wondering what was the reason for the lack of Clone.

In which scenario would we update the registered table?

One scenario is multi-node deployment; if a write gets executed on one node we want to load the table on the other node(s) to pick up the changes. For instance if the tables are stored as tables: RwLock<HashMap<Arc<str>, Arc<DeltaTable>>> it would be easiest to just call load on them, but that is not doable since Arc can't deref to a mutable variable (which load needs). (We define the tables map like so since it's handy to satisfy the entire SchemaProvider interface.)
The next simplest option is to clone the table to a new mutable variable and then call load on it, hence this issue/PR.
Alternatively, I can rebuild and load the table from scratch when Datafusion requests it via SchemaProvider::table which is slightly more verbose but should work, so I'll try that instead.
So I think DeltaTable::new_with_state can stay private outside of the repo for now.
Thanks.


Updated Contribution Guidelines.

A suggestion to reinforce the contribution guidelines to avoid that new contributors make the same mistake I made.

@jadb Thank you. It is done.

Thanks!


Respoonsive for the mobile screen to enhance the user experience on all device

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Responsive for the mobile screen

Use Case
It should be responsive  for the all users.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I'm a SSOC'24 contributor
[X] I want to work on this issue

@Utsavladia It's been resolved.

can you assign me this issue?


Some components lack unit tests

💩 How it is currently developed
During our early development, we did not create a stable unit testing structure. After a few weeks, we develop our Jest infrastructure and our new components all have proper unit tests, but some of those don't.
The list of components that lack proper unit tests are:

[x] src/components/KeyResult/ConfidenceTag
[x] src/components/KeyResult/DynamicIcon
[x] src/components/KeyResult/View
[x] src/components/KeyResult/List/Head
[ ] src/components/KeyResult/List/Body/Static
[ ] src/components/KeyResult/List/Body/DragAndDrop
[ ] src/components/KeyResult/List/Body/Columns/Base
[ ] src/components/KeyResult/List/Body/Columns/ConfidenceLevel
[ ] src/components/KeyResult/List/Body/Columns/ConfidenceLevelColors
[ ] src/components/KeyResult/List/Body/Columns/Cycle
[ ] src/components/KeyResult/List/Body/Columns/KeyResult
[ ] src/components/KeyResult/List/Body/Columns/Objective
[ ] src/components/KeyResult/List/Body/Columns/Owner
[ ] src/components/KeyResult/List/Body/Columns/Progress
[ ] src/components/KeyResult/List/Body/Columns
[ ] src/components/KeyResult/List/Body
[ ] src/components/KeyResult/List
[ ] src/components/KeyResult/Single/Sections/CheckIn
[ ] src/components/KeyResult/Single/Sections/Cycle
[ ] src/components/KeyResult/Single/Sections/Description
[ ] src/components/KeyResult/Single/Sections/Objective
[ ] src/components/KeyResult/Single/Sections/Owner
[ ] src/components/KeyResult/Single/Sections/Title
[ ] lib/apollo <-- I suggest doing a major refactor here

🌟 What is the optimal solution
All components that handle complex logic should have unit tests.
😓 Why we did that way
To improve our development speed.
💣 What are the possible impacts
In the future, we could break some of those components without knowing it.

Closed since we're now managing our engineering priorities on this Jira board.