feat: add shortcut to open troubleshoot modal

Details

feat: add shortcut to open troubleshoot modal
Fixed Issues

$ https://github.com/Expensify/App/issues/43256
PROPOSAL: https://github.com/Expensify/App/issues/43256#issuecomment-2157181996
Tests

Open web/desktop app and press CTRL/CMD + D

Verify that the troubleshooting modal shown up

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Open web/desktop app and press CTRL/CMD + D

Verify that the troubleshooting modal shown up

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Asked for a Spanish translation here (might be an internal channel)

Unassigned myself since Jules is assigned to the linked GH.

@Julesssss Do we have any updates on the Spanish translation?

@Julesssss Do we have any updates on the Spanish translation?

Still waiting, but I just bumped the request 🤞

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/35371050/f1e8eafa-e594-4908-9f06-86cf29294739

Android: mWeb Chrome

iOS: Native
https://github.com/Expensify/App/assets/35371050/29ee3c0e-3d10-4d30-9ef2-d49deec36cd5

iOS: mWeb Safari
https://github.com/Expensify/App/assets/35371050/64bb52d4-0d19-42d3-9990-a09519746d3b

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/35371050/95342367-84ba-4269-ad4f-685bf183d5e9

MacOS: Desktop
https://github.com/Expensify/App/assets/35371050/928e0a95-9f07-4439-aae2-85a60ab3929a

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.85-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.85-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

Hi friends! This looks like it crashes the app, uh, sometimes. I haven't figured out why yet, but we've got a deploy blocker - https://github.com/Expensify/App/issues/43897

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.85-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/AndrewGable in version: 1.4.85-7 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Extend the database to support cover art URL fields for podcasts

This is for podcasts, not episodes. Also throw in a string field for storing the author.
Acceptance criteria:

Each podcast has a field for the URL to a cover art
Each podcast has a field for the author

Done! Added the cover_url and author VARCHAR fields


Can't use ember-place-autocomplete component in acceptance tests

Trying to use the component in an acceptance test caused this exception:
Assertion failed: You have turned on testing mode, which disabled the run-loop's autorun.
You will need to wrap any code with asynchronous side-effects in an Ember.run

This guide was helpful in figuring out what the heck was going on:
http://discuss.emberjs.com/t/guide-asynchronous-side-effects-in-testing/2905
Opened up a pull request: #40
This wraps the place_changed handler in a run loop.

Thanks @arthur5005.


chase: init at 0.5.2

Motivation for this change
NixOs handles different versions of software contemporary installed on a NixOs installation.
Dispatching is done via symlinks.
"Chase" automatically resolves  to the last target of a chain of symlinks avoiding looping.
I think its a valuable tool for any NixOs admin and is good company for "which".
Things done
Added chase under pkgs/tools/system/chase
Its empowers "which" that is installed in the same pkgs path

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Merged in e0878ce3163272f097b14f36dd61adca18257799 note I collapsed your commits in to one with the text "chase: init at xxx". I also fixed the hyphen in the name. Thank you!

 I did that in fa89f84c546b2f7e669cacb4e457e2460a487e0a.

Hi graham,
in e0878ce you changed the hyphen to dash ..... the original file on the debian repo has a hyphen in its name to seperate name and version . Your change broke futchurl downloading src .

Oh, can you create a new pr with a fix?

Ok fixed the hyphen issue and  avoided fully qualified attribute names as you suggested

well Graham Christensen already fixed it in the nixos repo directly ,
should work right now.
2017-01-04 11:31 GMT+01:00 Daiderd Jordan<EMAIL_ADDRESS>
Oh, can you create a new pr with a fix?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/21590#issuecomment-270340763, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AXuc4p3B3Xxm_qveoSdIPZVtcsEzkqksks5rO3UFgaJpZM4LZHwE
.


Custom Play Button for Video - MHImageViewController

Hello,
Is there any way to custom the play button?
I dont see any way to access the MHImageViewController properties.
Thank you

MHGalleryCustomImageBlock(^UIImage *(NSString *imageToChangeName) {
return nil;
});


Server side error message

Display the server side error message when it is provided.

Don't merge yet, tests aren't passing.


CPP code...

Write a CPP considering an array of numbers having 1 to 10^6 digits sort the array elements in non decreasing order

heyy assign this to me !!! sir


fix: resolving of paths in vueCompilerOptions

Have just tried https://github.com/vuejs/language-tools/pull/2267 and it totally didn't work because the path resolving always returned undefined.

Thanks!


Settle on consistent framebuffer binding semantics for renderers and filters

Related to #52.
The right approach might be that all renderer/filter parameters specify an optional output framebuffer. The convention is:
If an output framebuffer is specified, bind that framebuffer at the start of the renderer/filter evaluation.
If an output framebuffer isn't specified, don't bind a framebuffer.
At the end of evaluation, the framebuffer (if any) is left bound.
The jcanephora API can eliminate redundant framebuffer binds. The above rules should allow for the minimum number of binds whilst also allowing renderers/filters to output to user-created framebuffers or to the screen.

Using a stack-based framebuffer context seems like the right way to go.
This would work similarly to use the texture unit allocator abstraction that exists now. Code
can freely bind framebuffers using the context, and unbinding a framebuffer restores whatever framebuffer was previously bound. Redundant binds are eliminated.

The stack abstraction is actually the wrong choice. The problem isn't in maintaining a stack discipline (like it tends to be with texture units), but is about reducing the number of bindings that occur. The render target stack actually makes this slightly worse, because it's continually rebinding the default framebuffer.
The https://github.com/io7m/jcanephora/commit/884066e68cf711b8cf8d2738391fab7d3e51202a commit has made redundant bindings free, so the original idea seems to be the correct one.


Error Icon on Manage (gear) when Settings json is formatted incorrectly

