3.0.0rc3

[michael-s-molina]

Hello Superset Community,

This is a call for the vote to release Apache Superset version 3.0.0.

The release candidate:
https://dist.apache.org/repos/dist/dev/superset/3.0.0rc3/

Git tag for the release:
https://github.com/apache/superset/tree/3.0.0rc3

The Change Log for the release:
https://github.com/apache/superset/blob/3.0.0rc3/CHANGELOG.md

The Updating instructions for the release:
https://github.com/apache/superset/blob/3.0.0rc3/UPDATING.md

Public keys are available at:
https://www.apache.org/dist/superset/KEYS

The vote will be open for at least 72 hours or until the necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thanks,
The Apache Superset Team

---

This discussion was created from the release 3.0.0rc3.

[mautkasaudagar002]

Hi, There is an issue when I upload CSV data into the database. My CSV contains the date as dd-mm-yyyy but when I upload into the database, it stores some dates as mm-dd-yyyy

Contents of CSV FIle:
Date Time,Group,Team
01-08-2023 02:01:00,A,2
02-08-2023 02:01:00,A,2
03-08-2023 02:01:00,A,2
04-08-2023 02:01:00,A,2
05-08-2023 02:01:00,A,2
06-08-2023 02:01:00,B,1
07-08-2023 02:01:00,B,1
08-08-2023 02:01:00,B,1
09-08-2023 02:01:00,B,1
10-08-2023 02:01:00,B,1
11-08-2023 02:01:00,B,3
12-08-2023 02:01:00,B,3
13-08-2023 02:01:00,B,3
14-08-2023 02:01:00,A,4
15-08-2023 02:01:00,C,4
16-08-2023 02:01:00,C,4
17-08-2023 02:01:00,C,4
18-08-2023 02:01:00,C,4
19-08-2023 02:01:00,C,4
20-08-2023 02:01:00,C,4
21-08-2023 02:01:00,C,4

But it stores as
Date Time Group Team
2023-01-08 02:01:00 A 2
2023-02-08 02:01:00 A 2
2023-03-08 02:01:00 A 2
2023-04-08 02:01:00 A 2
2023-05-08 02:01:00 A 2
2023-06-08 02:01:00 B 1
2023-07-08 02:01:00 B 1
2023-08-08 02:01:00 B 1
2023-09-08 02:01:00 B 1
2023-10-08 02:01:00 B 1
2023-11-08 02:01:00 B 3
2023-12-08 02:01:00 B 3
2023-08-13 02:01:00 B 3
2023-08-14 02:01:00 A 4
2023-08-15 02:01:00 C 4
2023-08-16 02:01:00 C 4
2023-08-17 02:01:00 C 4
2023-08-18 02:01:00 C 4
2023-08-19 02:01:00 C 4
2023-08-20 02:01:00 C 4
2023-08-21 02:01:00 C 4

[mautkasaudagar002]

I have created dataset named "test" in http://35.86.112.125:8080/

[michael-s-molina]

Hi @mautkasaudagar002. It will always store date values following a standard format. When visualizing the data you can select the format you want using Timestamp Format or a SQL statement.

[mautkasaudagar002]

Hi, @michael-s-molina Thanks for your kind reply!
The problem is that I had uploaded all data related to the month of August i.e. (08). But superset is storing data as below.
01 August 2023 -----> 08 January 2023
02 August 2023 -----> 08 February 2023
03 August 2023 -----> 08 March 2023
and so on .....til 12 August 2023.

But interestingly, for data onwards 13 August 2023 to 25 August 2023...it is being stored correctly
(HIghlighted in Screenshot: Red-Incorrect entry, Green- Correct entry)

[mautkasaudagar002]

My CSV file is attached for your reference. (DateTime format is DD-MM-YYYY HH:MM:SS)

Book1.csv

[michael-s-molina]

Thanks for the CSV example @mautkasaudagar002. I submitted a fix here.

[jfrag1]

@michael-s-molina Embedded dashboards will not work properly without #25081 included

[michael-s-molina]

Cherry-picked into RC4. Thanks @jfrag1!

[michael-s-molina]

Found a problem while testing SQL Lab: #25111. Assigned it to @justinpark.

[michael-s-molina]

Fix: #25114. Thanks @justinpark!

[john-bodley]

Found a problem when running the migration in #25053 for MySQL databases using the InnoDB storage engine when the innodb_large_prefix is disabled. Added a line item to UPDATING.md in #25115 to inform users of the potential issue.

[alexandercarruthers]

I tested #21255 using the Docker image tag 2c993663331f88720c1c85bfe5f86479fa552060-py310

and the import-directory CLI feature now works :)

[zhaorui2022]

While testing 3.0.0rc3, it seems #24790 still happens.

