Question: Transfer Ownership?

It’s set for 4.0 so not urgent, but also definitely not wontfix. It already came up in our own little usecase that we needed the marketing team and me to have access to the Forms.

Transfer Ownership
**Nextcloud (please complete the following information):**
- Nextcloud-Version: 22.2.5
- Forms-Version: 2.4.0

**Is your feature request related to a problem? Please describe.**
Nextcloud is used by many companies, that implies staff turnover and leaving employees. If the account is disabled or deleted, we lost access to the forms and related data.

**Describe the solution you'd like**
We would like to be able to transfer forms ownership from an user to another, using occ commands and/or a web gui option.

**Describe alternatives you've considered**
I thought about changing manually the db, but it seems touchy and I cannot give control to it through my userbase.

**Additional context**
If this isn't a regular use case, I think it may tend to become one as Nextcloud seems to be more and more used by privacy-concerned companies. Nextcloud Files and Calendar are already proposing such a feature, it's a shame that this is not "standardized".

Thanks for your reading and thanks for the amount of work you're placing on Nextcloud as a whole.

This would be useful; User A develops the form, transfer Form to Users B,C,D... or Group. Then recipient users can share link to external people to answer/fill-in and collect their own answers.

I support this request! I set up a form for an organizer of a small community festival and wish to assign editing rights to the organizing circle. See also URL

Same here!
I have developed forms, but need my editor to be able to edit them also

Additionally:

It would be nice if you could configure to transfer all forms to another user / the admin, when a user is deleted (instead of removing the forms). This would be useful e.g. if a user leaves your company.

Hi.
thx for forms in nextcloud.
I got also to this. I would prefer to share the edit feature to someone else, e.g. a circle.

Collaborative editing of Forms
Hello!

It would be really nice if we have collaborative editing of Forms.

### Usage Examples
- The whole marketing team has access to some Forms and responses.
- My situation: I have a team of some people. They review user requests (bug reports and feature request) for my public programs. They talk with the user and create cards on the correct board in the Deck app. But only I have access to the form response and that makes it a bit harder. I have to export all response as excel/csv and send it to them every time new responses are here.

### What do I think about how It could be used
Share a Form to other users/groups and define if they have access to view the responses and if they have access to edit the Form. It should also be possible then to allow/deny re-sharing the Form.
As a good example, take the Deck app.

This feature has been discussed already here: #316

I split the part of **Ability to share responses #455** out because that one is reasonable and simpler to do.

Collaborative editing of Forms comes with all the pitfalls of conflict handling etc and it’s not something we should get into yet at this stage. :)

Is it possible to re-use some how some parts of the Text app, which allows to organise collaboration in creation of very simple forms, eg checkboxes?..

@ostasevych I don’t think so, as in Nextcloud Text we use ProseMirror as base which is focused on text editing. But ref @juliushaertl for info.

Yes, I don't think that using prosemirror and its document format here will make a lot of sense. For some collaborative editing, you could of course use a somehow similar change tracking based sync format as the text app does, but this will most likely require a larger amount of work in restructuring the database for that.

Yeah, for me it's far too complicated.
We could have a way to allow working on different questions, adding/removing.
But we cannot implement a conflict resolution (the hardes part) easily.

I'd either close as wontfix or just partial one

Great to read that this will be adressed.
Imho it's kind of misleading, that there is the sharing function with other users for forms at all

Hello, I ended up here since my and my team heavily rely on Nextcloud and if only one of us can create and edit a form without collaboration by the others, this implementation is almost useless. If I may: is it really necessary to define conflicts management? I feel like if the user just knows forms have to be edited one at a time, this integration could be **very** useful and not that hard to implement.

Thanks a lot for your work and your time!

T.

Extending the thoughts of @xplosionmind , a simple mutex-solution would be fully satisfying imho. Just have a lock on the form while it is being edited and a timeout if one forgets to free it afterwards.
Conflict handling is mainly needed for realtime or offline collaborative editing. Offline is not possible anyway (it's browser only, right?) and realtime is really cool but only necessary in corner cases. :)

I'm waiting this feature for months. I hope that doesn't take long. My job is on the table.
Sending good vibes to the dev team.
Thxx

An idea to allow for a workaround might be to implement import and export of forms (#582). Users could then share their exported, say CSV, files. The different exported CSV files could be manually merged in a spreadsheet app and imported to the final form.

This would at least work for our use case. What do you think?

hi there,

could the survey (forms) be provided with an edit(orange)/public(green) button (i.e. a button that changes color and function by click). when the button is set to edit, the edit option for groups or nextcloud-user or a public-edit-link appears. and when the button is clicked to public, the edit-group/nextcloud-user/public-edit-link is blocked and can only be edited by the creator of the survey (forms)?

or all people added as editors to the survey (forms) can click the edit/public button to 'lock' or 'unlock' the survey?

thx for your work, i like this project <3

Perhaps **Etherpad** could be useful in some way to meet this challenge: URL

I'd be happy to just have a group or circle with the right to edit - only one at a time. I'm just a user but wouldn't a file lock be enough while one is editing?

Hello and thanks for the app,
I came here because we also need this feature. In our case, the communication team needs to edit the forms that other teams make.
Thanks a lot and have a good day :)

We don't need collaborative editing, but just having more than one person who has the right to edit a form would be really useful when preparing a form together. It doesn't need to do any conflict resolution, just let me edit text in a form someone else created. That would be nice. :)


Question: Rust TL-B serialization?

### @mitinarseny thank you for the contribution!

To accurately recognize your **valuable contributions** in our repository, we kindly request you to submit a Pull Request to the Hall of Fame file, providing the wallet address and a link to the bounty with the number.

Please follow these steps:
1) Fork the repository (if you haven't already).
2) Edit the Hall of Fame file, commit, and push your changes.
3) Create a Pull Request from your fork to the main repository, providing the wallet address and a link to the bounty with the number (for example, Pull Request URL
For reference on what your entry should look like, please see the examples of past merged pull requests.

4) And please follow the questbook proposal stage in accordance with the bounty guideline

Rust TL-B serialization
### Summary

TL-B serialization is a fundamental component of the TON blockchain, enabling the encoding and decoding of data structures in a compact, efficient, and schema-based binary format. To provide Rust developers with seamless support for this critical feature, we propose developing a TL-B serialization library in Rust. This library will allow developers to work with TL-B schemas directly in their Rust applications, enhancing the capabilities of TON-based tools and services.

### Context

The TL-B (Type Language - Binary) format is widely used within the TON blockchain for serializing and deserializing data structures, such as messages, cells, and state data. While other programming languages have partial implementations or utilities for TL-B serialization, Rust lacks a comprehensive and developer-friendly library tailored for this purpose. By creating a dedicated TL-B serialization library in Rust, we can empower developers to build efficient and reliable applications in the TON ecosystem. Key features of the proposed library include:
 • Support for defining and parsing TL-B schemas directly in Rust.
 • Serialization and deserialization of TL-B data structures into binary format.
 • Bit-level data manipulation for precise TL-B compliance.
 • Recursive structure handling for complex TL-B schemas.
 • Error handling to ensure data integrity and conformity with TL-B specifications.
 • Integration with existing TON blockchain tools, such as tonlibjson, for seamless workflows.

Suppose we have a simple TL-B schema:
use std::io::{self, Read, Write};

// Example struct matching the TL-B schema
struct User {
 text: String,
 age: i32,
}

// Serialization
impl User {
 fn serialize(&self, writer: &mut impl Write) -> io::Result {
 // Serialize the text as a string (length-prefixed, for example)
 let text_bytes = self.text.as_bytes();
 let length = text_bytes.len() as u32;
 writer.write_all(&length.to_be_bytes())?;
 writer.write_all(text_bytes)?;

 // Serialize the age as a 32-bit integer
 writer.write_all(&self.age.to_be_bytes())?;
 Ok(())
 }

 // Deserialization
 fn deserialize(reader: &mut impl Read) -> io::Result {
 // Read the text length
 let mut length_bytes = [0u8; 4];
 reader.read_exact(&mut length_bytes)?;
 let length = u32::from_be_bytes(length_bytes);

 // Read the text
 let mut text_bytes = vec![0u8; length as usize];
 reader.read_exact(&mut text_bytes)?;

 // Read the age
 let mut age_bytes = [0u8; 4];
 reader.read_exact(&mut age_bytes)?;
 let age = i32::from_be_bytes(age_bytes);

 Ok(Self {
 text: String::from_utf8(text_bytes).unwrap(),
 age,
 })
 }
}

### References

Develop a Rust library that implements TL-B serialization, enabling developers to encode, decode, and manipulate TL-B data structures effortlessly within Rust applications.

### Estimate suggested reward

$5,000 USD in TON equivalent

Please visit #444 also.

Speaking of improvements, I'd like infallible (and preferably non-panicking) store functions; they seem more optimal. They could be implemented as in URL

Thank you for your submission. After careful review, we regret to inform you that we cannot proceed with your application at this time, as a Rust SDK has already been implemented as part of the Bounty program (see bounty #182).

TL-B serialization in Rust
### Summary

Implement a Rust library for effective and convenient TL-B (Typed Language Binary) serialization and deserialization.

### Context

### Why it's Important?
Implementing TL-B serialization in Rust is imperative to offer wider language support allowing more programmers to contribute to TON.

### Problem showcase:
From TL-B Language docs:

At the moment, the only existing Rust library that has very basic support for TL-B serialization and deserialization is tonlib-rs.
While it implements basic functionality for storing uints/strings/addresses into `Cell` and reading these exact types back from it, but it becomes hard to serialize complex nested structures (e.g. DeDust nested Swaps). The library does not define unified traits for serialization/deserialization, so you can't compose types with each other, while using powerful features of Rust type system. This might discourage Rust developers from contributing to the project.

### Potential Solution:
Here is my initial implementation of a Rust library that supports TL-B serialization and deserialization: URL

It already supports effective TL-B (de)serialization for primitive types and composing them into larger ones, following best practices and leveraging features of Rust type system.

The library has similar design to serde and serde_with traits. One might ask: why to define your own (de)serialization traits and not to use existing serde ecosystem and implement a new data format for TL-B? That's a reasonable question to ask and I tried this way in the beginning. But, unfortunately, per-bit serialization and references to Cells cannot be expressed with serde's data model.

### Things needed to be done:
* Documentation
* Cell serialization into bytes needs to be optimized and to reuse existing `BitSerialize` trait from this crate.
* More testing
* Publish crate to crates.io registry
* Open a PR for integration with tonlib-rs

### Future improvements:
* `syn`-powered TL-B schema parsing
* Code-gen for (de)serialization by using [`#[derive(TLBSerialize)]`]( URL

### References

* tlb – this library
* TL-B Language
* tonlib-rs

### Estimate suggested reward

$5K

I'd like to add my initial implementation: URL
Right now it only collects a list of stores to be done into a cell, but that can be modified easily.

rust
#[tlb_enum_serializable]
#[tlb_assert_unsafe(items_prefixes_nonoverlap)]
enum CommonMsgInfo {
 #[tlb_item_serializable(u 0 1bit, ihr_disabled, bounce, bounced, src, dest,
 value, ihr_fee, fwd_fee, created_lt, created_at)]
 int_msg_info {
 ihr_disabled: bool,
 bounce: bool,
 bounced: bool,
 src: ton::Address,
 dest: ton::Address,
 value: ton::CurrencyCollection,
 ihr_fee: ton::Coins,
 fwd_fee: ton::Coins,
 created_lt: u64,
 created_at: u32
 }
}