Problem
Working with students learning to program for the first time, we have them edit the settings manually (so they don't overwrite other settings by pasting in a file and do not get lost scrolling). Many of the students do not format the user settings correctly which results in subsequent issues the new students don't understand. When helping them, we don't realize the settings were typed in incorrectly (especially helping remotely).
The instructions to modify the settings include all the formats, the students don't follow the instructions or don't understand why quotes and commas are needed.

Feature
When there is an update, we see a blue 1 on the Manage Gear (pictured above). Is it possible to add a red icon on the gear if the settings.json file is unreadable for the user settings (not the local/workspace folder .vsc/settings.json? Some sort of icon so people modifying the setting.json know there is an error. There are many that don't notice the red squiggle lines underneath. Hopefully it will save time when solving issue why VSC isn't finding the program path correctly.
Any icon on the Manage Gear would be fine, as long as it distinguishes there is an error in the user settings.

It is a feature request / suggestion. No issues when running Visual Studio Code.
Feature suggestion to help handle user error.

Out of curiosity, which settings are these students changing that can't be edited in the settings UI?

Of course! This isn't a desperate feature, but after TAing this class for 6 semesters, students don't read the instructions fully and to save time when installing in lab, it is easier to have them type based on a list.
Since the set-up tutorial is a nightmare to edit every semester, having them edit the setting in the json saves me time (since I can't easily get access to a "blank" computer to do the installation fresh each time to ensure the order hasn't changed and update screenshots).
Most of the settings can be edited in the UI, but they are spread out all over the setting page.
We normally have them change (Mac and Windows):

python.linting.enabled
python.linting.pylintEnabled
git.path (Mac due to issues with xcode and older versions of the OS)
git.enableSmartCommit
files.autoSave
python.pythonPath
terminal.integrated.shell.windows (this is rare now with the terminal picker integrated into Windows ... but students still manage to cause a problem)

Now this can all be solved in the UI, just trying to optimize the installation process for a large class.


Add plugin-all module

Purpose of the pull request
All plugin module should be composite of plugin-api, plugin-all module, we can directly rely on plugin-all module to install the plugin.
Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Codecov Report

Merging #13079 (3d475cb) into dev (2792c45) will decrease coverage by 0.10%.
The diff coverage is 21.86%.

@@             Coverage Diff              @@
##                dev   #13079      +/-   ##
============================================
- Coverage     39.32%   39.21%   -0.11%
+ Complexity     4275     4273       -2
============================================
  Files          1069     1069
  Lines         40180    40311     +131
  Branches       4611     4634      +23
============================================
+ Hits          15801    15809       +8
- Misses        22600    22723     +123
  Partials       1779     1779

Impacted Files
Coverage Δ

...uler/api/controller/ProcessInstanceController.java
70.21% <ø> (ø)

...r/api/controller/WorkflowInstanceV2Controller.java
84.61% <ø> (ø)

...uler/api/service/impl/DataAnalysisServiceImpl.java
36.49% <0.00%> (-45.48%)
:arrow_down:

...scheduler/api/service/impl/ProjectServiceImpl.java
62.79% <ø> (ø)

...server/master/utils/DataQualityResultOperator.java
0.00% <0.00%> (ø)

...olphinscheduler/plugin/task/linkis/LinkisTask.java
0.00% <ø> (ø)

...heduler/api/service/impl/ResourcesServiceImpl.java
38.65% <63.63%> (+0.03%)
:arrow_up:

...heduler/api/controller/StatisticsV2Controller.java
84.00% <84.00%> (ø)

...r/api/service/impl/ProcessInstanceServiceImpl.java
63.96% <88.88%> (ø)

.../org/apache/dolphinscheduler/api/enums/Status.java
100.00% <100.00%> (ø)

... and 8 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Create 0002-add-secure-heap.patch

Merged from here
https://github.com/linaro-swg/linux/compare/e31dd54997^...961993fde6

This is very good that there is a link to the original patches in the comments here (which will not be included into the git tree itself). But you should have added the 3 original patches here, not the combination of them missing the original headers etc.


IA-2356: Import DHIS2 pyramid is failing while connection test is successful

Explain what problem this PR is resolving

For some case the dhis2 test connection succeeded  even when the dhis2 url was wrong
This PR is to fix that kind of bug
Related JIRA tickets : IA-2356

Self proofreading checklist

[x] Did I use eslint and black formatters
[x] Is my code clear enough and well documented
[ ] Are my typescript files well typed
[ ] New translations have been added or updated if new strings have been introduced in the frontend
[ ] My migrations file are included
[ ] Are there enough tests
[ ] Documentation has been included (for new feature)

Changes

Added a check on 404 response status code
Added a check on the api/system/info to validate the url authenticity

How to test

Go to the data source list
Create or edit a data source
Modify the dhis2 url, password or username
check if it succeed or fail

Print screen / video
Screencast from 2023-08-17 11-37-11.webm
Screencast from 2023-08-17 11-49-01.webm

Looks good to me


Regression bug since CryptoJS is external library dependency: obfuscated fonts SHA1 (byte array)

Fixed here: https://github.com/readium/readium-js/commit/51948fffd7288c69c3ad762e239b765c53f8aad5#diff-725fd66068801adf5d7c9df7d42d3842L109

Re-opening until fix is verified in release 0.22.1


New row from empty grid

Clicking the green + to add a new row works great if I initially load the grid with data and there are rows to start.  If I start with no rows, how do I tell the grid about the schema of my data so it can insert the first row when the green + is clicked?  I am using the controller and tried returning a new object with null values for each property.  I just see the trashcan by itself in the middle of the row.   If I click the empty row, I see the green check and red x as if there is something there.  See attached screen shot.

It should not matter whether you loaded any data or not. Describe fields (columns) of the grid in the config. The grid should work just fine allowing you to add new data and afterwards you can access these items in data option like $("#jsGrid").jsGrid("option", "data")


Tag new release

Not working now, because trying to install from version that is not deployed and not locally.

Closing until getting instruction on how to release a new version.


ISPN-13261 Server parser and configuration refactoring

https://issues.redhat.com/browse/ISPN-13261
https://issues.redhat.com/browse/ISPN-13284
https://issues.redhat.com/browse/ISPN-13283
This PR refactors the Server parser and configuration to achieve the following:

construction of the security realms and implicit setup of the endpoints/connectors happens after parsing is complete, not during
the parser now supports unordered elements which should help out with YAML/JSON configurations which have been processed by external tools
Resolution of paths is done after parsing and relative-to property names are retained
Bug fixes to the schema and some of the realms (mostly LDAP)
Upgrade to Elytron 1.17.0.Final
Use the Infinispan timeout executor for the Elytron SecurityDomain

Bonus points for removing more lines than are being added :)

It's still not possible to have endpoints elements proceed socket-bindings due to applySocketBinding being called from the EndpointConfigurationBuilder constructor.

Let me fix that

YamlConfigurationReaderTest failure fixed since last build ... merging.
Thanks @tristantarrant


Adding the script to download and process the GPCC file

This GPCC file is monstrous: it has more than 40 million rows. The process to match latitudes and longitudes is very intensive in terms of computing power and my laptop crashed like 4 times trying to do it.
Finally I decided just to try the code with a smaller sample and it works, so it would be amazing if someone else could try it to be sure if it works with the full file.
Closes https://github.com/jessegrabowski/laos-climate-change/issues/20

We don't have a super high level of geographic resolution on our other datasets, notably EM-DAT, so we're going to have to summarize down the data. My suggestion would be to loop country by country and compute its average value.

I agree, but to have the country values, we have to match the latitude and longitude data with the shapely.Points and then geo merge the shapefile with the GPCC monster file, and there is where my computer explodes.
Tomorrow my new computer arrives, so maybe I will be able to do it.

We don't have a super high level of geographic resolution on our other datasets, notably EM-DAT, so we're going to have to summarize down the data. My suggestion would be to loop country by country and compute its average value.

The draft of the function is ready for review.


Don't drop uplink when frequency is not supported

We don't have to drop uplink messages when their frequency is not supported in duty-cycle calculator. Instead, we should process them like any other message. Downlink responses and ACKs can be dropped when the frequency is not supported.
For staging: Forward to Croft is not affected by this.

This is handled in the refactor branch. See #199 for more info.


there is no open Java class file shortcut

i search the VScode doc，but i  can not find the shortcut that can open the 3rd lib class file.

You have to install java extension and if you don't find it then please file issue against the java extension.


Problem when points are occluded

Hi @Seokju-Cho ,
I recently ran your method on a custom video (the one depicted in Fig. 6 of your paper). Overall, the results are impressive for visible points, but I'm encountering significant jittering with occluded points. Below are the visualizations illustrating the issue:

First, when I disable the occluded point, the result look good

https://github.com/user-attachments/assets/9df913d0-1e1b-413b-8c4a-fec384cea070

Second, when both visible and occluded points are visualized, the occluded points exhibit a lot of jittering:

https://github.com/user-attachments/assets/5cac3ea4-5a2b-4b9d-896f-b8160c05ebcb
Given this, I'd like to inquire if this jittering issue is due to a bug during inference or if it's an inherent problem with the method. Here are my thoughts on possible causes:

Training Loss Calculation: During training, only the Huber loss for visible points is calculated, preventing the model from learning to predict accurate positions for occluded points.

Correlation Map Reliance: The initial predictions depend on the correlation map, which yields incorrect results for occluded points, leading to erroneous refined predictions.

Could you please provide insight into this issue? Any guidance or suggestions for addressing this would be greatly appreciated.
Looking forward to your response. Thank you!

Hello, I encountered the same issue, and I would like to know how to disable occluded points.


Invoice Unit price!

Hello,
been testing the system and set the pricing in Integration Settings>Pricing Dimesions>Energy as per kWh, and the calcs are correct but the unit price is not showing in the invoice!
This was done with the ev-simulator.

anybody?
I also tried in stripe but cant get it to work!

Hi, can i see your pricing definition?

I think the unit price is associated to the flat fee. If you add a flat fee of test, the unit price might return the flat fee

but I want to use the Enrgy, isnt that possible?

What I am telling you is, the first row of the stripe invoice is exclusively for the flat fee on your Price dimension.
If you want to have the energy price, you can change the code to put it in the first line

What I am telling you is, the first row of the stripe invoice is exclusively for the flat fee on your Price dimension.
If you want to have the energy price, you can change the code to put it in the first line

Do you happen to know where should I change it? :(

Did you figured it out, or are you confronting the same issue?

Did you figured it out, or are you confronting the same issue?

Hello @Zakichanu , thanks for getting back to this thread.
I read and followed a lot of code to found out that the unitPrice doesnt get with the other values in one of the functions!
Instead I ended up getting that value from the Transactions class.
In StripeBillingIntegration.ts, in this function buildLineItemDescription4PricedDimension()
there is also this const unitPrice = Utils.createDecimal(pricedData.unitPrice).toNumber().toLocaleString(userLocale); which returns 0!
So I had to make it like this const unitPrice = transaction.pricingModel.pricingDefinitions[0].dimensions.energy.pricedData.unitPrice; to get something like what you can see in the screenshot.
If you know a better way please let me know.

Hi @UBT-FJ,
That's a great way to modify this in my opinion. I never use this part in my case so I don't know if there is a better way for this.
I think we can close this issue then


Update v1.5 files

Update user and dev guides.
Update tests.
Fix bug in deletetag feature.

Coverage increased (+0.2%) to 86.018% when pulling da96c3ec165341972708e2dfb781c23cfab9c5f9 on lancehaoh:master into 6ce68c203d9216d4d5510f6232b24e9ee743fa38 on CS2103AUG2017-W11-B1:master.


Boolean widget small fixes

[ ] Boolean values should not show a dropdown, only a "dot" widget.
[ ] Boolean widget should insert "True" and "False", not "Boolean.True"

Refinement notes:

Let's make exception for drop-down matching: if the boolean would match it, the frop down marks itself as "Mismatch". The more general way wil be implemented when more similar cases arise.


NaN receieved for Hue and Saturation Characteristics

Since upgrading to Homebridge v1.3.x my Homebridge logs are being flooded with the following warnings every few seconds:
[23/02/2021, 13:05:54] [homebridge-wiz-lan] This plugin generated a warning from the characteristic 'Saturation': characteristic was expected valid number and received NaN. See https://git.io/JtMGR for more info.
[23/02/2021, 13:05:55] [homebridge-wiz-lan] This plugin generated a warning from the characteristic 'Hue': characteristic was expected valid number and received NaN. See https://git.io/JtMGR for more info.

I have the filament (non-rgb) bulbs and this plug-in was designed for rgb bulbs; so I imagine this is part of the issue.

i have the filament bulbs, too. hope, someone can add plugin support for these soon!

Should be fixed in https://github.com/kpsuperplane/homebridge-wiz-lan/pull/32 :)


[BugFix] improve lake primary table compaction strategy

Do some changes to lake primary table compaction policy:

Consider rowset's compaction score when picking rowsets.
When calc compaction score of tablet, only the picked rowsets will be involved.

What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

@Mergifyio backport branch-3.1


"window.reopenFolders": "all" should work also when launching on a specific folder

VSCode Version: 1.7.2 , portable zip
OS Version: Windows 10

Steps to Reproduce:

Open some workspace folders
Close Code
Open folder from command prompt by typing code .
Last open folders and sessions are lost!

Atom has exactly the same issue :)

Try with "window.reopenFolders": "all"

Did that already.. first thing when I got started with it.

@rajnisheu so you say it does not work with that setting?

Yes @bpasero

@rajnisheu I see what is going on. When you instruct Code to explicitly open on a resource (file or folder), we do not restore the windows. So this setting only has an impact when you just launch Code without providing a path.

I am not sure I can make sense of that @bpasero. To me its not at all intuitive to loose my working session.
Its not unusual to right click and use "open file with" command. If Code wasn't open at that time, all working folders and open files are lost.
This is offered by several tools, including likes of Notepad++ which remember sessions.
I would not call it a feature request. Its fundamental functionality. If it is, its probably unusable by me till we can have that in. Its no fun loosing working folders and files.
Thanks for looking into it.

@rajnisheu what do we do about people that expect "code ." to open exactly one folder which is the folder the "." is pointing to? A change like this always means to potentially break expected behaviour for some users. Since the current behaviour is intended, I set this to be a feature request because this is not something that happens by accident.

@bpasero I am not able to comprehend why would someone expect "code ." to forget their session where an explicit setting for "window.reopenFolders": "all" has been set. Is that not what the setting "all", "one" and "none" are about?
For lack of a better example, lets take the case of a browser. If its been set to reopen tabs from last session aka remember last session, and after close, if an html file, say from the desktop, is opened, should the browser loose all tabs?
That would be a disaster for a user.

@rajnisheu how about you double click on a file in the windows explorer to do some quick edits, would you expect all windows to reopen in that case from your previous session? to take it one step further, what about using VS Code as external editor, e.g. to quickly edit a git commit message, would you still expect all windows to open?

You do make a point @bpasero.
But that's not how I see developers working with editors. Editors are open most times. Its those occasional moments when, for example, Windows comes of a reboot (which it does nearly every week ;) ), and you unwittingly double click a file before making sure that Code is open, that loosing session is disastrous.
If its a quick edit of a Git message, it would most likely be for a project. Editing a message.. and loosing the session! I can tell you working with a reasonable size team, single message edits are always in Git tool directly or even command line.
I can't imagine working with a modern tool where I am likely to loose my project setups, tasks and several open (and sometimes unsaved) files, even accidentally. In the end, if I have set session to be remembered, that's what I would expect. Extra seconds spent for loading is any day far more acceptable than loosing work!
Thanks for the clarification though, you can close this thread if you wish.

@rajnisheu I took extreme examples, but that is the reason why "code ." behaves like it does today. You are basically instructing VS Code to open the current working directory as folder (because you add the "." to it) in a new window. We distinguish such a way of opening VS Code from just typing "code" where we assume you want to restore your previous session.
Now, wether this behaviour is good or bad is up for discussion and that is why I will leave this issue open and flag it as feature request. I am not saying that our behaviour is good or bad, just saying that it is a result of us interpreting "code ." not as an instruction to restore the full previous session but rather to only open the current folder.

@bpasero its the same behaviour with Code installed and doing a right click "open with" instead of using "code .". Doesn't matter if its right click to open folder or file.
Previous session is lost.
Is that really the expected behaviour?

Yes, as long as Code is opened on a specific path (either file or folder), we use that as the session over any previous session. At least that is a consistent behavior I would say.

I agree with rajnisheu. Anytime I reopen Code it should automatically reopen all the files I had open previously. If I double click or use the context menu to open a file, it should also show all the previously opened files in their respective tabs. The editor doesn't have to actually load those other files until the user clicks the appropriate tab.
Personally, I never have files open from just a single folder. Multiple files are open from multiple folders across multiple drives.
Notepad++ does it right. I can even use a tab in Notepad++ as a temporary copy/paste buffer. I never have to save the file.
At the VERY least you should make it a setting so those who want Code to work the way Notepad++ does, they have that option.
Great editor. Love the plugins, Love the themes. It won't replace my current editor if it doesn't automatically open all of my last file. This is especially true since Windows 10 WILL reboot after an update if even you have the settings otherwise. That's a different issue altogether.

Thanks @37Stars, several users I know and I abandoned Code and decided to stick to Notepad++ / other IDEs. The other extremely helpful feature in Notepad++ is the ability to save sessions. This means if I have two (or even more) multi tab instances of NP++ open, I can save these and come back to exactly what I was doing including unsaved tabs after the notorious WIN10 update. NP++ does get it right!

What you want is https://github.com/Microsoft/vscode/issues/207 and not this issue.

As far as I can see "window.reopenFolders": "all" under Linux just doesn't work.
It will reopen one folder but never two.

Thought this was a bug for the longest time. Never understood what the issue was until I accidentally reproduced it yesterday twice in a row, thus the bug report (#50846). Reading through this issue thread, I respectfully disagree with the VS Code team's interpretation. I don't understand what benefit there is in not loading the previous working state regardless?
Can you explain what the benefit is in not loading the previous state, and what lead you to this interpretation of why users would want VS Code to behave this way? It feels very counter-intuitive -- its not what I've come to expect after having used other IDE's -- or really from the Windows environment itself -- it just doesn't feel right.
Why should I need to launch VS Code, to then be able to right-click to open a file in VS Code? THe worst part, is that its left in this "fresh" state -- I find myself having to reload my workspace, over and over again. In such an event, I question the point of the right-click context menu at all. It just seems to me like you're targeting two very different types of users -- there should at the least, be a user-defined setting to control this behavior.
If your goal is to have code window launched via a CLI open in a "fresh" state, then why force that behavior on the right-click context behavior within Windows? Again, it just seems like there would be very distinct use-cases for opening files in both manners (via CLI and via right-click context menu).
At least now I know what causes this bug. It's still frustrating as all heck as it goes entirely against my workflow, but now that I know how to avoid it, hopefully I can curse the code gods less frequently :)

I also disagree with the VS Code team's interpretation. If I set VSCode to open all files again at startup (reopenFolders:all) I also want VSCode to keep them open if a single file is opened.
It should not matter at all if VS Code is started without arguments (e.g. taskbar link) or started with argument (explorer double click on file). And it should not matter if VS Code is already open or still closed when I double click on a file in explorer.
I just try to switch from notepad++ to VS Code and love it so far, love the plugins, the ui and everything, except two issues: startup performance and this bug of loosing the open files! The files are open for a reason and I want to continue work on them. I never open VS Code with a folder, just as a file editor, and I want VS Code to keep that open.
If it is really necessary to keep that behavior, why not add a setting for that? Or solve that problem (e.g. open as git editor) with a commandline switch like notepad++ does to open a single independend instance?

Extreme disagreement from here too. I've lost unsaved work and sessions thrice within 2 weeks. By sessions I mean opened files and folders. Yes, I can always reopen them, but the tabs represent my last 1-4 weeks of mental context. All of a sudden its all gone! Also I thought this was a bug in VSCode, but it seems, based on @bpasero, that this is a designed feature of some kind.
Steps to repro:

Open files in tabs, and assume they will be coming back
Close VSCode representing Windows update or any other reason to turn off the computer
Open Explorer, navigate to a file associated with VSCode and double click it
Feel lost and confused looking at the contents of the opened file. It just caused you to loose all work and context. Also all Unsaved files are lost, if you didn't have the foresight to set a custom setting.

Mitigations:

Found the secret (to me) setting that at least seems to not destroy my "Unsaved" tabs: "files.hotExit": "onExitAndWindowClose"

I expected the setting "window.restoreWindows": "all" to fix the situation, but it does not - just like bpasero explained above. It seems that the only reason for this horror is to support code . opening a folder? And perhaps for using VSCode as a diffing tool?
Would it not suffice that code-dot opens a new window, AND all of the old stuff? Same with diffing, or maybe use another program for diffs? Because if workflow for diffs is the reason to throw away all users opened tabs, ... then I'm speechless.
You see this situation is really awful. Any time I have my work context "saved" in VSCode tabs and VSCode is not currently running, clicking on files in Explorer turns into a mine field. If I accidentally missclick or forget this VSCode special horror, and hit an associated file -> BOOM! Everything is gone. VSCode is untrustworthy in this respect - as we have learnt to trust Sublime Text, Notepad++, and others.

Testing around I realized why I was so surprised by this behavior. It's the UX flow.
For weeks I've kept VSCode open, dodging windows restarts, on few different machines. During that time VSCode has taught me:

when VSCode is running
double click an associated file
it opens as a new tab nicely next to my other open work in VSCode

After closing VSCode for any reason, the behavior is very different:

when VSCode is not running
double click an associated file
it closes ALL other open tabs (and Unsaved buffers, lest user had set a setting), only that single file is open

Hopefully we could get a setting for "never close user's files" (perhaps should be the default, as surprise closing is disrespectful).
If one would like to hack around this, PR in mind, where should one start looking?

Came here to complain again.
(Though let it be noted that due to this issue described in this Issue, I've tried to switch to few other editors. Turns out I couldn't let go of VSCode because it is just too good in so many other aspects. Props to you who work on this!)
Issue:
I've been trying to be extra careful to always have VSCode open, so that if I accidentally double click an associated file in Explorer I don't loose all my work context = open tabs. Today I was trying to run a python script, but accidentally forgot to write python in the command which opens the file in an associated editor:
pipenv run src/msgpack_test.py    (it should have been pipenv run python src/msgpack_test.py)
I observed two different behaviors:

if VSCode is open, file opens in a new tab next to all my open work (Good)
if VSCode is closed, it closes all open tabs and opens just msgpack_test.py (Bad, aka unexpected)

It seems xtronoid complained about this, or something very related, in above issue.
From my POV a setting that says "always open files as tabs in current vscode workspace" would fix everything. I'm aware that situation requires more design, as there are workflows that VSCode supports that are unfamiliar to me.
Based on above explanations by @bpasero, VSCode is now geared to support this workflow:
"user wants to open all files in one directory, and close all tabs in current workspace".
and perhaps also "using VSCode as difftool to open file comparison".
I do agree that difftool started by Git for example should probably open a new window, and not a new tab in current workspace.
So is it possible to enumerate the features & workflows, and design the system to never disappear user's workspace?
It's just quite annoying to keep loosing all my work context - which never happened to me when using Sublime Text.

Found this after trying to add a similar issue. It also seems completely unintuitive to me that when opening code from with a file or folder as an argument the previous session is not restored. If I were to click a new web link and Chrome happened not to be open, I wouldn't expect it to not restore my tabs, and only restore them if I opened it manually first and then clicked a link.
I understand that the Code team may desire to maintain the existing behaviour by default, but would it be so hard to add an option to always restore previous sessions when opening a new file for those of us that do want that behaviour. That's how I've been using TextWrangler for years until I went in search of a new editor with code completion. Code seems to have the best I've tried, but I'd love to see it restore my previous session even when opening a new file or folder as an argument.

I have to agree with Rajnisheu as well. Especially now my Mac crashes every day (new Mojave OS sux) and VC is the ONLY app that refuses to restore my session, it's pretty tedious. And "yes", when I open VC to start from a correct close down, I would still not mind it restores the previous session. If I really want to start fresh I tend to open a "new window" instead which then indeed opens a fresh clean slate.
Signed:

UX Architect -

Please can this issue be reopened? Even if it's decided that this should not be the default behaviour, it would be great to have an option that let's us override it.

Hi @edmorley looks like this is now happening, for me it is restoring previous folders/files now.

Problem still exists for me, v 1.31.1 on Win10 and CentOS 7.6, steps to Reproduce:

Open some files in Code
Close Code
Double click on a file from Explorer to open it in Code
Last open folders and sessions are lost

They are not lost. But when you close your window and then ask VC to open a specific (other) file from Explorer or Finder, it is going to do what you ask of it: open that file and that file alone. This is expected behavior of any software. However if you want to go back to where you were before you can go to "open recent".
This particular thread is about restoring the same files (that were open when you close the app/ window) when opening the same folder/ workspace; and it is doing that now. It is even restoring everything after you closed the computer down improperly (or after a crash). That is why this particular thread is close/ resolved.

The issue here, is that workspaces are not remembered. I think a few folks here have misspoke and thereby shifted the conversation off topic slighty.

Well, again: it is working properly for me. It is remembering my workspace(s) now. But not when I open one specific file like jimjoh describes (which I don't think it should as you ask it to open that specific file)
I'm on Mac though...

I appreciate your opinion, but I think it's clear there are a lot of folks who don't hold your same viewpoint. Personally, I can't logically understand why a workspace should be forgotten because I choose to open a new file without first having VS Code running. However, if VS Code is already running, and I open a new file, my workspace isn't lost. It doesn't make much sense and is simply not consistent, especially within the Windows environment itself --- it's just not expected behaviour. The Microsoft team which maintains this program, has explained that they are aware this happens, and does is intentionally as it is more favourable when using VS Code from a command line. Which is understandable, but I feel that there are more users using VS Code in a desktop environment, than via a CLI. Therefore, I think a reasonable compromise would be to implement such functionality through a user defined option, rather than leaving desktop environment users high and dry.

There definitely seems to be enough support on this thread alone to warrant an option for those of use that would like that behavior. I ended up always running VS Code on startup to make sure I never clear my previous workspace when opening files.

 This thread was started in 2016, and 2019 still no sign of solving the issue.
It looks the product core is incapable of doing this. Would be helpful if someone could close the thread.
Three cheers to well thought, friendly tools like Notepad++

Please, please, please... It's driving me crazy.
I try to open VS Code as soon as my computer starts to avoid losing my previous VS Code 'session'... but, yeah, sometimes I forget. And it is so frustrating when it happens. Each time such a waste of time.
As mentioned before by many others, I find it utterly counter intuitive to lose all my open tabs (files) when I open this - otherwise near perfect - editor by double clicking on a file. Other text/code editors do not do that, browsers do not do that when clicking on a link or double clicking a .url file, and many other programs mimic that behavior so why can't we expect VS Code to act the same way ? At least when "window.restoreWindows": "all" is selected (or another option if it makes more sense to you).
We are not asking to change the way it works by default, but to give us the ability to always (!) restore the previous 'session' when opening a file or folder while VS Code is not started yet. In that configuration, if anyone wants to open a clean new VS Code instance/window with no open files, it is pretty easy to do so.
I thought I had to finally add my voice after coming back so many times to this feature request.

I could not figure out why VSCode suddenly started losing my workspaces, until I discovered this issue... crazy oversight / bent logic from devs' side. Now I can only try to begin to attempt to remember how many UNSAVED files there were in my now prematurely closed workspaces, and trying to recover them by hand. Crazy monkey wrench in the middle of a sprint.

It's strange to see this annoying issue still not being seen as an 'issue' by devs smh

At least once every week I lose my entire work context and have to find and open everything again only because I've committed a cardinal sin of forgetting to manually open VSC before double-clicking a file.
While there's no actual work being lost, so this issue is not really critical, it is still as close to being critical as it gets.
I cannot for the life of me understand how is this still not addressed after 3 years, and why do we not even have a "restore previous hot-exit session" button for cases like that. @bpasero

I built something for atom to be able to restore workspace because I was sick of losing all my tabs, I made this associate the state (files, tabs, arrangement etc) to the local commit, so if users moved between commits it would be able to restore their last known workspace state  for that hash (even if the hash was amended multiple times, it would be able to track the changes based on mercurial). I'm looking at possibility of doing something similar on VSCode but couldn't find an official API that does a "...deserializeWorkspace(someObject)" like what atom had. Even if VSCode doesn't consider this an issue it would be helpful to know if this functionality exists.

@aadisriram sounds interesting but I'm interested in better understanding what you mean by basing the saved state on 'the local commit'? Would I be correct in assuming that you are assuming that a user associates an single instance of VS Code to a single project? If this is true, I'm not sure I understand how this relates to workspaces in VS Code which can have many projects/repositories in that single workspace. Can you please elaborate?

.. For what my comments are worth, I've seem to have changed my working habits to somehow match VSCode UX. I now try to open one VSCode instance per code repository. VSCode keeps the state in that folder/repository, and always opens the tabs what I previously had open.
This means I've created one "project" / "context" (just a folder) for main information collecting, main todo lists, random temp scrathcpad stuff, etc. So if I have some thoughts or overall planning, I open that "context" in a separate VSCode instance. Using i3 window manager on Linux helps keeping the instances in a sensible order. On Windows (my previous OS or choice) it would be slightly harder to keep track of which "project" I'm in at what point.
This tends to become a hassle if I need to work over more than 4 contexts (projects), as switching between VSCode instances messes up my focus. Hmm.. maybe color coding the instances would help.
My previous complaints in this thread (similar to what the latest comments here reflect) were due to tyring to use one VSCode instance as the "main" thing. Always trying to open only one VSCode window ever.
I don't know if the UX philosophy of VSCode is clearly stated somewhere - aka what is the right/best/intended way to use VSCode. That might be helpful.

@lautjy Your post convinced me to try this method of working. I have to admit, I do like the idea of having these individual saved states that are restored when opening a project folder. It also inherently resolves something I personally struggle with when using large workspaces, and that's managing the structure tree -- it can get annoying when trying to jump between different projects; i find its much easier to manage when each project is in its own VS Code instance (window).
I'll add that it actually feels like this method of working is how VS Code was intended to be used. By comparison, workspaces (which I'll note is immediately how I started using VS Code), does not feel intuitive (in regards to this issue thread) inside the Windows desktop environment. Which really makes me wonder exactly what Microsoft was trying to achieve with workspaces in the first place? Regardless of Microsoft's opinion that they function as intended, workspaces feel broken and I've decided to abandon that concept of working.
I'll note one important thing for anyone else considering this style of working -- within the Windows environment, I feel that its critical you install VS Code with both options: opening folders and opening files with the "Open with Code" context option. Initially when I installed VS Code, I had only select the context menu option for files. Without the folder option in particular, you'd otherwise have to use the File > Open Folder menu controls every time, which can be annoying.

Lastly, after having tried this method of working, I can confirm that everything @aadisriram noted in his post, already happens in VS Code.

@purplekrayons ah sorry din't mean to confuse, in the world I come from we do stacked commits and often the files I touch in commit 1 are different or a sub/superset of the next commit on the stack. So I had built something into atom that would automatically open up the window state as it was the last time I was on that commit.
Ex: on commit 1 I have files A, B, C open with a 3 pane setup with the file tree open
on commit 2 I have filed C, D open in 1 pane setup with a debugger pane to the right and no file tree
This was useful especially when working with multiple devservers, I was able to checkout a commit on a new devserver and get back my old state that I had last left it on a different machine. I understand this is a very unique usecase but atom let me build this (in a very hacky way I must say) but if vscode had a way to get a saved workspace state that can be restored on demand that might be useful for folks like me, maybe more?

@aadisriram Thanks for the clarification. What your describing is actually something I would also find very useful, at least in the sense that it would allow for saved states across multiple machines, which is something I juggle on a daily basis (home and office desktops and laptops).

My problem was that I somehow deleted my projects.json file in my application support>code>user folder.
I've tried the usual stuff to fix it:
"window.restoreWindows": "all",
"files.hotExit":"onExitAndWindowClose",
When I put that file back, everything worked as expected.

up

I have just encountered this data loss bug and am rather upset to see that this has been known for four years and not resolved. I rely on my editor being able to recover workspace arrangement and unsaved files/buffers after a crash, power loss, etc. For vscode to intentionally abandon this behavior based on which way it is opened is unfathomable to me. I spent days trying to figure out how I lost some data, then inquiring in support chat rooms about this behavior I "discovered", just to find this issue where I see that this is expected behavior.

Lest Microsoft close this ticket for lack of recent activity (which I've noticed is happening increasingly often across a wide array of bug reports), I'd like to add my voice to the crowd of disaffected developers. I had no idea this issue had been identified 4 years ago, and then IGNORED FOR 4 WHOLE YEARS!
It's always been an annoyance with using Code, and I can't count the times I've lost a complicated "workspace" simply because I forgot to open Code on its own before using the "Open with Code" context-menu item in Windows Explorer, or called it up from a command line.
The current behaviour is a massive disruption to workflow, and completely un-intuitive. Whatever happened to the Principle Of Least Surprise?!
So c'mon Microsoft: Admit you got it wrong. Just give us a setting which always restores the previous workspace regardless of opening method. And if you can't do that, a "Restore Previous Workspace" menu item might suffice.

The problem is worse for mac so I'm now used to closing everything with command+q thanks to vs code. Guess that's what "learning a software" means nowadays...
Also, people might be interested in "Project Dashboard" extension if you have many workspaces to switch between.

I'll repeat what I wrote few comments above (1 year ago):
Code works well when you always have your workspace in a folder.
So with Code you should have every "context" saved as a folder on your harddisk:

Programming that new Pytorch model: dev/new_model/
Keeping notes of things you study: dev/notes/study/
etc. for every "context" you have.

Then you just CTRL+k o to open a folder, and you select the folder that matches the "context" you need to work on.
You then need to open a window of Code for every context.
The actual state of a "context" (aka folder) is stored in Code/User/workspaceStorage/ (I guess). Hence all your tabs and unsaved data is stored - but it is tied to a folder on the filesystem!
The workflow you (and I previously) are complaining about is how Sublime Text works.
There you have kind of like 1 global context, where all your files, tabs, etc., saved or not, are stored.
Then you just open Sublime and continue work.
With Code you need to open Code, CTRL+k o, select folder, and continue work.

This is completely ridiculous. I'm using Code on Windows AND on macOS.
On Windows, the session is ALWAYS lost, when calling Code externally (by opening file via explorer).
On macOS the session opens perfectly fine, when opening a file, while Code is closed.
So this is clearly a bug and needs attention.

This is completely ridiculous...On Windows, the session is ALWAYS lost, when calling Code externally (by opening file via explorer).

I won't argue with that.  I agree that if you don't have a folder open VSC should always remember your open files in a default workspace.  However, @lautjy's reply is a good (non-obvious) workaround.  When he first posted his solution a year ago I ignored it because I didn't think it would work for me since the text files I edit are scattered around my hard drive (not under a single folder).  However it does work for my workflow.  I created a folder (named WS) that is empty that I just use for my VSC workspace.  The folder is empty, it holds no files or folders, but it still allows VSC to magically remember all of my open files.
Now when I open VSC from its shortcut it by default restores my "WS" folder (workspace) files.  I.e. it restores all the files I had open last time.  If I open VSC by double clicking on a text file all of my open files are lost (i.e. my workspace is lost), but I can easily get them back by going to "File->Open Folder" (CTRL+K CTRL+O) and opening my "WS" folder.
To make it even easier to open my WS folder I use the Favorites Manager extension and have my WS folder saved as a favorite.

I will check that out, thanks for the heads up. Much appreciated.
Still, the fact that we have to argue about the behavior with the devs is totally ridiculous.
Imagine you would open a link from your email program and the browser would just empty your complete session with all tabs and only load the clicked link. This is totally counter productive.
In the end, such frustrating behaviors will just lead to going back to other applications. Even more if the devs play stubborn. And once again: it IS working on macOS.

And once again: it IS working on macOS.

That surprises me since I have the same problem on Windows and Linux.  One of these years I'll have to try a Mac.  :)

I double checked, it definitely worked that. Now that I removed the workspace from Code, it doesn't work anymore sigh.
This really drives me crazy...

As part of our issue grooming effort this month I am thinking of looking into this. A related issue is https://github.com/microsoft/vscode/issues/14675 which is more specifically around restoring opened editors, but I think a solution should ideally cover both.
Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

default: behaviour as today, selecting a file or folder to open when VSCode is not running will only open that
restore: depending on the window.restoreWindows setting, all windows from the previous session will restore first and then the file or folder will be opened. if a file is selected, it will open in the same way as if you had VSCode already running and open it then (i.e. in the last active window or the one that has the folder opened the file is in) and if you pick a folder, it will open a new window or reuse the last active one depending on other settings

To give examples how this would behave:

double click file to open -> opens in last active window or matching window that has parent folder opened as a new tab alongside all other opened editors
open folder -> opens a new window for that folder and all the other windows that were open
git config from a command line (provided that VSCode is configured as git editor) will first restore all your windows and then open the git editor in the last active one (not a separate window)

Thoughts?

Alternate solution proposal: When opening a specific file/folder/workspace, don't discard the previously saved session, just keep it saved and do nothing with it. When closing VSCode and it's time to save the current session for [possible] reopening next time, append them to that saved session. Best of both worlds?
(Yes, I know there's a tricky bit here related to figuring out which part of the session to overwrite when doing automatic saves for crash recovery. I have some ideas for that, but it seems like an implementation detail rather than something worth discussing as target behavior.)

@bpasero I think your proposal sounds solid. It is purely additive and optional and won't make things worse for anyone using the current default behavior. A few questions:

Would using vscode on the command line with this setting enabled also reopen the previous session? (I think it should)
Do you see any scenarios where, with this option enabled, an unsaved buffer would be lost by restarting my machine or restarting vscode?

@sparr

Alternate solution proposal: When opening a specific file/folder/workspace, don't discard the previously saved session, just keep it saved and do nothing with it. When closing VSCode and it's time to save the current session for [possible] reopening next time, append them to that saved session. Best of both worlds?

Not sure, I find this a bit hard to understand for the user what happens. I feel my proposal comes close to what browsers support via settings where you can chose to always restore all your previous tabs and windows or not when opening a single link. I feel that users would feel more comfortable with a setting that behaves like I described given this matches what browsers do.
@joshrivers

Would using vscode on the command line with this setting enabled also reopen the previous session

It would actually always restore in any case, not just double click on files or command line, even interactions where a protocol handler is involved (e.g. a link in a browser uses the vscode protocol and triggers to open something inside VSCode. Basically in any case where VSCode is started no matter how, all your previous windows would restore.

Do you see any scenarios where, with this option enabled, an unsaved buffer would be lost by restarting my machine or restarting vscode?

No never. Restoring of unsaved editors is always explicitly handled. Even today already, we forcefully restore all windows and editors that are dirty even when you ask VSCode to just open a single file.

2 cents:
Sounds like your proposal will solve the gripes we've had in this thread.
Though a new user would first have to hit this behavior, realize what happens (took me a while back then, thought vscode was crashing or something), then look for a solution.
Any ideas about how to make this information easy to find for users?
Maybe one of those small popups that advertise extensions; could advertise this optional setting when user 1st time opens a single file?

@bpasero

Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

I think your ideas sound good, but I agree with @lautjy that users will continue to be confused by the existing behavior which I consider broken.   What can't you "break existing behaviour"?  Defaults can be changed to be better.

@jimjoh I think it can cause frustration too if this was the default. For example, you may decide to use VSCode as editor for git commit messages and anytime VSCode opens to show the git editor, suddenly all other windows and editors would restore if it was not running before.
I agree that a nice feature would be to be able to restore windows + editors from previous sessions as a way to get back to the last state even when meanwhile a single editor was opened.
Btw I just checked how browsers do it, and Chrome for example does not seem to put "Continue where you left off" as a default:

Your analogy to browsers is not entirely appropriate. Unless you use extensions to do so, browsers don't save user-entered information when they are shut down (like form fields), so less total and less important information can be lost if a session is lost. Further and far more importantly, browsers have different behavior when they crash, and I think it's getting lost a bit in this conversation that part of this bug is the loss of unsaved data when vscode crashes. If you want to analogize to browsers, you need to provide a different workflow with a prompt to the user to restore their session if the program closed unexpectedly.
I still can't believe we need to argue this. Literally every program/platform/app that I use to enter text can restore my "unsaved" data after the program crashes. Sublime, Atom, VSCode, MS Office, Libreoffice, Google Docs, Evernote... This is a standard feature in even remotely capable text editors for the last ten years. VSCode is the only one that throws this feature away because the user happens to relaunch the program in a specific entirely usual way.

@sparr I cannot follow your argument. Are you implying that VSCode is loosing unsaved data in any way?

Yes. When VSCode throws away the saved session because you opened a specific target file or folder, that session can include unsaved files/buffers.
Search up-thread for "unsaved" or "buffer" for other people pointing out this failure mode.
Reproduction steps:

code
File > New
type foo into the new file
killall electron (obviously do something safer and more specific if you use other electron apps)
code /

At this point your "foo" seems to be irretrievably lost. If your #1 had targeted a specific directory like code /usr/src then you could recover the lost file by doing code /usr/src again, but only if you remember that that's the directory you used to open the instance of code where the lost file was.

@sparr understood, I forgot about a change we did in March: https://github.com/microsoft/vscode/issues/92467 (cc @aeschli) where we no longer open folders/workspaces that contain dirty files. Fact is, we lost this behaviour for a couple of months and then decided to not bring it back because it resulted in a sudden spawn of tons of windows for users that accumulated dirty files in various folders and workspaces. Our UI solution was then to indicate workspaces with dirty files in the picker with a black dot:

Still, this is NOT data loss.
To summarise:

we used to restore every folder, workspace, empty window that contained dirty files until 1.32 where we lost support for this for folders and workspaces
in 1.43 we decided to keep this behaviour (empty windows with dirty files still restore because there is no other way of getting your data back)
we never supported to restore folders, workspaces, empty windows when you ask VSCode to open a specific file or folder

I feel the original intent of this issue was to restore the windows and editors independent from having files dirty or not. Arguably we could introduce a setting that would only restore those windows with dirty files, but I feel that is not really what people asked for here.
Does that make sense?

@bpasero I am the original poster of the issue, and am glad this is being visited four years on! Better late than.. :)
What you say in https://github.com/microsoft/vscode/issues/15949#issuecomment-724714778 is exactly what I think the behaviour should be.
Most people understand the implication of opting for "Continue where you left off". And that is what VSCode should do. As with the browser, or infact similar tools, if there were 15 windows open, all should restore. If VSCode can handle opening an isolated instance for git diff or git commit, good. But not at the cost of loosing work. In any case there are other possibilities to handle diff or commit as well.
With this feature, and multiline tabs, VSCode will achieve awesome 🥇  and can become a truly mainstream IDE 👍

@bpasero I do not understand how to apply your description to the reproduction steps I provided above. How can I recover my unsaved "foo" file?

@sparr that depends wether the untitled file is part of a folder/workspace context or an empty window:

empty window: we always restore that window and file
folder/workspace: you get the dirty file back once you opened that same folder or workspace (you can use File > Open Recent > More... picker to see all folders/workspaces that have dirty files)

That's amazingly useful and not at all intuitive. Thanks to this advice I've been able to recover three dirty workspaces with unsaved files that I thought were lost.
Sadly the one I most regret losing, the one that brought this bug to my attention, is not represented in that picker. I only wish I'd known to check there when it happened.

As part of our issue grooming effort this month I am thinking of looking into this. A related issue is #14675 which is more specifically around restoring opened editors, but I think a solution should ideally cover both.
Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

default: behaviour as today, selecting a file or folder to open when VSCode is not running will only open that
restore: depending on the window.restoreWindows setting, all windows from the previous session will restore first and then the file or folder will be opened. if a file is selected, it will open in the same way as if you had VSCode already running and open it then (i.e. in the last active window or the one that has the folder opened the file is in) and if you pick a folder, it will open a new window or reuse the last active one depending on other settings

To give examples how this would behave:

double click file to open -> opens in last active window or matching window that has parent folder opened as a new tab alongside all other opened editors
open folder -> opens a new window for that folder and all the other windows that were open
git config from a command line (provided that VSCode is configured as git editor) will first restore all your windows and then open the git editor in the last active one (not a separate window)

Thoughts?

This is totally how I would expect it to work, huge 👍 !

I presented this in our UX meeting and think we can push this to insiders for feedback. One discussion was around the name of the setting. Current proposal is still to have a new setting that controls this behaviour, however it might be very confusing given we have window.restoreWindows already.
How would people feel if we added another option to window.restoreWindows to control this? This would mean, you could not chose anything but to restore all windows, but I feel that is the gist of this issue anyway. The sum of options in window.restoreWindows would then be:

preserve (new): all windows are restored, independent of how VSCode was started
all: all windows are restored, but not when you start VSCode on a file or folder
folders: only folders are restored, but not when you start VSCode on a file or folder
one: only a single window is restored, but not when you start VSCode on a file or folder
none: no window is ever restored

Thoughts?

Sounds good to me!

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.
One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

Ah, --new-window would definitely be helpful :+1:
Hard to find which window has opened a file I clicked (hence I use other editors for single files these days).

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.
One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

@bpasero what determines what window the file opens in?

In a perfect world, it would open in the same place that it would have opened if you'd already had vscode running and opened the file from outside the program, which I think depends on whether or not the file is within any existing open workspace.

@Jonatino yes I think @sparr described it well. The experience of opening a file will be the same independent wether VSCode is running or not. We have some logic that tries to find the best window when opening a file. E.g. ensuring that a file opens in the window where the parent folder is opened in.

This can now be tested from our insiders release channel: https://code.visualstudio.com/insiders/


fix display issue on snippet edit view

Fixes: #5852

Thanks @Quadric! Merged in 06fbde14b3b5f9ba2f39e7786858ba25bc32b7e7.


How to add bots dynamically from list in database?

Hi, im trying to add telegram bots after the startup class has been loaded. Any examples of that?
Thanks for a great library.

Nevermind, have used the Core project instead. Thanks.


Extensions cannot be installed on Dbeaver in archive format

System information:

Operating system (distribution) and version
DBeaver version 7.2.4 zip or tar.gz

Steps to reproduce, if exist:

Download, unzip and run DBeaver
Go to Install new software and enter any of DBeaver extensions in work with field (e.g. DBeaver Office integration - https://dbeaver.io/update/office/latest/)
Go through the wizard and press Restart at the end

Expected: Dbeaver opened again with the installed extension
Actual result: DBeaver tries to start but fails  (the application label just jumps at the bottom toolbar)
Note: if you cancel the restart, the extension will not be installed, even if you restart Dbeaver manually later

Can't reproduce.
However it is a known issue when DBeaver splash starts to blink after extension install + restart.
We need more precise steps to reproduce.

Can be reproduced in 7.30 release Mac version (https://dbeaver.io/download/ Will try Windows later too) using steps above

Floating bug. We need more precise steps to reproduce.

Floating bug. We need more precise steps to reproduce.

#10852

closed as a duplicate of #10852


fix(explore): timepicker show human readable string in pill

SUMMARY
fix #12285
Backward compatible. the timepicker pill should show human-readable text.

show human-readable text in common / previous calendar frame.
move frontend datetime expression to backend

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before

After

common frame

previous frame

TEST PLAN
Added UT
ADDITIONAL INFORMATION

[ ] Has associated issue:
[x] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #12300 (d84641a) into master (6b2b208) will increase coverage by 0.53%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #12300      +/-   ##
==========================================
+ Coverage   63.01%   63.54%   +0.53%
==========================================
  Files        1002      485     -517
  Lines       49250    29843   -19407
  Branches     5003        0    -5003
==========================================
- Hits        31035    18965   -12070
+ Misses      18015    10878    -7137
+ Partials      200        0     -200

Flag
Coverage Δ

javascript
?

python
63.54% <100.00%> (-0.64%)
:arrow_down:

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

Impacted Files
Coverage Δ

superset/utils/core.py
90.22% <100.00%> (+0.42%)
:arrow_up:

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.62%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-12.78%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/utils/celery.py
96.42% <0.00%> (-3.58%)
:arrow_down:

superset/examples/world_bank.py
97.10% <0.00%> (-2.90%)
:arrow_down:

superset/examples/birth_names.py
96.51% <0.00%> (-2.33%)
:arrow_down:

superset/views/database/mixins.py
80.70% <0.00%> (-1.76%)
:arrow_down:

... and 528 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 6b2b208...d84641a. Read the comment docs.

Codecov Report

Merging #12300 (d84641a) into master (6b2b208) will increase coverage by 0.53%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #12300      +/-   ##
==========================================
+ Coverage   63.01%   63.54%   +0.53%
==========================================
  Files        1002      485     -517
  Lines       49250    29843   -19407
  Branches     5003        0    -5003
==========================================
- Hits        31035    18965   -12070
+ Misses      18015    10878    -7137
+ Partials      200        0     -200

Flag
Coverage Δ

javascript
?

python
63.54% <100.00%> (-0.64%)
:arrow_down:

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

Impacted Files
Coverage Δ

superset/utils/core.py
90.22% <100.00%> (+0.42%)
:arrow_up:

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/db_engine_specs/hive.py
54.61% <0.00%> (-29.62%)
:arrow_down:

superset/db_engine_specs/presto.py
70.56% <0.00%> (-12.78%)
:arrow_down:

superset/db_engine_specs/mysql.py
79.59% <0.00%> (-12.25%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/utils/celery.py
96.42% <0.00%> (-3.58%)
:arrow_down:

superset/examples/world_bank.py
97.10% <0.00%> (-2.90%)
:arrow_down:

superset/examples/birth_names.py
96.51% <0.00%> (-2.33%)
:arrow_down:

superset/views/database/mixins.py
80.70% <0.00%> (-1.76%)
:arrow_down:

... and 528 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 6b2b208...d84641a. Read the comment docs.


🐛 :

Plugin Name
Techdocs plugin
📜 Description
I want to implement Techdocs plugin on my backstage app. i had successfully added frontend code by following backstage.io official documentation. but i am facing issues while implementing backend code. the following code throwing error. i tried multiple ways but not able to resolve this error. kindly go through this and help me to get rid of these errors
async function main() {
// ... other backend plugin envs
const techdocsEnv = useHotMemoize(module, () => createEnv('techdocs'));
// ... other backend plugin routes
apiRouter.use('/techdocs', await techdocs(techdocsEnv));
}
error warnings:
Cannot find name 'useHotMemoize'.
Cannot find name 'createEnv'.
Cannot find name 'apiRouter'.
👍 Expected behavior
i want to add this code to my backstage app without any errors.
import techdocs from './plugins/techdocs';
// .... main should already be present.
async function main() {
// ... other backend plugin envs
const techdocsEnv = useHotMemoize(module, () => createEnv('techdocs'));
// ... other backend plugin routes
apiRouter.use('/techdocs', await techdocs(techdocsEnv));
}
👎 Actual Behavior with Screenshots
`/*

Hi!

Note that this is an EXAMPLE Backstage backend. Please check the README.

Happy hacking!
*/

import { createBackend } from '@backstage/backend-defaults';
import techdocs from './plugins/techdocs';
const backend = createBackend();
backend.add(import('@backstage/plugin-app-backend/alpha'));
backend.add(import('@backstage/plugin-proxy-backend/alpha'));
backend.add(import('@backstage/plugin-scaffolder-backend/alpha'));
backend.add(import('@backstage/plugin-techdocs-backend/alpha'));
// auth plugin
backend.add(import('@backstage/plugin-auth-backend'));
// See https://backstage.io/docs/backend-system/building-backends/migrating#the-auth-plugin
backend.add(import('@backstage/plugin-auth-backend-module-guest-provider'));
// See https://backstage.io/docs/auth/guest/provider
// catalog plugin
backend.add(import('@backstage/plugin-catalog-backend/alpha'));
backend.add(
import('@backstage/plugin-catalog-backend-module-scaffolder-entity-model'),
);
// permission plugin
backend.add(import('@backstage/plugin-permission-backend/alpha'));
backend.add(
import('@backstage/plugin-permission-backend-module-allow-all-policy'),
);
// search plugin
backend.add(import('@backstage/plugin-search-backend/alpha'));
backend.add(import('@backstage/plugin-search-backend-module-catalog/alpha'));
backend.add(import('@backstage/plugin-search-backend-module-techdocs/alpha'));
async function main() {
// ... other backend plugin envs
const techdocsEnv = useHotMemoize(module, () => createEnv('techdocs'));
// ... other backend plugin routes
apiRouter.use('/techdocs', await techdocs(techdocsEnv));
}
backend.start();
`

👟 Reproduction steps
https://backstage.io/docs/features/techdocs/getting-started
📃 Provide the context for the Bug.
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

For your actual problem you want to follow the steps from the new backend system section here: https://backstage.io/docs/features/techdocs/getting-started/#new-backend-system. Try that and let me know how it goes.

Thank you 😊
On Mon, 3 Jun, 2024, 20:36 Andre Wanlin, @.***> wrote:

For your actual problem you want to follow the steps from the new backend
system section here:
https://backstage.io/docs/features/techdocs/getting-started/#new-backend-system.
Try that and let me know how it goes.
—
Reply to this email directly, view it on GitHub
https://github.com/backstage/backstage/issues/25037#issuecomment-2145440075,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BH2SC5DLT2MCXU76NHWDHOTZFSA6ZAVCNFSM6AAAAABIWWO37CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVGQ2DAMBXGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi,
After setting up the Techdocs Configuration, how to check the output of Techdocs on browser, i want to know how its working. kindly help me to find out.
https://backstage.io/docs/features/techdocs/getting-started#setting-the-configuration

Hi @bhavanikorivi456! After following the entirely local setup of TechDocs outlined here, can you describe in more detail what you're seeing and what you're expecting?

Hi John Philip, I had done all the steps which provided by backstage
official documentation for Techdocs plugin
https://backstage.io/docs/features/techdocs/getting-started/#setting-the-configuration
but after giving yarn dev command, i haven't observe any Techdocs output on
the browser.
On Mon, Jun 24, 2024 at 10:05 AM John Philip @.***>
wrote:

Hi @bhavanikorivi456 https://github.com/bhavanikorivi456! After
following the entirely local setup of TechDocs outlined here
https://backstage.io/docs/features/techdocs/getting-started/#setting-the-configuration,
can you describe in more detail what you're seeing and what you're
expecting?
—
Reply to this email directly, view it on GitHub
https://github.com/backstage/backstage/issues/25037#issuecomment-2185587699,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BH2SC5FKKFHE26KU5WLRKPTZI6O2XAVCNFSM6AAAAABIWWO37CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVGU4DONRZHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @bhavanikorivi456 - if you navigate to the Docs portion of your Backstage instance, are there any documentation components there at all? Similar to https://demo.backstage.io/docs?filters[user]=all. Please provide a screenshot, as well as any other error messages you might be getting.


Require a tag policy does not validate tags against az group create command parameter.

Describe the bug

Assign a custom policy definition for Azure Policy that requires a tag for resource group.

$policyDefinition = Get-AzPolicyDefinition -BuiltIn `
    | Where-Object {$_.Properties.DisplayName -eq 'Require a tag on resource groups'}

$policyParameterObject = @{ 'tagName' = 'CreationDate' }
$nonComplianceMessages = @( @{Message="CreationDate tag is required for resource groups."} )

$policyAssignmentParameters = @{
    Name = $REQUIRE_RESOURCE_GROUPS_CREATIONDATE_TAG
    Scope = "/subscriptions/$($azContext.Subscription.Id)"
    PolicyDefinition = $policyDefinition
    PolicyParameter = $policyParameterObject
    NonComplianceMessage = $nonComplianceMessages
}

. "$(Join-Path -Path $PSScriptRoot -ChildPath 'Set-PolicyAssignment.ps1')"
Set-PolicyAssignment @policyAssignmentParameters

Create a resource group with the required tags.

az group create \
    --name "${RESOURCE_GROUP_NAME}" \
    --location "${RESOURCE_GROUP_LOCATION}" \
    --tags CreationDate=$(date --universal '+%Y-%m-%dT%H-%M-%S.%NZ')

Related command
az group create --tags KEY=VALUE
Errors
(RequestDisallowedByPolicy) Resource 'contoso-rg' was disallowed by policy. Reasons: 'CreationDate tag is required for resource groups.'. See error details for policy resource IDs.
Code: RequestDisallowedByPolicy
Message: Resource 'contoso-rg' was disallowed by policy. Reasons: 'CreationDate tag is required for resource groups.'. See error details for policy resource IDs.
Target: contoso-rg
Additional Information:Type: PolicyViolation
Info: {
    "evaluationDetails": {
        "evaluatedExpressions": [
            {
                "result": "True",
                "expressionKind": "Field",
                "expression": "type",
                "path": "type",
                "expressionValue": "Microsoft.Resources/subscriptions/resourcegroups",
                "targetValue": "Microsoft.Resources/subscriptions/resourceGroups",
                "operator": "Equals"
            },
            {
                "result": "True",
                "expressionKind": "Field",
                "expression": "tags[CreationDate]",
                "path": "tags[CreationDate]",
                "targetValue": "false",
                "operator": "Exists"
            }
        ],
        "reason": "CreationDate tag is required for resource groups."
    },
    "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/00000000-0000-0000-0000-000000000000",
    "policyDefinitionName": "00000000-0000-0000-0000-000000000000",
    "policyDefinitionDisplayName": "Require a tag on resource groups",
    "policyDefinitionEffect": "deny",
    "policyAssignmentId": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyAssignments/RequireResourceGroupsCreationDateTag",
    "policyAssignmentName": "RequireResourceGroupsCreationDateTag",
    "policyAssignmentScope": "/subscriptions/00000000-0000-0000-0000-000000000000",
    "policyAssignmentParameters": {
        "tagName": "CreationDate"
    },
    "policyExemptionIds": []
}

Issue script & Debug output
(RequestDisallowedByPolicy) Resource 'contoso-rg' was disallowed by policy. Reasons: 'CreationDate tag is required for resource groups.'. See error details for policy resource IDs.
Code: RequestDisallowedByPolicy
Message: Resource 'contoso-rg' was disallowed by policy. Reasons: 'CreationDate tag is required for resource groups.'. See error details for policy resource IDs.
Target: contoso-rg
Additional Information:Type: PolicyViolation
Info: {
    "evaluationDetails": {
        "evaluatedExpressions": [
            {
                "result": "True",
                "expressionKind": "Field",
                "expression": "type",
                "path": "type",
                "expressionValue": "Microsoft.Resources/subscriptions/resourcegroups",
                "targetValue": "Microsoft.Resources/subscriptions/resourceGroups",
                "operator": "Equals"
            },
            {
                "result": "True",
                "expressionKind": "Field",
                "expression": "tags[CreationDate]",
                "path": "tags[CreationDate]",
                "targetValue": "false",
                "operator": "Exists"
            }
        ],
        "reason": "CreationDate tag is required for resource groups."
    },
    "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/00000000-0000-0000-0000-000000000000",
    "policyDefinitionName": "00000000-0000-0000-0000-000000000000",
    "policyDefinitionDisplayName": "Require a tag on resource groups",
    "policyDefinitionEffect": "deny",
    "policyAssignmentId": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyAssignments/RequireResourceGroupsCreationDateTag",
    "policyAssignmentName": "RequireResourceGroupsCreationDateTag",
    "policyAssignmentScope": "/subscriptions/00000000-0000-0000-0000-000000000000",
    "policyAssignmentParameters": {
        "tagName": "CreationDate"
    },
    "policyExemptionIds": []
}

Expected behavior
The az group create with required tags should succeed without being restricted by the required a tag for resource group policy.
Environment Summary
{
  "azure-cli": "2.53.0",
  "azure-cli-core": "2.53.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "resource-graph": "2.1.0"
  }
}

Additional context
No response

Thank you for opening this issue, we will look into it.


#89 Block merge with fixup in CI

Closes #89
What changed
Add Block fixup commit merge action.
By ci edit only, no tests are updated.
Others

Checklist

[x] Issue is linked.

It is not needed if simple edit such as corrections of words, etc.

[ ] Test is added.

If fixed bug, add case on existing test or add new test.
If add new feature, add new test.
Add benchmark test, as needed.

[x] Test coverage rate has no decreased.

If rate is decreased, explain why in What changed.

配置間違えて動いてないし

配置間違えたおかげでfixupのテストが出来たので良し(´・ω・`)


Fix joinWithGeoIntersectNL test when SQL_PAGINATION_API_SEARCH_AFTER is true

Reference PR https://github.com/opensearch-project/sql/pull/2703/files#diff-8641a3f03cc2042ce99a65d9849b79069b163aca37445d9f7bb44329e10c3d11R292

[Weekly Catch All Triage - 1]