Syrius Improvements

CryptoFish · January 19, 2023, 8:20am

As discussed with @sol in Discord.

The ‘My projects’ filter tag, filters on all user addresses, but as a non-pillar owner the result set gets filtert down in the _filterProjectsAccordingToPillarInfo function to all active projects or projects owned by the selected address.

github.com

zenon-network/syrius/blob/9a394eb7a0f21306e90a2dea86f33276d58f874f/lib/blocs/accelerator/project_list_bloc.dart#L159


      
          Future<List<Project>> _filterProjectsAccordingToPillarInfo(
              Set<Project> projectList) async {
            bool isPillarAddress = pillarInfo != null;
            if (isPillarAddress) {
              return projectList.toList();
            } else {
              List<Project> activeProjects = projectList
                  .where(
                    (project) =>
                        project.status == AcceleratorProjectStatus.active ||
                        project.owner.toString() == kSelectedAddress,
                  )
                  .toList();
              if (activeProjects.isNotEmpty) {
                return activeProjects;
              } else {
                throw 'No active projects';
              }
            }
          }

A non-pillar user has to switch the selected address to see its own projects on another address. While a pillar user sees its own projects on all addresses.

For example:
User A has 3 addresses
Address 1 has a pillar registration and 3 projects
Address 2 has 1 project
Address 3 has 1 project

When address 1 is selected, the user sees all 5 projects when activating the ‘My projects’ filter tag.
When address 2 or 3 is selected, the user only sees project 1 when activating the ‘My projects’ filter tag.

So when address 1 is selected the user is considerd a pillar user, otherwise a non-pillar user.

With the following change the situation would be equal to that of a pillar user and the user would not have to change the selected address to see all his owned projects.

kDefaultAddressList.contains(project.owner.toString())

So far I’ve not been able to detect any side-effects.

0x3639 · January 19, 2023, 10:04am

this seems like a good improvement.

sol · January 20, 2023, 12:30am

I forgot about this

Unfortunately, they don’t support native ZNN. We could revisit this when the multi-chain bridge is deployed.

I’ve updated the Mattermost board with most of the remaining tasks from the original post.
Please continue providing feedback so we can add it to the funnel.

DrD3 · January 21, 2023, 5:15pm

I believe @angelo_a_jr returned most of the ZNN received back to AZ. If you guys are planning on reviving Dework for paying bounties then @SugoiBTC and Angelo might have to submit another proposal on AZ.

https://forum2.zenon.org/t/proposal-rapid-bounty-deployment-discovery-on-dework-wznn-multisig/640/9?u=drd3

aliencoder · January 22, 2023, 10:51am

I can merge it right away if eveyone is OK with the fix.

I’ll wait for more feedback for this one: Fix fusing address reset #13 .

CryptoFish · January 22, 2023, 6:40pm

I’ll need to complete some extra tests on the cicd branch to be sure. Will let you know when they’re ready.

CryptoFish · January 23, 2023, 11:30am

Fully tested PR 13 and PR 14 on the cicd branch. Could not find any problems. However, we do need to make a design decission on PR 14. See PR for more info.

github.com/alienc0der/syrius

Feature AZ filter on all addresses

alienc0der:cicd ← KingGorrin:az-projects-filter

opened 01:23PM - 19 Jan 23 UTC

KingGorrin

+3 -3

# Problem A non-pillar user has to switch the selected address to see project…s on another address. While a pillar user sees all projects for all addresses. ## Example An user with 3 addresses Address 1 has a pillar registration and 3 projects Address 2 has 1 project Address 3 has 1 project - When address 1 is selected, the user sees all 5 projects when activating the 'My projects' filter tag. - When address 2 or 3 is selected, the user only sees project 1 when activating the 'My projects' filter tag. # Cause When address 1 is selected the user is considerd a pillar user, otherwise a non-pillar user. The 'My projects' filter tag, filters on all user addresses, but as a non-pillar owner the result set gets filtert down in the `_filterProjectsAccordingToPillarInfo` function to all active projects or projects owned by the selected address. # Solution With the following change the situation would be equal to that of a pillar user and the user would not have to change the selected address to see all his owned projects.

aliencoder · January 23, 2023, 9:07pm

The "create phase" will only be visible when the address of the project owner is selected.

I think this is a good approach, as you must know in advance where you’ll receive the funds for your project.

Waiting for more feedback, but I think we’re good. PR #13 is already merged.

aliencoder · January 28, 2023, 8:49pm

I’ve patched a potential problem with getting the chainId from a remote node.

I’ve also added some git info (branchName and git commitHash) for Syrius in order to be easier for users to verify this information directly from Info Tab → About Card.

aliencoder · January 28, 2023, 8:53pm

We are approaching v0.0.6 release candidate for Syrius.

Next week the community will be able to test the wallet before submitting the Pull Request to integrate all the changes into the official repository.

0x3639 · January 28, 2023, 10:44pm

Atomic Swaps and Wallet Connect in v0.0.7? Is anything else getting pushed to the next release?

Look forward to testing everything.

aliencoder · January 29, 2023, 10:41am

Thank you! Testing is very important during early stage development and maybe in the future we’ll start integrating an automatic testing framework.

Now let’s focus on delivering v0.0.6 that’s around the corner and has a ton of improvements already and then we’ll start working on v0.0.7.

vilkris · January 29, 2023, 8:50pm

Are you planning on submitting one big PR or will there be multiple PRs in smaller self-contained chunks?

aliencoder · January 30, 2023, 9:19am

A big PR containing all the changes.

aliencoder · January 30, 2023, 9:56am

Merged material-3 branch into cicd.

Flutter Material 3 / Material You

Demo Material 3

vilkris · January 30, 2023, 10:10am

Maybe I missed something but why only one big PR? Why not self-contained PRs of bugfixes and new features to make reviewing and discussion easier? There’s a lot of new code and changes in your branch and I’m worried it will be hard to review if everything is in one PR.

aliencoder · January 30, 2023, 12:57pm

When the branch is fully tested and we’re approaching the release of v0.0.6 we’ll decide on how to submit the pull request(s).

vilkris · January 30, 2023, 2:09pm

Why not submit separate PRs for features/bugfixes as they get finished? More time to review and discuss before the deadline.
A single PR with thousands of lines of code changes related to different features is hard to effectively review, so I’m not sure I agree with the approach to make large PRs containing a full release.

aliencoder · January 30, 2023, 2:58pm

I agree, but let’s see how we can do it efficiently.

sol · January 30, 2023, 3:30pm

The community should be given every opportunity to analyse individual code proposals, test, provide feedback, and consent to specific changes.
Some community members won’t compile code so the proposals should include a visual component, like a screenshot, or a description if applicable.

Having a massive PR is not conducive to this approach. It’s difficult to see what code/commits are specific to which features/bugfixes, reducing the community’s ability to veto certain proposals.

It’s one thing to combine all prospective code changes into a repo for testing, but I think we should break out the individual fixes and features into smaller PRs in order to be more surgical about what gets merged.

Once the community is satisfied with what’s been merged, we can have a small PR to increment version numbers.