...
println!("{:?}", CommonMsgInfo::default().serialize());
// ["u 0 1bit", "u 1 1bit", "u 1 1bit", "u 0 1bit",
// "u 4 3bit", "u 0 8bit", "u 0 128bit", "u 0 128bit", "u 4 3bit", "u 0 8bit", "u 0 128bit", "u 0 128bit",
// "u 0 4bit", "u 0 0bit", "u 0 1bit", "u 0 4bit", "u 0 0bit", "u 0 4bit", "u 0 0bit",
// "u 10001 64bit", "u 0 32bit"]

There is also broxus/ton-labs-block which already has full implementation of block.tlb.

Thank you for your initiative, but it seems that there are already tools of this kind available now.

I'm happy to announce that ~tlb~ toner finally found its usage in in ton-grpc!
toner is going to be used to implement balancing over shards to safely implement deserialization of complex nested structs, such as:

tlb
_ (HashmapE 32 ^(BinTree ShardDescr)) = ShardHashes;

@akostylev0 Please, correct me if I'm wrong here.

I'm going to continue working on toner and will add a proper documentation soon.
If anyone also wants to use it, check out the docs. Please, feel free to reach out in case you have any questions or suggestions.

Hope it helps! ❤


Question: iOS return 500 while using flutter uploader with version 1.x?

What content type is the file you are uploading? You need to match it using `Content-Type`.

iOS return 500 while using flutter uploader with version 1.x
For android the flutter uploader works fine, the server able to upload the data. But for iOS, I meet this issue.
3f1086db-3486-42f2-9b66-d2523640280f