Another issue we have observed, not sure if it is related to the issue linked above, is that we used to have unixtime timestamp (bigint) converted to timestamp like this in 2.0.0, date_trunc('week', CAST(from_unixtime("col") AS TIMESTAMP)) AS "__timestamp", but after upgraded to 3.0.0rc3, the query becomes date_trunc('week', CAST("col" AS TIMESTAMP)) AS "col" which fails to render the associated chart. I am doing more tests and create a separate issue for this once I have some sample dataset to reproduce the issue.

[michael-s-molina]

Thank you for testing the release and creating the issues @zhaorui2022. As soon as fixes are provided, I can cherry-pick them into a future RC or a patch release.

[zhaorui2022]

Hi, I was able to reproduce the issue and create an issue here #25134

[michael-s-molina]

Thank you @zhaorui2022 for creating the issue.

#25133 fixes #24790 thanks @justinpark!
#25135 fixes #25134 thanks @john-bodley!

[zhaorui2022]

Hi. We have found some of our existing charts running into this issue #25154

[michael-s-molina]

Fix: #25159

[zhaorui2022]

I'm not completely sure if this is expected behavior (breaking change) or a regression, but still filed an issue here #25155

[michael-s-molina]

I think this is expected behavior. You need to enable the ALLOW_ADHOC_SUBQUERY feature flag.

[zhaorui2022]

Hi. We recently discovered another issue that when we add a new database connection, edit a dabase connection, or edit a dataset, it raises an error saying it already exists. My laptop got wiped and reset today, so I don't have a screenshot or recording. If more details is needed, I can file an issue once my dev env is back to normal.

[michael-s-molina]

@zhaorui2022 I was able to do these operations successfully in the test environment. Maybe it's something with your local deployment? If that's not the case, we'll need more details to reproduce the bug.

[zhaorui2022]

Sure. Let me get my dev env set up and try to see if I can reproduce it.

[zhaorui2022]

It seems the database connection issue is caused by a 503 error on the client side (on the server side, with an error like this werkzeug.exceptions.NotFound: 404 Not Found: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. ), although the dataset is still added somehow. I will go through the breaking changes again and see if anything is missing.

Regarding the dataset edit error, I misunderstood the use case. It seems happening when editing a dataset, sync from source where there are column changes, and then fails when trying to save. I can file an issue once I have a screen recording.

[zhaorui2022]

Here it is #25210

[michael-s-molina]

Issue closed 🎉

[qleroy]

I just reported an error for the Handlebars chart related to a Content Security Policy directive error, that I was not experiencing with 2.1.1.

Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'strict-dynamic' 'nonce-7KRSJaEnmAisBJqk_9uAC0RXNd4Gc9NE'".

#25205

[michael-s-molina]

Hi @qleroy. This is a CSP restriction by design. Please check https://superset.apache.org/docs/security/#content-security-policy-csp on how to resolve the issue.

[michael-s-molina]

If you use the Handlebars chart, you'll probably need to disable TALISMAN or extend the default CSP policy to allow all of its features.

[qleroy]

Ok thank you I was not aware of the change 👍

[Alvie]

Did Gamma permissions change? Seems like before I was able to use GUEST_ROLE_NAME = "Gamma" but now that doesn't work because it doesn't have all datasource access? I believe it didn't have this issue in 3.0.0rc1

[michael-s-molina]

Hi @Alvie. I recommend reviewing the CHANGELOG.md file. We had many security fixes related to RBAC and permissions that may have changed access for Gamma users.

[michael-s-molina]

Here's the difference between RC1 and RC3 in terms of PRs.

[michael-s-molina]

Maybe #24789 and #24782 are the sources for the changes.

[Alvie]

Thanks, that's very helpful, I really appreciate your quick response. I took a look at the permissions across the two versions and they are indeed the same. I guess it's more related to the RBAC and I definitely understand the reasons for the change. I'll use a custom role with permissions I set myself from now on 👍🏾

[tristanb222]

Hello,

I have 2 challenges with the version, can you help me?

in the previous version you could change the colors of the labels in the dashboard via the "label_colors" in the JSON metadata. Now it seems that "label_colors" have no effect anymore.

In deck.gl polygon we have included javascript code via "javascript tooltip generator". Now this code doesn't work anymore, error message: "Error: Minified React error #31".

[michael-s-molina]

Hi @tristanb222. Given that this is highly specific to your deployment, I recommend opening a Github issue or discussion and add as much detail as possible so that the community can understand your problem. Add your label_colors configuration that is not working anymore and the tooltip generator code with the associated stacktrace. The #debug-together Slack channel is a great place to ask this question too.

[michael-s-molina]

Closing this as 3.0.0rc4 is out.