Then, I have tried the flutter uploader with version 3.0 beta, it didn't appear this error, but it straight went into this line first and the progress automatically = 100
 uploader.result.listen((result) {
 BotToast.showText(text:"Complete");
 }
 instead of this
 uploader.progress.listen((progress) {
 BotToast.showText(text:progress.progess.toString());
 }

then it automatically run 2nd time ( uploader.enqueue() ) then start from listening the progress=0. When the progress =100 and result = UploadTaskStatus.complete , it did toast the complete but my server couldn't receive any data from it.

have you checked that the issue is not the content-type header? we had the same issue (server not receiving anything when the request came from iOS but worked fine on android) and setting no content-type header worked for MultipartFormDataUpload
Related issue #204

@raphaelgurtner what does setting no content-type header means? Can you please tell me what to write? Here is my code:

await FlutterUploader().enqueue(
 RawUpload(
 url: uploadUrls[i],
 // required: url to upload to
 path: selectedVideos[i].path,
 // required: list of files that you want to upload
 method: UploadMethod.PUT,
 // HTTP method (POST or PUT or PATCH)
 // headers: {"apikey": "api_123456", "userkey": "userkey_123456"},
 tag: 'post video uploading', // custom tag which is returned in result/progress
 ),
 );

Fail to upload file in IOS
Hi , thanks for great work!
I use flutter_uploader 1.2.1 to upload file and photos to server, server code is asp.net core web api ,like following code:
public Response UploadFile(IFormFile file)
{
 /* code ...*/
}
everything is ok where in Android.
but in IOS device：iphone 7 plus. it is not work.
from log, file had been uploaded ,but in server file is null（as code above）.
log:
URLSessionDidCompleteWithError: upload completed
URLSessionDidCompleteWithError: response: {"returnValue":null,"isSuccess":false,"code":"0","description":"no file！"}, task: completed
URLSessionDidSendBodyData: taskId: chillisource.flutter_uploader.upload.background.13, byteSent: 390718, totalBytesSent: 390718, totalBytesExpectedToSend: 390718, progress:100.0
URLSessionDidReceiveData:
URLSessionDidCompleteWithError: chillisource.flutter_uploader.upload.background.13 with response: ...

would you please give some help?

@tranice what does setting no content-type header means? Can you please tell me what to write? Here is my code:

await FlutterUploader().enqueue(
 RawUpload(
 url: uploadUrls[i],
 // required: url to upload to
 path: selectedVideos[i].path,
 // required: list of files that you want to upload
 method: UploadMethod.PUT,
 // HTTP method (POST or PUT or PATCH)
 // headers: {"apikey": "api_123456", "userkey": "userkey_123456"},
 tag: 'post video uploading', // custom tag which is returned in result/progress
 ),
 );


Question: Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API?

A dependency date was set as 15 November 2022 to align with the Energy release timeframe and considerations to change this date will be discussed further through Issue #507 in Maintenance Iteration 11.

This change was incorporated into release v1.17.0.

Please refer to Decision 237 for further details.

Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API
# Description
As part of the API Uplift for Data Holder Multi-Sector support #424, there are considerations to be made on how the GetDataHolderBrands endpoint can be augmented to allow unauthenticated client access.

This piece of work has been extracted into its own change request to allow this topic to be considered beyond maintenance iteration 9.

# Area Affected
Register APIs will need to be structured to expose GetDataHolderBrands information from a public API

# Change Proposed

The following changes are proposed:

1. Create a new GetDataHolderBrands endpoint returning the same payload in time for energy
2. Move this endpoint out of the secure domain, removing MTLS and authentication requirements
3. Move this endpoint into the public API domain, allowing the API to be accessible via CDN and leverage ETags
4. Add industry filtering behaviour:
• Default: All data holder brands will be returned
• Query parameter filter: allow filtering by industry sector
5. Remove paging, aligning the response definition to other public APIs

## Options:
1. Create an unauthenticated Data Holder Brands API returning the same content as the current authenticated API. The authenticated version of the API will be deprecated once a schedule has been determined

2. Create an unauthenticated Data Holder Brands API returning a subset of the content currently returned in the authenticated API. Security endpoint information would NOT be included in this API. Both the authenticated and unauthenticated APIs would be maintained.

## Considerations:

- What are the consequences of making this information available publicly?
- What are the use cases which will be used from the public and authenticated APIs?

During MI #10, it was identified that one of the key use-cases for having a public GetDataHolderBrands API is to allow public clients to discover data holders in the CDR and their respective product reference data, status, and outage endpoints.

Option 2 could be conceivably constrained in scope to target this use case.

Thanks for taking the time to assess the issue and develop a proposed solution. Stay or Go is supportive of Option 1 proposed above - i.e. the create a new API, `Get Product Reference Data Endpoints`.

With regard to the `brandId`, this should be the same as the `dataHolderBrandId` in the existing `Get Data Holder Brands` API.

This has obviously been a significant gap and oversight for 2-3 years since the PRD endpoints were first implemented in the banking industry, so we request this change be ranked as an absolute priority for implementation Waiting until the end of the year, when Energy is to be implement, is not really acceptable in our mind.

Given conversations during the maintenance iteration, the ACCC would like to make it clear that if it is not acceptable for brandId to be optional, this item will need to be delayed until a time that the ACCC can assess a solution where this would be achievable.

With regard to `brandId` and a delay, I think 'delay' and the trade-off needs to be defined. If the API can be delivered within the next month without the brandId, then that would be worth doing. If its going to be delivered in 6 months, then brandId should be in-scope.

If faced with the above choice, I'd recommend delivering V1 of the API in one month's time without the `brandId` and then add it to the API in 6 months time as V2.

Not having `brandId` does create significant complexity and operational risk for anyone consuming the data, so its not an acceptable long-term solution.

Not having the API at all make the PRD largely unusable, and certainly unreliable.

Collaboration on this issue through maintenance iteration 10, has resulted in the following DSB proposal, expanding off of @ACCC-CDR's initial proposal.

Rather than duplicate the GetDataHolderBrands API for unauthenticated clients, a new API optimised for discovery of public data holder APIs (PRD, status, and outage and any future public endpoints) will be defined named: `Get Data Holder Brand Public Endpoints`

The schema will be optimised for presentation of Data Holder Brands and discovery of associated public endpoints. It will therefore have the following fields:

Name | Type | Required | Description
-- | -- | -- | --
brandName | String | true | Name of the data holder brand hosting the public endpoints
brandId | String | ~false~ true | ID of the data holder brand hosting the public endpoints
publicBaseUri | UriString | true | Public endpoints base URL
logoUri | UriString | true | Data Holder Brand logo URL
~industry~ industries | ~String~ [string] | true | The industries the Data Holder Brand belongs to. Please note that the CDR Register entity model is constrained to one industry per brand which is planned to be relaxed in the future.
lastUpdated | DateTime | true | Time when the record was last updated
abn | String | false | Australian Business Number for the organisation
acn | String | false | Australian Company Number for the organisation
arbn | String | false | Australian Registered Body Number. ARBNs are issued to registrable Australian bodies and foreign companies

The payload will be a shortened version of the data holder brands payload with a flat simplified structure.

The industries array will follow the same convention as GetDataHolderBrands URL Only one industry will initially be supported until multiple industry sectors per brand are supported on the CDR Register.

Discussion has occurred on whether the brandId can remain optional until the CDR Register is able to guarantee the field will be populated. The DSB does not seek to define an interim solution in the standards. This leaves the responsibility to the ACCC to coordinate the release of this API based on their release schedules. Any interim solution will also remain the responsibility of the ACCC.

Feedback we have received from the ACCC indicates they will not be able to specify a delivery date for the proposed solution and an interim solution will be required. As highlighted from ACCC's feedback, a mandatory `brandId` will not be available in the short to medium term.

Feedback from industry during MI 10 has highlighted that an interim solution that provides a mandatory unique identifier in addition to the `brandId`, would meet the need to reconcile each record until a complete solution can be delivered.

In order to give the ACCC flexibility in delivering the full solution, provide partial value to API clients, and to simplify reading of the standards, the DSB has decided to propose an interim solution.

## Proposal

Based on the feedback received from stakeholders, the DSB proposed the following:

1. `brandId` moves from mandatory to optional
2. To enable clients to reconcile data holder brand records from this API with those retrieved in previous requests, an interim identifier (`interimId`) is proposed. This will allow for clients to use the following logic:
a. IF the record includes a `brandId`, use `brandId` as the record identifier ELSE use `interimId` as the record identifier
b. If in a future request the `brandId` is populated, move the record identifier from `interimId` to `brandId`
3. For each record, when `brandId` is finally populated, the `interimId` will be maintained for a minimum of 1 month prior to being retired.

This logic will provide a transition period, allowing clients to migrate records from referencing the `interimId` to the `brandId` in anticipation of `brandId` becoming the mandatory identifier. Once `brandId` becomes the defacto standard identifier, `interimId` can be phased out per record after the transition period of a minimum of 1 month has passed.

**Interim Solution (V1) - targeted latest dependency date of 01st October 2022**
_Note that this solution is intended to be a temporary solution until the ACCC is able to deliver the complete solution._

Name | Type | Required | X-Conditional | Description
-- | -- | -- | -- | --
brandName | String | true |   | Name of the data holder brand hosting the public endpoints
brandId | String | false | true | ID of the data holder brand hosting the public endpoints.  To be used to uniquely identify the record and not to be reused
interimId | String | false | true | Interim ID of the data holder brand hosting the public endpoints. This is to be used to uniquely identify the record when brandId is not populated and is not to be reused
publicBaseUri | UriString | true |   | Public endpoints base URL
logoUri | UriString | true |   | Data Holder Brand logo URL
industries | [string] | true |   | The industries the Data Holder Brand belongs to. Please note that the CDR Register entity model is constrained to one industry per brand which is planned to be relaxed in the future.
lastUpdated | DateTime | true |   | Time when the record was last updated
abn | String | false |   | Australian Business Number for the organisation
acn | String | false |   | Australian Company Number for the organisation
arbn | String | false |   | Australian Registered Body Number. ARBNs are issued to registrable Australian bodies and foreign companies

**Complete Solution (V2) - targeted release to be assessed in a future maintenance iteration**

Name | Type | Required | Description
-- | -- | -- | --
brandName | String | true | Name of the data holder brand hosting the public endpoints
brandId | String | true | ID of the data holder brand hosting the public endpoints.  To be used to uniquely identify the record and not to be reused
publicBaseUri | UriString | true | Public endpoints base URL
logoUri | UriString | true | Data Holder Brand logo URL
industries | [string] | true | The industries the Data Holder Brand belongs to. Please note that the CDR Register entity model is constrained to one industry per brand which is planned to be relaxed in the future.
lastUpdated | DateTime | true | Time when the record was last updated
abn | String | false | Australian Business Number for the organisation
acn | String | false | Australian Company Number for the organisation
arbn | String | false | Australian Registered Body Number. ARBNs are issued to registrable Australian bodies and foreign companies

This approach look fine. Key to success is to deliver the interim solution quickly. Thanks

The ACCC reiterates it’s previous commentary that if the solution the ACCC has previously proposed is not accepted then we’ll be unable to commit to a 1st of October 2022 delivery date. The ACCC does not support the inclusion of an `interimId` for the same reason it does not support a mandatory `brandId`, the additional solution delivery and operational effort. If the ACCC’s proposed solution cannot be agreed upon, the ACCC suggests deferring this GitHub issue to the next Maintenance Iteration so that the alternative options that the ACCC proposed on the 23rd March can be discussed.

This sounds a _lot_ like hostage taking by the regulator, perhaps if the ACCC engaged the community earlier it wouldn't be facing timeline issues. October is 6 months away, that's the time accepted by all the other participants in the ecosystem, I find it pretty hypocritical for the ACCC to enforce FDO obligations, request shorter timelines on Participants and then not accept the convention for its own delivery.

Is the ACCC _honestly_ suggesting that these records _don't_ already have a database identifier associated with them? If there isn't an identifier already present how else would the ACCC be administering the records? Hand coding them? Smoke signals from some tower in Canberra? I thought the `interimId` proposal was to allow for the id to change which seems to eliminate any architectural reason to oppose it.

I was at the last maintenance call and I don't believe ACCC bothered to show up, perhaps it should have. If the ACCC is going to throw its toys out of the pram whenever it doesn't get what it wants then perhaps the Minister should be called in to resolve _who exactly is responsible_ for Register related Standards since it seems increasingly ambiguous.

It isn't a reasonable nor sustainable solution for non-government technical implementers trying to plan activities based on guidance from multiple government bodies on delivery timelines that are, in the Register case, quite opaque.

Just want to highlight again that this API is already close to 3 years late - i.e. it should have been delivered on 1-Jul-2019 when the first PRD APIs were launched. Waiting another 6 months for this API really isn't an acceptable outcome for the industry or the success of the CDR.

This is a very simple API and shouldn't take more than a week to build. We therefore request that it be priorities and delivered within the next 4 weeks. Happy to have a conversation with the ACCC (assuming they are responsible for building the API) if technical advice is required.

Regarding the `interimId`, the suggestion above to use the ACCC's existing database identifier makes sense, assuming they have one. If the existing database has been implemented without a unique identifier (e.g. in an Excel spreadsheet), then the ABN should be a sufficient proxy - i.e. a company may rebrand, but they don't normally change their ABN. Otherwise, it would be very simple to add an 'interimId' the the existing database.

To summarise, the contention remained that the `interimId` presented increased complexity for ACCC delivery, conflicting with industry highlighting the urgency of delivery of this API with a mandatory identifier in order to be fit for purpose.

With this being considered, the DSB’s position remained unchanged as the interim solution shares the implementation burden between the CDR Register and clients until the complete solution is available. No other solution has been proposed which is seen as fit for purpose. The 1 October 2022 delivery date proposed is the latest that this API can be released and provide meaningful value to the CDR. Later delivery will erode the value of this API as industry may look for alternative sources for discovery. Earlier delivery will increase the value of this API as it will increase the period unauthenticated clients are able to leverage its value and increase confidence that the CDR Register is the source of truth in the CDR.

| API Details | |
| ------------- | ------------- |
| **API Name** | Get Data Holder Brands Summary |
| **Path** | `GET /cdr-register/v1/{industry}/data-holders/brands/summary` |

Release v1.17.0. for the CDS incorporates the interim solution **(V1)** into the standards.

Issue #518 has been raised to track delivery of the Complete Solution **(V2)**

Please refer to Decision 237 for further details.

Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes
# Description
The introduction of the energy sector will introduce the following new authorisation scopes to the CDS:

| New Authorisation Scopes for Energy|
|--|
| energy:electricity.servicepoints.basic:read |
| energy:electricity.servicepoints.detail:read |
| energy:electricity.usage:read |
| energy:electricity.der:read |
| energy:accounts.basic:read |
| energy:accounts.detail:read |
| energy:accounts.paymentschedule:read |
| energy:accounts.concessions:read |
| energy:billing:read |

Banking data holders who do not participate in the energy sector are not going to support energy APIs and the associated authorisation scopes.

Clarification is required on how data holders should behave when receiving registration create and update requests where the SSA `scope` field is populated with unsupported scopes.

# Area Affected
Security Profile > Client Registration

# Change Proposed
This is not the first time where unsupported scopes have been populated in SSAs. Banking sector phasing resulted in this scenario occurring.

Feedback on this issue needs to be reviewed and considerations made as to whether the standards need to articulate this behaviour

For reference, guidance on this issue has previously been provided: URL

It has been an expectation that Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations, as reflected in the following guidance: URL

However, this hasn't been explicitly called in the standards and there is an opportunity for the standards to clarify this scenario.

The DSB proposes that the standards are updated to specify that:

_Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations._

A future dated obligation would align this change with the Energy release timeframe of 15th November 2022.

ACCC strongly supports the proposed change outlined above and requests an earlier obligation date to support the introduction of Energy. ACCC proposes 15th September 2022 as the future dated obligation, to ensure Data Holders are responding correctly to data requests prior to the implementation of the Energy Sector.

After incorporating feedback from the community through maintenance iteration 10, the proposal is being updated to move this requirement from a SHOULD to a MUST.

The DSB now proposes that the standards are updated to specify that:

_Data Holder Brands MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations._

Regarding changing the FDO to 15th September 2022, further discussion is required to consider having an FDO less the 6 months out. Changes to the FDO will not be considered as part of maintenance iteration 10 however, will be considered for maintenance iteration 11.

The DSB invites the community to comment on this change

Issue #507 has been raised to investigate the opportunity for modifying the FDO date for this piece of work

ForgeRock is seeking clarification. This article URL states that:

"As described, the DH would allow the request but accept the client registration with the subset of scopes the DH supports per RFC7591"

However, this RFC does not state that subsets of scopes should be supported during Dynamic Client Registration. It states:

"The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes."

This comment appears to indicate that either a precise set of scopes be requested during DCR, or none at all.

RFC7591 does point to RFC6749 [ URL which allows subsets, but as RFC6749 pertains to authorization, not registration, this is seen by ForgeRock as irrelevant.

Question
Has this change proposal been backed by the OAuth2.0 standard? (and could you please point me to the document, or perhaps point out any misunderstanding of the above document/s?) Or has CDR requested a change to the standard to allow vendors to enable our customers to support the approach?

Hi @SlatsFR, the reference in regards to RFC7591 is towards general dynamic client registration requirements.

The reason for DHs ignoring unsupported scopes is due the the way the CDR Register operates. It issues the SSA signed using the Register CA cert incorporating all scopes an ADR is accredited for. The way the CDR Rules are expressed it means that once a data recipient is accredited, they are accredited for all sectors and hence all scopes across those sectors: right now that is banking and energy. In future that will include telecommunications etc.

To ensure that an ADR can successfully manage their client registration with a DH when they present all scopes (noting that the ADR cannot control which scopes the CDR Register generates for it), the DH needs to facilitate the client registration updates without rejecting the request.

Hope that helps.


Question: Cannot handle enums with numeric fields?

The problem is here: URL

OpenApi calls `.values()` to get the values of the enum. This calls (for Java) the following in core URL

The problem is that inside that code (even if we copy it to the openapi module) we don't have access to any bean metadata that Micronaut produces. All the `Element`s in the stream are javax elements and not Micronaut. I don't see a way to check if those element have the appropriate annotation to generate the right value instead of the `toString()` that it's done at this moment.

@graemerocher any thoughts if there is a way to do this?

Cannot handle enums with numeric fields
### Expected Behavior

When presented with enum with number fields (e.g. `FOO(1)`), it should respect `@JsonValue` and `@JsonCreator` and should compile.

### Actual Behaviour

When running the test, compilation fails with

 Caused by: com.fasterxml.jackson.databind.JsonMappingException: Cannot deserialize value of type `java.lang.Number` from String "EdDSA": not a valid number

This works fine in micronaut 3.

The error does not really make sense as the enum should be serialized to a number (based on `@JsonValue`) and never be in the string form.

### Steps To Reproduce

1. Clone URL
2. Run the test and see compilation fail with the above error (it does not even get to running the test)
3. Adjust the HelloController to use COSEAlgorithmIdentifier2 (with 2 suffix). This uses `@JsonProperty` instead
4. Re-run the test and see it pass

Raising this in micronaut repo, as the same enum class serializes and deserializes fine with jackson by itself.

### Environment Information

- OSX
- JDK 21
- Micronaut 4.0.0 -> 4.7.6

### Example Application

 URL

### Version

4.7.6

From URL it appears that maybe `@JsonValue` is not really supported. If that is still the case, it would be good to at least be able to compile (like in micronaut 3), rather than blow up.

Unfortunately, this is a limitation of the annotation processor. You see, the annotation processor does not see your code and cannot execute it, it only sees the class structure. Therefore, all I can see is a method or field that is marked as JsonValue , but I cannot uniquely calculate the values that correspond to enums.

For example, if a method is marked as JsonValue , then it is not necessarily a simple getter, there may be other logic, but I cannot see it in the annotation processor.

Similarly, with a field marked as JsonValue - the enum field does not necessarily correspond to the argument of the enum constructor, it may well be transformed in the constructor.

Moreover, the annotation processor does NOT see the values that you describe in the enum constructor. For example yuor example:

java
public enum COSEAlgorithmIdentifier {
 EdDSA(-8),
 RS1(-65535);
...
}

micronaut openapi doesn't see values `-8` and `-65535`, because it is a code. Annotation processor can see only annotations and values inside annotaions.

The single way to work with it - add annotaion for every enum constant:

java
public enum COSEAlgorithmIdentifier {
 @JsonProperty("-8")
 EdDSA(-8),
 @JsonProperty("-65535")
 RS1(-65535);
...
}

I see. Is there any reason why it would not crash in micronaut 3 then?

Given the enum class is from an external depenendency not directly in my control, do you have any suggested workaround that doesn't involve maintaining a copy of the class in my own code base?

I can't tell you, but this is not a micronaut-openapi problem. This annotation processor is only used to generate the OpenAPI spec for your code and does not play any role in the actual operation of the application, so you should create an issue in micronaut core , not here.

Please, create an issue in micronaut-core module ( URL because micronaut-openapi just create openapi.yml file

@gnarroway-bullish fixed it here: URL

So, the problem is that micronaut openapi determined the type of your enum correctly, analyzing the method with the annotation `@JsonValue` - the type was integer .

But because you did not put the annotation JsonProperty , an incorrect schema was obtained with the type integer , but the values of the enum `EdDSA` and `RS1`

Serialization and deserialization occurred inside, due to which the values of `EdDSA` and `RS1` tried to be converted as numbers, because the type of the schema is integer .

In general, I made it so that now information about the annotation JsonProperty will be written in the console and the enum type will be set as string . Thus, there will be no error, there will be a message that there is not enough information to correctly construct the enum schema

thank you @altro3 , and really appreciate the responsiveness

JsonProperty not getting picked up by yaml generation for Enum
### Task List

- [ X ] Steps to reproduce provided
- [ N/A] Stacktrace (if present) provided
- [ N/A] Example that reproduces the problem uploaded to Github
- [ X ] Full description of the issue provided (see below)

### Steps to Reproduce

1. Create Java Enum Class with JsonProperty

import com.fasterxml.jackson.annotation.JsonProperty;

public enum CurrencyPair2 {
 @JsonProperty("CAD-USD") CADUSD("CAD", "USD");
 private final String baseCurrency;
 private final String quoteCurrency;

 CurrencyPair2(String baseCurrency, String quoteCurrency) {
 this.baseCurrency = baseCurrency;
 this.quoteCurrency = quoteCurrency;
 }

 public String getBaseCurrency() {
 return baseCurrency;
 }

 public String getQuoteCurrency() {
 return quoteCurrency;
 }

}

2. Reference class in response object/request params
3. Build OpenApi:

annotationProcessor("io.micronaut.openapi:micronaut-openapi")
...
implementation("io.swagger.core.v3:swagger-annotations:2.1.6")
...

tasks.withType(JavaCompile) {
 options.fork = true
 options.forkOptions.jvmArgs << '-Dmicronaut.openapi.views.spec=rapidoc.enabled=true,swagger-ui.enabled=true,swagger-ui.theme=flattop'
}

4. Check Swagger output

### Expected Behaviour

Enum values should be CAD-USD and serialization should convert appropriately

CurrencyPair2:
 type: string
 enum:
 - CAD-USD

### Actual Behaviour
Serialization converts on ingress and egress appropriately but enum values are CADUSD in the swagger schema

CurrencyPair2:
 type: string
 enum:
 - CADUSD

Tell us what happens instead

### Environment Information

- **Operating System**: MavOS Mojave version 10.14.6
- **Micronaut Version:** 1.3.4
- **JDK Version:**
- OPENAPI_VERSION=2.0.10

### Example Application

- TODO: link to github repository with example that reproduces the issue

@ccorcoran-nydig Hi! I added the ability to view annotations on enum constants - URL . But this feature will appear only in release `3.6.0`. After that, it will be possible to implement this feature

@altro3 Any plans to add support for `@JsonValue` annotation?

@altro3 Hi! I thought about it, but could not come up with a normal solution to support this annotation. Watch how the library works: the analyzer parses the structure of classes and enums, and can read the annotations that are used there.

So, the problem is: in order to support JsonValue, you need to call the method, i.e. run certain logic to understand what value will be the result.

In general, I'm just not sure that such logic is possible in this library. :-(

@daltonconley Hi! I thought about it, but could not come up with a normal solution to support this annotation. Watch how the library works: the analyzer parses the structure of classes and enums, and can read the annotations that are used there.

So, the problem is: in order to support JsonValue, you need to call the method, i.e. run certain logic to understand what value will be the result.

In general, I'm just not sure that such logic is possible in this library. :-(

@daltonconley I have good news for you. I implemented JsonValue annotation support :-). We are waiting for the merge of my changes and the new release (see URL

@altro3 Was pleased to see the above PR as I have a similar issue with @JsonValue which I expected would be fixed with your latest commit. I've built 4.5.0-SNAPSHOT from your PR and updated the dependency of my minimal recreation project locally and there's some improvement as it seems to obey the @JsonProperty annotation but still doesn't work for me with @JsonValue.

Interestingly I now get the warning:

Note: Generating OpenAPI Documentation
{path omitted}.../swagger-enum-gen/src/main/java/com/example/ResponseEnum.java:8: warning: Can't find enum class com.example.ResponseEnum

when running, but it still outputs the yaml with the Enum names (and one JsonProperty value).

The checked in bug recreation project above is still on the default dependencies rather than on your snapshot version. Please shout if I can be of any assistance. Thanks very much for your efforts!

@dclarke18 @daltonconley I also tested this functionality. Well, unfortunately this functionality cannot be done in any way. I rolled back my changes because my solution only works at the testing level. The problem lies in the limitations of Java itself. Java, when executing annotation processors, does not load classes from the main classpath and does not provide access to the source codes of these classes. Those. the annotation processor only accesses the structure of the classes, but cannot call methods from these classes or read the method bodies in any way. So the only solution for enums is to put a JsonProperty annotation on each enum value.

Processing JsonValue at the annotation processor level is impossible to do :-(


Question: Deno add - "Failed to install from package.json" "Unexpected character."?

It looks good, but I think we probably dont' need any changes in deno_semver. Probably it could just be handled in deno_package_json (I'm not sure though)

Deno add - "Failed to install from package.json" "Unexpected character."
Version: Deno 2.0.4

$ deno add npm:debug
Add npm:debug@4.3.7
error: Failed to install from package.json

Caused by:
 0: Invalid version requirement
 1: Unexpected character.
 ^
 ~
$ cat deno.json
{
 "name": "...",
 "description": "...",
 "version": "3.0.0-alpha.5",
 "exports": "./src/index.ts",
 "tasks": {
 "build": "deno run --allow-read --allow-write scripts/export-json-schema.ts",
 "coverage": "deno coverage | deno run jsr:@silverbucket/threshold 100 88",
 "test": "deno test --coverage --clean --allow-env src/**/*.test.ts"
 },
 "imports": {
 "@silverbucket/threshold": "jsr:@silverbucket/threshold@1.0.2",
 "@types/node": "npm:@types/node@22.5.0",
 "@types/debug": "npm:@types/debug@4.1.12",
 "ajv": "npm:ajv@8.12.0",
 "ajv-formats": "npm:ajv-formats@2.1.1",
 "@silverbucket/ajv-formats-draft2019": "jsr:@silverbucket/ajv-formats-draft2019@1.6.1",
 "debug": "npm:debug@4.3.7"
 }
}

I tried reproducing the problem and with provided `deno.json` and running `deno add npm:debug` I don't get any error. @silverbucket could you please provide more information about your project?

@bartlomieju Sure what would you like to see? To answer your question, there is no package.json.

bash
$ ls -al
total 40
drwxr-xr-x@ 9 njenning staff 288 Oct 31 01:26 .
drwxr-xr-x@ 15 njenning staff 480 Aug 26 23:06 ..
-rw-r--r--@ 1 njenning staff 1077 Aug 26 23:06 LICENSE
-rw-r--r--@ 1 njenning staff 271 Aug 29 14:54 README.md
drwxr-xr-x@ 2 njenning staff 64 Oct 31 01:24 coverage
-rw-r--r--@ 1 njenning staff 823 Oct 31 01:26 deno.json
-rw-r--r--@ 1 njenning staff 5814 Aug 27 17:53 deno.lock
drwxr-xr-x@ 4 njenning staff 128 Aug 27 17:44 scripts
drwxr-xr-x@ 12 njenning staff 384 Oct 31 01:23 src

$ deno add npm:debug
Add npm:debug@4.3.7
error: Failed to install from package.json

Caused by:
 0: Invalid version requirement
 1: Unexpected character.
 ^
 ~

It might be worth mentioning that this is a mono-repo, however I've never had issues converting packages one at a time with deno 1.45, it was only upgrading to 2.0.x that I started getting issues like this.

We should improve this error message to say the file the error occurs in. Probably there's a package.json in the workspace in this case.

Using deno `2.0.6` I'm getting another variation of this bug. Same repo I mentioned about, this time it's not with the `package.json` at the root of the repository, but a different pacakge at the same level as the `schemas` package.

bash
project-root/packages/schemas $ deno install
error: Failed to install '@sockethub/client'
 at file:///project-root/packages/examples/package.json

Caused by:
 0: Invalid version requirement
 1: Unexpected character.
 ^
 ~

@nathanwhit Should I create a new ticket? Or can you re-open this one?

Hmm we're putting the dependency in the correct file now, but we error out because we validate all of the `package.json` files in the workspace when we cache the dependencies, and one of them has a version requirement (`workspace:^`) that we don't support.

I feel like maybe we should make `workspace:^` not a hard error? Or at least not a parsing error

Hey, Im facing a similar issue when upgrading from v1.146 to v2.

We have a backend monorepo and it uses `import_map.json` files to manage dependencies per sub module in our monorepo. We don't have a package.json (except our Next.js frontend which is still on node). we do have a deno.jsonc at the root level of our project. After upgrading Deno, we get these errors when we run or try to install:

sh
# install
error: Error in @stripe/react-stripe-js@3.1.0 parsing version requirement for dependency "react-dom": ">=16.8.0 && <=^19.0.0"
deno install
Caused by:
 0: Invalid version requirement
 1: Unexpected character.

 ~

sh
# run
Running service
Watcher Process started.
error: Could not find a matching package for 'npm:pg@8.12.0' in the node_modules directory. Ensure you have all your JSR and npm dependencies listed in your deno.json or package.json, then run `deno install`. Alternatively, turn on auto-install by specifying `"nodeModulesDir": "auto"` in your deno.json file.

Watcher Process started.
error: [ERR_MODULE_NOT_FOUND] Cannot find module 'file:///Users/app/node_modules/type-fest/index.js' imported from 'file:///Users/app/@types/date.types.ts'
 at file:///Users/app/@types/date.types.ts:8:24

this is part of our import_map.json file:

json
{
 "imports": {
 "kysely": " URL
 "pg": "npm:pg@8.12.0",
 "query-string": " URL
 "remeda": " URL
 "stripe": " URL
 "type-fest": "npm:type-fest@4.30.1",
 "zod": " URL
 }
}

"react-dom": ">=16.8.0 && <=^19.0.0"

image

This doesn't work the way they probably think.

undefined

true

I opened URL

A huge problem in npm dependencies is npm allows people to just put whatever even when it doesn't make sense. I'll update deno_semver to handle that situation. Follow URL for updates

I think though the original issue can now be closed because workspace specifiers like `workspace:^` are now implemented URL

Support other `workspace:` specifiers
Currently Deno supports `workspace:*` specifiers in `package.json`, but tools like pnpm also support
`workspace:^`, `workspace:~` and others.

See URL

Necessary changes would need to be applied around this code:
 URL

I did some digging into this and here's what I found:
1. Handling of `workspace:` specifiers in `package.json` is done here: URL
2. The `workspace:` prefix is stripped and the remainder is passed to `VersionReq::parse_from_npm` from `deno_semver`: URL
3. `*` or `x.y.z` are valid ranges in this context, but `~` and `^` are not
4. It appears that simply stripping `workspace:` is not good enough here and we should have a dedicated functionality in `deno_semver` to handle `workspace:` version constraints that will accept `~` and `^`, otherwise we'd have to alter the current parsing which would break other stuff, because `"mypackage": "^"` is not a valid range, but `"mypackage": "workspace:^"` is.

@dsherret do you agree here?


Question: Evaluate DAG versioning & bundles with a Airflow 3 pre-release?

Create a PR isolating changes and add conditionals so we can all work using this same code base

Evaluate DAG versioning & bundles with a Airflow 3 pre-release
**What we want to do**

Evaluate how DAG Bundles and DAG versioning are behaving with Cosmos.

Try out Airflow 3.0 with Cosmos example DAGs:

COMMIT_SHA=573cd95 AIRFLOW_HOME=$(pwd) uvx \
 --python 3.11 \
 --from "git+ URL \
 --with "git+ URL \
 --with "git+ URL \
 bash -c "
 cd \$(python -c 'import airflow, os; print(os.path.dirname(airflow.__file__))') && \
 # Build the new UI (located in the 'ui' directory)
 cd ui && pnpm install && pnpm build && \
 # Build the legacy UI (located in the 'www' directory)
 cd ../www && yarn install --frozen-lockfile && yarn run build && \
 airflow standalone
 "

See the UI working in:
 URL
 URL

Focus on the work of these AIPs:
* AIP-63: DAG Versioning
* AIP-66: DAG Bundles & Parsing

**Acceptance criteria**

* [ ] Document which Airflow/Cosmos version was tested
* [ ] Raise any concerns and problems faced with @jedcunningham and team
* [ ] Have an action plan

@phanikumv suggested we try this with the nightly image. We can check with Rahul

Tables of interest:
- dag_run:
- dag_version:
- serialized_dag:
- dag_code:

1. Run Cosmos DAG - v X
2. Without changing Cosmos DAG, re-run v X
3. Change Cosmos python code, re-run v Y
4. Change dbt project, re-run, v Z

We need to use a version backend. We need to use the Git Repo

TODO:
- add diagram
- add reference on GitRepo

This is expected to work with local executors only.

This is likely not expected to run using DAG test.

I spoke to @jedcunningham, and he suggested we try out the alpha, since this has been released since we first wrote this ticket - it would make our lives easier. He'll share the info with us

We have an Airflow standalone local setup for AF3 beta2, and we are experiencing issues even in loading individual cosmos tasks, for instance, `DbtCloneLocalOperator`. So, we are removing this issue from the scope of the current sprint and will work on URL and URL

Tested some basic cases

Keeping the dbt Project Outside the DAG Folder:

- Modifying the DAG file updates the DAG version.
- Changes made to the dbt project do not impact the DAG version.

Keeping the dbt Project Inside the DAG Folder:

- Modifying the DAG file updates the DAG version.
- Changes made to the dbt project do not affect the DAG version.

This is what we were expecting. I’ll do a deeper analysis further.

I tested the DAG below, which is independent of Cosmos, and found that changing the content in the Python file /usr/local/airflow/dags/hello.py does not update the DAG version.

python
from airflow.providers.standard.operators.bash import BashOperator
import datetime
from airflow.sdk import DAG
import pendulum

with DAG(
 dag_id="example_bash_operator",
 schedule="0 0 * * *",
 start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
 catchup=False,
 dagrun_timeout=datetime.timedelta(minutes=60),
 tags=["example", "example2"],
 params={"example_key": "example_value"},
) as dag:
 run_this = BashOperator(
 task_id="run_after_loop",
 bash_command="python /usr/local/airflow/dags/hello.py",
 )

I'm trying to understand how we decide if the DAG version needs to be updated:
Reaching out team here for the same: URL

It seems there's a bug in the DAG bundle; I've reported the issue here: URL

Be able to parse and run a DAG containing one Cosmos Local operator in Airflow 3
**Context**

We are facing several issues when attempting to run Cosmos with Airflow 3. To advance, we're reducing the scope of the problem so we can iterate quicker.

Once #1620 is completed, we want to run in Airflow 3 a simple DAG built with parts of Cosmos using the following configuration:

* `RenderConfig` should use `LoadMode.DBT_MANIFEST`
* `ProfileConfig` with Profile YAML

Example:

import os
from datetime import datetime
from pathlib import Path
from typing import Any

from airflow import DAG

from cosmos.config import ProfileConfig
from cosmos.operators.local import DbtCloneLocalOperator

DEFAULT_DBT_ROOT_PATH = Path(__file__).parent / "dbt"
DBT_ROOT_PATH = Path(os.getenv("DBT_ROOT_PATH", DEFAULT_DBT_ROOT_PATH))
DBT_PROJ_DIR = Path("/Users/pankaj/Documents/astro_code/airflow3_dev/jaffle_shop")
DBT_PROFILE_PATH = DBT_PROJ_DIR / "profiles.yml"
DBT_ARTIFACT = DBT_PROJ_DIR / "target"

profile_config = ProfileConfig(
 profile_name="default",
 target_name="dev",
 profiles_yml_filepath=DBT_PROFILE_PATH,
)

with DAG("example_operators", start_date=datetime(2024, 1, 1), catchup=False) as dag:
 clone_operator = DbtCloneLocalOperator(
 profile_config=profile_config,
 project_dir=DBT_PROJ_DIR,
 task_id="clone",
 dbt_cmd_flags=["--models", "stg_customers", "--state", DBT_ARTIFACT],
 install_deps=True,
 append_env=True,
 )

 clone_operator

**Acceptance criteria**

* [ ] Any developer should be able to run this DAG, so we should not have hard-coded path values
* [ ] The DAG should be parsed without errors
* [ ] The dbt clone command should be run without errors

The DAG parsing is working on the branch: URL

I'm able to run DAG

import os
from datetime import datetime
from pathlib import Path

from airflow import DAG

from cosmos.config import ProfileConfig
from cosmos.operators.local import DbtCloneLocalOperator, DbtRunLocalOperator, DbtSeedLocalOperator

DEFAULT_DBT_ROOT_PATH = Path(__file__).parent / "dbt"
DBT_ROOT_PATH = Path(os.getenv("DBT_ROOT_PATH", DEFAULT_DBT_ROOT_PATH))
DBT_PROJ_DIR = Path("/Users/pankaj/Documents/astro_code/astronomer-cosmos/dev/dags/dbt/jaffle_shop")
DBT_PROFILE_PATH = DBT_PROJ_DIR / "profiles.yml"
DBT_ARTIFACT = DBT_PROJ_DIR / "target"

profile_config = ProfileConfig(
 profile_name="default",
 target_name="dev",
 profiles_yml_filepath=DBT_PROFILE_PATH,
)

with DAG("example_operators", start_date=datetime(2024, 1, 1), catchup=False) as dag:
 seed_operator = DbtSeedLocalOperator(
 profile_config=profile_config,
 project_dir=DBT_PROJ_DIR,
 task_id="seed",
 dbt_cmd_flags=["--select", "raw_customers"],
 install_deps=True,
 append_env=True,
 )

 clone_operator = DbtCloneLocalOperator(
 profile_config=profile_config,
 project_dir=DBT_PROJ_DIR,
 task_id="clone",
 dbt_cmd_flags=["--models", "stg_customers", "--state", DBT_ARTIFACT],
 install_deps=True,
 append_env=True,
 )

 run_operator = DbtRunLocalOperator(
 profile_config=profile_config,
 project_dir=DBT_PROJ_DIR,
 task_id="run",
 dbt_cmd_flags=["--models", "stg_customers"],
 install_deps=True,
 append_env=True,
 )

 seed_operator >> [run_operator, clone_operator]

with `airflow dag test ` command

When triggering it from the Airflow UI, the dagrun gets stuck at

[2025-03-24T19:32:06.783+0530] {local_task_job_runner.py:120} INFO - ::group::Pre task execution logs
[2025-03-24T19:32:06.788+0530] {taskinstance.py:2351} INFO - Dependencies all met for dep_context=non-requeueable deps ti=
[2025-03-24T19:32:06.789+0530] {taskinstance.py:2351} INFO - Dependencies all met for dep_context=requeueable deps ti=
[2025-03-24T19:32:06.790+0530] {taskinstance.py:2592} INFO - Starting attempt 1 of 1
[2025-03-24T19:32:06.793+0530] {taskinstance.py:2615} INFO - Executing on None
[2025-03-24T19:32:06.798+0530] {standard_task_runner.py:131} INFO - Started process 81127 to run task
[2025-03-24T19:32:06.802+0530] {standard_task_runner.py:147} INFO - Running: ['airflow', 'tasks', 'run', 'example_operators', 'seed', 'manual__2025-03-24T14:01:17.808538+00:00_QYRo5rS0', '--raw', '--subdir', '/Users/pankaj/Documents/astro_code/astronomer-cosmos/scripts/airflow3/dags/operator_dag.py', '--cfg-path', '/var/folders/hd/7r9vjkwj4hnfyph52pr_b7lc0000gn/T/tmpraiej989']
[2025-03-24T19:32:06.804+0530] {standard_task_runner.py:148} INFO - Subtask seed
[2025-03-24T19:32:06.822+0530] {task_command.py:442} INFO - Running on host pankajs-macbook-pro.local
[2025-03-24T19:32:06.892+0530] {taskinstance.py:2902} INFO - Exporting env vars: AIRFLOW_CTX_DAG_OWNER='airflow' AIRFLOW_CTX_DAG_ID='example_operators' AIRFLOW_CTX_TASK_ID='seed' AIRFLOW_CTX_TRY_NUMBER='1' AIRFLOW_CTX_DAG_RUN_ID='manual__2025-03-24T14:01:17.808538+00:00_QYRo5rS0'
[2025-03-24T19:32:06.893+0530] {taskinstance.py:690} INFO - ::endgroup::
[2025-03-24T19:32:07.987+0530] {local.py:213} INFO - dbtRunner is available. Using dbtRunner for invoking dbt.
[2025-03-24T19:32:07.988+0530] {local.py:416} INFO - Cloning project to writable temp directory /var/folders/hd/7r9vjkwj4hnfyph52pr_b7lc0000gn/T/tmp0qu0uuky from /Users/pankaj/Documents/astro_code/astronomer-cosmos/dev/dags/dbt/jaffle_shop
[2025-03-24T19:32:07.991+0530] {config.py:356} INFO - Using user-supplied profiles.yml at /Users/pankaj/Documents/astro_code/astronomer-cosmos/dev/dags/dbt/jaffle_shop/profiles.yml
[2025-03-24T19:32:07.993+0530] {runner.py:60} INFO - Trying to run dbtRunner with:
 ['deps', '--project-dir', '/var/folders/hd/7r9vjkwj4hnfyph52pr_b7lc0000gn/T/tmp0qu0uuky', '--profiles-dir', '/Users/pankaj/Documents/astro_code/astronomer-cosmos/dev/dags/dbt/jaffle_shop', '--profile', 'default', '--target', 'dev']
 in /var/folders/hd/7r9vjkwj4hnfyph52pr_b7lc0000gn/T/tmp0qu0uuky
[2025-03-24T19:32:08.053+0530] {logging_mixin.py:212} INFO - 14:02:08 Running with dbt=1.9.3


Question: roachtest: cdc/schemareg failed?

roachtest.cdc/schemareg failed with artifacts on release-22.2 @ 07a53a36601e9ca5fcffcff55f69b43c6dfbf1c1:

test artifacts and logs in: /artifacts/cdc/schemareg/run_1
(test_impl.go:286).Fatal: pq: Use of CHANGEFEED requires an enterprise license. Your evaluation license expired on December 30, 2022. If you're interested in getting a new license, please contact subscriptions@cockroachlabs.com and we can help you out.
(test_impl.go:286).Fatal: cluster.RunE: context canceled

 Parameters: ROACHTEST_cloud=gce
, ROACHTEST_cpu=4
, ROACHTEST_encrypted=false
, ROACHTEST_fs=ext4
, ROACHTEST_localSSD=true
, ROACHTEST_ssd=0

 Help

See: roachtest README

See: How To Investigate \(internal\)

 Same failure on other branches

- #94502 roachtest: cdc/schemareg failed [C-test-failure O-roachtest O-robot T-cdc branch-master release-blocker]
- #94482 roachtest: cdc/schemareg failed [C-test-failure O-roachtest O-robot T-cdc branch-release-22.1 release-blocker]

This test on roachdash | Improve this report!

roachtest: cdc/schemareg failed
roachtest.cdc/schemareg failed with artifacts on release-22.1 @ 000c9624b56b09d5fbd06557c559b2f910142a9c:

The test failed on branch=release-22.1, cloud=gce:
test artifacts and logs in: /artifacts/cdc/schemareg/run_1
 cdc.go:514,cdc.go:883,test_runner.go:883: pq: Use of CHANGEFEED requires an enterprise license. Your evaluation license expired on December 30, 2022. If you're interested in getting a new license, please contact subscriptions@cockroachlabs.com and we can help you out.

 cluster.go:1934,cdc.go:1449,panic.go:1038,test_impl.go:248,cdc.go:514,cdc.go:883,test_runner.go:883: cluster.RunE: context canceled
 (1) attached stack trace
 -- stack trace:
 | main.(*clusterImpl).RunE
 | main/pkg/cmd/roachtest/cluster.go:1951
 | main.(*clusterImpl).Run
 | main/pkg/cmd/roachtest/cluster.go:1932
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.kafkaManager.stop
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:1449
 | runtime.gopanic
 | GOROOT/src/runtime/panic.go:1038
 | main.(*testImpl).Fatal
 | main/pkg/cmd/roachtest/test_impl.go:248
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.runCDCSchemaRegistry
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:514
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.registerCDC.func10
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:883
 | main.(*testRunner).runTest.func2
 | main/pkg/cmd/roachtest/test_runner.go:883
 | runtime.goexit
 | GOROOT/src/runtime/asm_amd64.s:1581
 Wraps: (2) cluster.RunE
 Wraps: (3) context canceled
 Error types: (1) *withstack.withStack (2) *errutil.withPrefix (3) *errors.errorString

 Help

See: roachtest README

See: How To Investigate \(internal\)

/cc @cockroachdb/cdc

This test on roachdash | Improve this report!

Jira issue: CRDB-22922

roachtest.cdc/schemareg failed with artifacts on release-22.1 @ 000c9624b56b09d5fbd06557c559b2f910142a9c:

The test failed on branch=release-22.1, cloud=gce:
test artifacts and logs in: /artifacts/cdc/schemareg/run_1
 cdc.go:514,cdc.go:883,test_runner.go:883: pq: Use of CHANGEFEED requires an enterprise license. Your evaluation license expired on December 30, 2022. If you're interested in getting a new license, please contact subscriptions@cockroachlabs.com and we can help you out.

 cluster.go:1934,cdc.go:1449,panic.go:1038,test_impl.go:248,cdc.go:514,cdc.go:883,test_runner.go:883: cluster.RunE: context canceled
 (1) attached stack trace
 -- stack trace:
 | main.(*clusterImpl).RunE
 | main/pkg/cmd/roachtest/cluster.go:1951
 | main.(*clusterImpl).Run
 | main/pkg/cmd/roachtest/cluster.go:1932
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.kafkaManager.stop
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:1449
 | runtime.gopanic
 | GOROOT/src/runtime/panic.go:1038
 | main.(*testImpl).Fatal
 | main/pkg/cmd/roachtest/test_impl.go:248
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.runCDCSchemaRegistry
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:514
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests.registerCDC.func10
 | github.com/cockroachdb/cockroach/pkg/cmd/roachtest/tests/cdc.go:883
 | main.(*testRunner).runTest.func2
 | main/pkg/cmd/roachtest/test_runner.go:883
 | runtime.goexit
 | GOROOT/src/runtime/asm_amd64.s:1581
 Wraps: (2) cluster.RunE
 Wraps: (3) context canceled
 Error types: (1) *withstack.withStack (2) *errutil.withPrefix (3) *errors.errorString

 Help

See: roachtest README

See: How To Investigate \(internal\)

 Same failure on other branches

- #94502 roachtest: cdc/schemareg failed [C-test-failure O-roachtest O-robot T-cdc branch-master release-blocker]
- #94496 roachtest: cdc/schemareg failed [C-test-failure O-roachtest O-robot T-cdc branch-release-22.2 release-blocker]

This test on roachdash | Improve this report!

roachtest: cdc/schemareg failed
roachtest.cdc/schemareg failed with artifacts on release-22.2 @ 07a53a36601e9ca5fcffcff55f69b43c6dfbf1c1:

test artifacts and logs in: /artifacts/cdc/schemareg/run_1
(test_impl.go:286).Fatal: pq: Use of CHANGEFEED requires an enterprise license. Your evaluation license expired on December 30, 2022. If you're interested in getting a new license, please contact subscriptions@cockroachlabs.com and we can help you out.
(test_impl.go:286).Fatal: cluster.RunE: context canceled

 Parameters: ROACHTEST_cloud=gce
, ROACHTEST_cpu=4
, ROACHTEST_encrypted=false
, ROACHTEST_fs=ext4
, ROACHTEST_localSSD=true
, ROACHTEST_ssd=0

 Help

See: roachtest README

See: How To Investigate \(internal\)

 Same failure on other branches

- #94482 roachtest: cdc/schemareg failed [C-test-failure O-roachtest O-robot T-cdc branch-release-22.1 release-blocker]

/cc @cockroachdb/cdc

This test on roachdash | Improve this report!

Jira issue: CRDB-22936


Question: Default shortcut keys cannot be used.

Wow, thanks! I rarely start `nvim .` myself so I didn't know about it.

But I can reproduce it too, although it happens so fast on my machine that I missed it previously. I'll add a note about this to the docs for now.

I don't know if it's possible to automatically apply this at the correct time with this solution, but at least people can now copy paste this into their configs.

Default shortcut keys cannot be used.
os:ubuntu22.04
yazi version: 25.3.7

Install and configure according to the instructions in the readme.

Can you give an example? What are you trying to do exactly?

Currently yazi.nvim completely overrides keys and they cannot be used in yazi.

Image
After installing the plugin, except for F1 which can be used, none of the other shortcut keys respond at all.

Exactly the same as in the readme file.

lua
---@type LazySpec
{
 "mikavilpas/yazi.nvim",
 event = "VeryLazy",
 dependencies = { "folke/snacks.nvim", lazy = true },
 keys = {
 -- 👇 in this section, choose your own keymappings!
 {
 " -",
 mode = { "n", "v" },
 " Yazi ",
 desc = "Open yazi at the current file",
 },
 {
 -- Open in the current working directory
 " cw",
 " Yazi cwd ",
 desc = "Open the file manager in nvim's working directory",
 },
 {
 " ",
 " Yazi toggle ",
 desc = "Resume the last yazi session",
 },
 },
 ---@type YaziConfig | {}
 opts = {
 -- if you want to open yazi instead of netrw, see below for more info
 open_for_directories = false,
 keymaps = {
 show_help = " ",
 },
 },
 -- 👇 if you use `open_for_directories=true`, this is recommended
 init = function()
 -- More details: URL
 -- vim.g.loaded_netrw = 1
 vim.g.loaded_netrwPlugin = 1
 end,
}

With the same configuration, it is normal on another machine.
I will tinker with it slowly when I have time. Thank you.

@mikavilpas Does this mean keys like Mac OS's `Command` key cannot be used in yazi.nvim? I had noticed it works for yazi outside of nvim

Hmm what I meant was that if yazi.nvim has a binding for e.g. ` `, it will always process that key (in neovim), while keys that do not have a yazi.nbim mapping are sent to Yazi to be processed there.

I think the command key might never be sent on its own, but I don't exactly know how it works. Does it work for you on neovim if you open `:term` and then start Yazi there?

Netrw supression
Looks like
open_for_directories = true
 doesn't supress netrw correctly, somehow

Not sure is it due your plugin or not, but with my decision below all works correct
Netrw-noload doc was a solution

In my case enough
vim.g.loaded_netrwPlugin = 1

If I do readme way, netrw preloads before yazi

lua
return {
 "mikavilpas/yazi.nvim",
 event = "VeryLazy",
 opts = {
 open_for_directories = true,
 },
}

asciicast

But if I add netrw "supression" part into init then all works properly

lua
return {
 "mikavilpas/yazi.nvim",
 init = function()
 -- Block netrw plugin load
 -- vim.g.loaded_netrw = 1
 vim.g.loaded_netrwPlugin = 1
 end,
 event = "VeryLazy",
 opts = {
 open_for_directories = true,
 },
}

asciicast

System settings:
Yazi 25.2.26 (Arch Linux 2025-02-27)
kitty 0.39.1
NVIM v0.10.4

Also, thx for this beautiful plugin:)

I'm a non native speaker myself. I think it's non ambiguous, but I agree it could be worded in a way that's a lot more clear.

I'll try to improve it.

this still does have an issue where opening with nvim . will not make it open the current working directory and instead try to use a bogus filepath

@kaem-e can you open a new issue with a reproduction script ( URL ?

It seems to be working now! Maybe something else from my config influenced this? Or did you change something with the latest update?


Question: Recursively controlling a circuit takes exponential time and memory?

The primary focus of this issue is to decompose an `MCXGate()` using non-exponential number of `CX` gates, without using ancillas, thus fixing URL

Recursively controlling a circuit takes exponential time and memory
### Environment

- **Qiskit version**: 1.0
- **Python version**: 3.12
- **Operating system**: OSX and Linux

### What is happening?

Recursively adding controls to an initial sub-circuit will cause Qiskit to hang, using up ever increasing CPU and memory resources. E.g. the below will never complete, but taking `N=5` or so will.

python

N = 10
sub_qc = QuantumCircuit(1)
sub_qc.x(0)

out = QuantumCircuit(N)
out.compose(sub_qc,range(sub_qc.num_qubits), inplace=True)

for kk in range(N-1):
 sub_qc = sub_qc.control()
 out.compose(sub_qc,range(sub_qc.num_qubits), inplace=True)

### How can we reproduce the issue?

Run above

### What should happen?

It should not take apparently exponential time

### Any suggestions?

_No response_

This is because `control` by default, for historical reasons, performs an eager synthesis of the control operation, so the scaling is fairly naturally super-linear (for arbitrary controlled gates). The solution for the simple representation of the objects is to use the modern form that @alexanderivrii has been getting in place, where controls, inverses and gate powers are represented as modifier tags on the gate, and only realised at synthesis time. In your example, setting `annotated=True` in the `control` call will make this script work in linear time of `N`.

That said, when it actually comes to synthesising the gates through `transpile`, you're still almost certainly going to see the super-linear blow up. Our arbitrary-control syntheses probably aren't the best they can be yet, but I think the general case is still going to scale quite a lot with the number of controls.

Just as an immediate copy-pastable example of the above:

python
from qiskit import QuantumCircuit

N = 100
sub_qc = QuantumCircuit(1)
sub_qc.x(0)

out = QuantumCircuit(N)
out.compose(sub_qc,range(sub_qc.num_qubits), inplace=True)

for kk in range(N-1):
 sub_qc = sub_qc.control(annotated=True)
 out.compose(sub_qc,range(sub_qc.num_qubits), inplace=True)

Fwiw, slightly better form for this would be to do:

python
from qiskit import QuantumCircuit

N = 100
sub_qc = QuantumCircuit(1)
sub_qc.x(0)
sub = sub_qc.to_gate()

out = QuantumCircuit(N)
out.append(sub, range(sub.num_qubits))

for kk in range(N-1):
 sub = sub.control(annotated=True)
 out.append(sub, range(sub.num_qubits))

`compose` is a circuit-inlining method, where a circuit represents a program. A single object in a circuit is a `Gate` (if unitary) or `Instruction` (if not), and that's the base blocking structure of the object and how it's pulled through the transpiler. Using the native block structure like that (rather than inlining things with `compose`) will be / should be better for performance longer term, especially as our things like synthesis of these gate annotations improves, because the tranpsiler will be able to retain the abstract/logical structure of the circuit for more longer, and do operations on large-scale abstract components, rather than a flattened structure caused by over-use of `compose`. `compose` is of course better when you _want_ the structures to be merged / inlined, but I don't think this particular example is one of those.

Ok thanks. I am trying to benchmark various aspects of Qiskit, and this one broke things, where as other frameworks can handle the controlled circuit.

Is there anyway for an user to find out what `annotated=True` does in the control? I cannot seem to find it. Also, if it prevents blow-up, why is it not on by default?

It's not on by default because that would have been a major breaking API change, and we're not confident that it's as well supported through the entire stack as the current form yet. It will become the default once it and its synthesis have matured a little more - I'd imagine changing the default of `control` will be one of the API breaks of Qiskit 2.0.

For example, at the moment, the multiple `control` form of annotated gate isn't merging the controlled modifiers into one, nor do the transpiler passes that synthesise the annotated forms of the gates, so we'll still effectively be doing the same looped calls you were underneath. That's not super hard to fix of course, just an indication of the newness of the feature in Qiskit.

What are you meaning by "any way for a user to find out what it does?"? It's a modifier, so it doesn't really _do_ anything (in the sense of the eager synthesis of `ControlledGate`) does on the spot. How it gets synthesised to actual hardware depends (in theory, not yet in practice) on the basis gates and coupling constraints of the hardware, which isn't defined at the point of creating an abstract circuit, but would happen during compilation.

Yeah, no I answered my own question when I tried to change the basis on the circuit and it just kept running.

It also modifies the circuit drawing, which is not too important, but unexpected.

Continuing with Jake's example, here are a few thoughts on the following synthesis step:

An expression of the form `sub.control(annotated=True) ... .control(annotated=True)` would actually combine all of the control modifiers into a single list, that is create an "annotated operation" whose "base operation" is `sub` and whose modifiers are the list `[ControlModifier(1), ..., ControlModifier(1)]`.

For `N=10`, synthesizing this directly is very slow, but we do have a new transpiler pass `OptimizeAnnotated` in Qiskit 1.0 that canonicalizes the modifiers, that is replaces the list of modifiers by a single control modifier with multiple controls. We are still investigating how to best integrate it into the transpiler flow, so it's now on by default, but one would use this along the following lines:

from qiskit.transpiler.passes import OptimizeAnnotated
basis_gates = ['cx', 'id', 'u']
out = OptimizeAnnotated(basis_gates=basis_gates)(out)

The pass is recursive, descending into the definitions of custom gates, and it needs basis gates and equivalence library to know which definitions to examine and which to skip.

For `N=10`, the optimized circuit `out` is now susceptible to transpilation (i.e. to either `transpile` or to `HighLevelSynthesis`). However the approach still does not scale to much larger values of `N`. If I recall correctly (not too sure about this), our default algorithm for synthesizing multiply-controlled gates without ancilla qubits produces exponentially many gates.

One could do a bit better by replacing the code

sub_qc = QuantumCircuit(1)
sub_qc.x(0)
sub = sub_qc.to_gate()

by

sub = XGate()

in which case the synthesis algorithm would treat the annotated `sub` essentially as a `MCX`-gate, producing half as many gates and somewhat decreasing runtime, but unfortunately the default synthesis algorithm ("McxGrey") for MCX-gates without ancillas still produces exponentially many gates.

Indeed, it seems that the current synthesis algorithms for multi-controlled gates could be improved. See the discussion in #5872

Decompose CnXGate grows exponentially in terms of CX, instead of linear
@anedumla noticed that theorem 5 in URL bounds the amount of CNOTs needed to decompose a SU(2) gate when (n-1)-controlled.

<img width="508" alt="Screenshot 2021-02-18 at 14 38 14" src=" URL

The bound of resulting CNOTs in the decomposition grows linearly with respect to the amount of controlled qubits. However, the decomposition of MCX groups exponentially:

number_of_qubits = []
result = []
boundery = []
for k in range(1, 10):
 n = k+1
 circuit = QuantumCircuit(k+1)
 circuit.append(XGate().control(k), list(range(k+1)))
 unroller = Unroller(basis_gates)
 qc = unroller(circuit)
 number_of_qubits.append(n)
 result.append(qc.count_ops()['cx'])
 boundery.append(28*n-88)

image

### What is the expected enhancement?
A non-ancilla decomposition of `QuantumCircuit.mcx()` should result in a linear amount of CNOTs. URL refers to URL for calculating A-B-C, that can be precomputed.

<img width="615" alt="Screenshot 2021-02-18 at 14 46 00" src=" URL

In it's generic form, Theorem 5 can be applied any multi-controlled-W, where W \in SU(2). Therefore, I assume is can be generalised to fix the example URL by creating a possible decomposition.

How to decompose a gate in SU(2) into A, B, C : URL

From Lemma 4.1., every element of SU(2) can be expressed as
image

Then, from the proof of Lemma 4.3.:
image

For a general unitary, not in SU(2), (i.e X gate) Theorem 4[1] seems to be applicable that gives a CNOT count that scales quadratic. According to the upper bound they give, it's beneficial to use their scheme only when n > 10. (however the bound they give seems not to be tight and i can think it can be improved).

Even ancilla decompositions of `mcx` can be proved (according to section 1 of the appendix A[1]) when:
- `mode=recursion`. Current implementation uses 1 ancilla and has exponential CNOT count. With one ancilla qubit, it can be done with linear cost (16n - 40) (n: total no. of qubits)
- `mode=v-chain-dirty`. Current implementation uses (12k - 22) CNOTs (k: no. of controls). It can be reduced to (8k - 6) that is better for k > 4.

Can i work on this?

[1] URL

I'm cleaning the assignees so it can be back to the pool of available `short projects`.

Sounds good! @mtreinish should a synthesis interface be used for this?

Hi @1ucian0 ,

We have been working on this issue. Instead of using theorem 5 in [ URL this issue motivated us to develop a new decomposition that requires a smaller number of gates for SU(2) multi-controlled gates [ URL PR#8710 is the first step to solve this issue and reduces the number of gates in the MCXRecursive (that now is not recursive).

@AlexisRalli: this issue and all the PRs that link to it above are what I was trying to find when you asked me about them the other day. For others' reference: Alexis had also had some ideas about the generalised MCU constructions (see #9574 for one part, but I think he had more in the works as well), who I then told @alexanderivrii and @ShellyGarion about.

I don't have much to contribute myself to the discussion, just trying to link up all the folks I know about working on this, or things adjacent to this.

Thanks @jakelishman,

We intend to contribute with an n-qubit multi-controlled su(2) decomposition that requires ~16n cx if the gate has one real diagonal and ~20n for any other su2 gate.

Hi everyone,

I am reporting what we have done up until now about this issue.

We found some problems that need a fix concerning multi-controlled gates: multi-controlled rotations grow exponentially #9741; MCXVChain with dirty ancilla not optimal #9740; and MCXRecursive not optimal #9743.

We fixed the MCXVChain with dirty auxiliary qubits #9687 and the MCXRecursive #8710. We also fixed mcry and mcrx #9688. There is a conflict PR about multi-controlled rotations #9574. However, #9688 produces circuits with fewer cx gates because it implements our recent work about su(2) multi-controlled gates.

We did not fix mcrz because the actual implementation of mcrz applies an mcp gate (not su(2)) #9202. I do not know if we should open a PR with a fix to mcrz because this will impact several test cases and other users.

We would also like to contribute to #7505.

@ewinston. PR #9836 fix the mcrz. However it breaks compatibility tests. It is also necessary to include the multiplexer with a small number of control qubits.

@adjs @rafaella-vale - according to your paper [1] and to the function `_mcsu2_real_diagonal`, this function should decompose any multi-controlled SU(2) gate with a real main diagonal or secondary diagonal, hence it should also be able to decompose `mcx` or `mcp` gates.

[1] URL

However, this decomposition does not work properly, since it does not provide the expected operator:

from qiskit.circuit.library.standard_gates import multi_control_rotation_gates as mcrg
for num_controls in range(3, 10, 2):
 qc = mcrg._mcsu2_real_diagonal(XGate().to_matrix(), num_controls, use_basis_gates=True)
 qc1 = QuantumCircuit(num_controls+1)
 qc1.mcx(list(range(num_controls)), num_controls)

 print (np.allclose(Operator(qc).to_matrix(), Operator(qc1).to_matrix() ))
 print (Operator(qc).equiv(Operator(qc1)))

gives `False` and `False`.
It also does not work for `PhaseGate()` and `mcp`.
But the same code seems to work for the pairs: `RXGate()` and `mcrx`, `RYGate()` and `mcry`, `RZGate()` and `mcrz`.

Moreover,

num_controls = 2
qc = mcrg._mcsu2_real_diagonal(XGate().to_matrix(), num_controls, use_basis_gates=True)
(Operator(qc).to_matrix()).round(decimals=0)

produces a wrong matrix for the Toffoli gate (in the last line it should be `1` and not `-1`):

array([[ 1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j],
 [ 0.+0.j, 1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j],
 [ 0.+0.j, 0.+0.j, 1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, -0.-0.j, 0.+0.j],
 [ 0.+0.j, 0.+0.j, 0.+0.j, -0.-0.j, 0.+0.j, 0.+0.j, 0.+0.j, 1.+0.j],
 [ 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j],
 [ 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j, 1.+0.j, 0.+0.j, 0.+0.j],
 [ 0.+0.j, 0.+0.j, 0.-0.j, 0.+0.j, 0.+0.j, 0.+0.j, 1.+0.j, 0.+0.j],
 [ 0.+0.j, 0.+0.j, 0.+0.j, -1.-0.j, 0.+0.j, 0.+0.j, 0.+0.j, 0.+0.j]])

Another synthesis method for MCX gates, if we also allow ancillas, then I think that the best method appears here:
 URL

image
image

Hi @ShellyGarion, in this PR #9687 the mcx requires 8k-6 cnots (and k-2 ancillary qubits) to implement a k-controlled mcx. PR #8710 improves the number of cx gates with one auxiliary qubit (lemma 9 of URL

The approximated multi controlled U(2) without ancillary qubits is implemented in qclib.

pip install qclib

python
import numpy as np
import qiskit
from qiskit.quantum_info import Operator
from qclib.gates.mcu import MCU

tol = 10**-2
n_controls = 11
X = np.array([[0, 1], [1, 0]])
qc = qiskit.QuantumCircuit(n_controls)
MCU.mcu(qc, X, list(range(n_controls-1)), n_controls-1, tol)
tqc = qiskit.transpile(qc, basis_gates=['u', 'cx'])

print('mcu # operations', tqc.count_ops())

qiskit_circuit = qiskit.QuantumCircuit(n_controls)
qiskit_circuit.mcx(list(range(n_controls-1)), n_controls-1)
qiskit_circuit.draw()

t_qiskit_circuit = qiskit.transpile(qiskit_circuit, basis_gates=['u', 'cx'])
print('qiskit # operations', t_qiskit_circuit.count_ops())

qc_matrix = Operator(qc).to_matrix()
qiskit_matrix = Operator(qiskit_circuit).to_matrix()

print(np.allclose(qc_matrix, qiskit_matrix, atol=tol))

will return

mcu # operations OrderedDict([('u', 395), ('cx', 360)])
qiskit # operations OrderedDict([('u', 3070), ('cx', 3068)])
True

Thank you @adjs for referring us to your recent manuscripts [1] and [2]. Would you be interested in contributing the code to Qiskit?

@thiagom123 and @JeffersonDeyvis can you implement approximate multi-controlled gate in qiskit?

I am very happy to finally close this issue as all the PRs mentioned here have finally been merged!
I would like to thank @adjs and everyone who contributed to this enormous effort!
Feel free to open new issues and PRs with further synthesis algorithms for MCX with or without ancilla qubits if you think that they may be better than the current code.


Question: Uncaught TypeError: Cannot read properties of undefined (reading 'hasOwnProperty') Console error thrown while using GTranslate widget and logged into website as admin?

### QA Update: ✅

**Verified:**

- Installed GTranslate chrome extension and WordPress plugin verified the extension works.
- Visited a page on frontend, and the gtranslate extension is translating page.
- Tested gtranslate plugin, you can add shortcode [gtranslate] into any page, and the gtranslate widget shows and translation works.
- Tested with the Google Translate extension as well as GTranslate.
- No console or front end error messages.
- Completed a regression test on the behaviour fixed in URL

 Screenshots

image
image
image
image
image

Uncaught TypeError: Cannot read properties of undefined (reading 'hasOwnProperty') Console error thrown while using GTranslate widget and logged into website as admin
## Bug Description

As flagged in the support forum, the following console error is thrown while using GTranslate plugin widget and logged into website as admin:

Uncaught TypeError: Cannot read properties of undefined (reading 'hasOwnProperty')
 at _._setupNS (/_/translate_http/_/js/k=translate_http.tr.cs.sS79CTwCGSs.O/d=1/rs=AN8SPfooco5r-XPZgZHhoMWywin50i9rzg/m=el_conf:261:314)
 at /_/translate_http/_/js/k=translate_http.tr.cs.sS79CTwCGSs.O/d=1/rs=AN8SPfooco5r-XPZgZHhoMWywin50i9rzg/m=el_conf:287:17
 at /_/translate_http/_/js/k=translate_http.tr.cs.sS79CTwCGSs.O/d=1/rs=AN8SPfooco5r-XPZgZHhoMWywin50i9rzg/m=el_conf:292:11
 at /_/translate_http/_/js/k=translate_http.tr.cs.sS79CTwCGSs.O/d=1/rs=AN8SPfooco5r-XPZgZHhoMWywin50i9rzg/m=el_conf:293:9

I have been able to replicate this on a TasteWP site with just Site Kit and GTranslate installed. This only displayed when logged into the site as admin and viewing a page with the GTranslate widget place on it. When testing from an incognito browser and not logged in the console error does not display. You do not need to interact with the widget for the console error to show as it will display on page load.

Video recording of this in action:

 URL

## Steps to reproduce

1. Set up fresh TasteWP website with Site Kit installed and set up.
2. Install the GTranslate plugin.
3. Go to **Settings > GTranslate** and select an option for **'Show in menu'** and **'Show floating language selector'** so that the widget will display on posts/pages.
4. Visit the site homepage and console error should display.

## Screenshots

## Additional Context

---------------

_Do not alter or remove anything below. The following sections will be managed by moderators only._

## Acceptance criteria

*

## Implementation Brief

*

### Test Coverage

*

## QA Brief

*

## Changelog entry

*

@adamdunnage Weirdly i can reproduce the issue intermittently. First time I tried, I got the error message in the console. Then after a couple of refresh and not doing anything specific that would alter the plugin, the error was not there. Check the screencast below, where I refresh the page, but there are no errors:

 URL

This will require some further investigation @FlicHollis @eclarke1

I've investigated and identified the cause and a potential fix for this issue, which I have captured in the new issue #7121.

Fix console error thrown while using GTranslate widget and logged into website as admin.
## Bug Description

This is a followup to fix the support issue captured in URL

## Steps to reproduce

See the steps to reproduce on URL although note that I had to install an older version of the theme to get the **Show in menu** option to show anything (I switched to the Twenty Twenty-One theme).

## Screenshots

This is the snippet of code provided via GTranslate that throws the error.

image.png

The argument it's invoked with can be seen here:

image.png

And, the contemporaneous state of `window.google` can be seen here:

image.png

## Additional Context

 - PHP Version: any
 - OS: any
 - Browser: any
 - Plugin Version: historical, but verified on 1.101.0
 - Device: any

As can be seen in the screenshots above, the code is throwing an error because it's trying to deeply reference an object on `window.google`, but `window.google` is `undefined`.

It appears that this conflict is occurring as a result of Site Kit's code where it intentionally initializes `window.google` to `undefined`:

 URL

This itself was deliberately introduced as a result of URL so care needs to be taken not to reintroduce a problem with regard to this issue.

Preliminary investigation suggests a fix could be to initialize `window.google` to an empty object, rather that `undefined` - this appears to work both with GTranslate and with Site Kit's own Google Charts. However, this needs to be thoroughly investigated for viability.

---------------

_Do not alter or remove anything below. The following sections will be managed by moderators only._

## Acceptance criteria

* Site Kit should not prevent Google Translate from functioning
* This includes integrations via the official browser extension, and the GTranslate plugin

Note: there are known stability issues with Google Translate related to React crashing due to DOM changes made by Google Translate – this is a separate issue which is out of scope here. This issue is specific to allowing Google Translate to function at all on the page when SK is present/active

## Implementation Brief

* Locate the file at `assets/js/util/initialize-google-global.js`
* Update the value of `global.google` within the condition to be `{}` as opposed to `undefined`
* The final block of code should look as follows:

if ( ! Object.prototype.hasOwnProperty.call( global, 'google' ) ) {
 global.google = {};
}

### Test Coverage
* No additional tests required.

## QA Brief

* Install GTranslate chrome extension and WordPress plugin - URL
* Open dashboard, verify gtranslate extension works
* Open website, and some page on frontend, and verify that gtranslate extension is translating page (working)
* To test gtranslate plugin, you can add shortcode `[gtranslate]` into any page, and verify the gtranslate widget shows on that page and translation works
* It would be also worth giving this a test with the Google Translate extension as well as GTranslate.
* Lastly, it would also be worthwhile doing a regression test on the behaviour fixed in URL as mentioned in the bug description.

## Changelog entry

* Fix console error thrown while using Site Kit in conjunction with Google Translate.

Note: after further investigation, this error also happens with the Google Translate browser extension which is likely more widely used than the GTranslate plugin.

@bethanylang this one is ready to start moving as soon as we have the capacity.

@aaemnnosttv Sure, I can ask someone to pick this up for IB so I can try to get it into the next sprint – will depend on what kind of launch blockers we have from the KMW Bug Bash, though. Thanks!

I've not identified a need for any Test Coverage additions herein, please let me know if anyone is in disagreement with this. Existing tests should fail (unit and/or visual) should the change have any negative side effects.

@10upsimon Can you please add an estimate here? Thanks much!

Hi @10upsimon, thanks for your further investigation on this one.

As discussed on Slack, it does sound likely that the case whereby you manually construct a chart via the JS console is not really representative of a real-world scenario, particularly as you've noted that copying the same code into the page body does not result in an error. That said, if you do have those snippets to hand and can paste them here, I'd be interested to see the code just for a clearer picture of things.

I'm also interested to know if you've verified the proposed fix works when using the Google Translate extension in addition to G Translate, it would be good to have this assurance that it's a general purpose fix.

With regard to your question about testing, I'd agree, this isn't a case that we need to add any additional test coverage for. Our existing tests should provide coverage for general chart rendering, and it's probably not worth adding an E2E test for the integrated case with Google Translate.

@techanvil I can confirm that using the Google Translate Extension is a success as well as using the GTranslate plugin. Both work when the default/fallback value is updated to `{}`;

As for the snippet I was inserting, here it is:

const script = document.createElement('script');
script.src = ' URL
document.body.appendChild( script );

function drawChart() {

 // Create the data table.
 var data = new window.google.visualization.DataTable();
 data.addColumn('string', 'Topping');
 data.addColumn('number', 'Slices');
 data.addRows([
 ['Mushrooms', 3],
 ['Onions', 1],
 ['Olives', 1],
 ['Zucchini', 1],
 ['Pepperoni', 2]
 ]);

 // Set chart options
 var options = {'title':'How Much Pizza I Ate Last Night',
 'width':400,
 'height':300};

 // Instantiate and draw our chart, passing in some options.
 var chart = new window.google.visualization.PieChart(document.getElementById('wpbody'));
 chart.draw(data, options);
 }

script.onload = () => {
 console.log('Script loaded successfuly');
 // Load the Visualization API and the corechart package.
 google.charts.load('current', {'packages':['corechart']});

 // Set a callback to run when the Google Visualization API is loaded.
 google.charts.setOnLoadCallback(drawChart);
};

Here are the console errors that arise (in the SK dashboard) as a result:

<img width="705" alt="image" src=" URL

It is an odd error given that `new` is clearly used in the code, but I also suspect this is somewhat totally disconnected to the SK app and somewhat irrelevant, it was merely an observation while testing.

I've update the issue with estimate of 3, given that the change itself is minimal, as would be the QAB.

Thank you @techanvil , I've updated to state that no additional tests are required, as IMO they do not seem warranted. Handing this over for IBR.

Hey @zutigrm, this looks good and I've merged the PR. I've also added a couple of additional points to the QAB myself, in order to spare a round trip and move this along to the QA column.