Activities of "marble68"

Will do.

I don't know if it helps - I run into this sometimes, especially if I change from modal to no-modal.

When this happens, I let it fail, then manually build, check my error list, and clean up issues.

Then I run it again.

Rinse repeat until it completes.

Sometimes I have custom code referencing a property I'm changing, or something like that.

Right now my process is checkin (or branch) Do the above until migration is happy. Then I move all custom code over. Commit (or merge)

Of note - my local time zone is CST, which is -6 hours offset from UTC, yet it's showing 6 AM. We're in Daylight savings, so currently it's -5 hours.

If it were somehow parsing incorrectly, and getting midnight UTC, you'd think it'd get 7PM or 6PM.

I'll test this further and see where 6:00 AM is coming from.

I did - It is correct, both the IANA and TimeZoneInfo.

Like I said, If I change the formatting to include the date along with it, it shows the correct time (format: 'L LT').

But if I use only LT, the value is incorrect. It's 6:00 AM regardless of what the value in the input field is (I should clarrify - regardless of the input value. I haven't tested this by changing my local timezone.)

In the cshtml, if I formatted the datetime to "t" (putting only the time in the input value) it would show the correct time.

Right now - I'm having to set that value via the above; which is fine - but not expected.

For what it's worth - here's how I'm having to address it:

    $('.date-picker').each(function (i, e) {
        $(e).val(moment($(e)[0].defaultValue).format("HH:mm A"));
    })

Is this the normal way it's handled?

I figured it out, the documentation has a bug in it.

In Main Definition section, it says to inert:

var helloWorld = new WidgetDefinition(
    id:AbpZeroTemplateDashboardCustomizationConsts.Widgets.Tenant.HelloWorld,
    name:"WidgetRecentTenants",//localized string key
    side: MultiTenancySides.Tenant,
    usedWidgetFilters: new List<string>() { helloWorldFilter.Id },// you can use any filter you need
    permissions: tenantWidgetsDefaultPermission);

What is Should say is:

var helloWorld = new WidgetDefinition(
    id:AbpZeroTemplateDashboardCustomizationConsts.Widgets.Tenant.HelloWorld,
    name:"WidgetHelloWorld",//localized string key
    side: MultiTenancySides.Tenant,
    usedWidgetFilters: new List<string>() { helloWorldFilter.Id },// you can use any filter you need
    permissions: tenantWidgetsDefaultPermission);

I think I found a way other than making the permission host only in the auth provider, adding a property to every permission "HostOnlyAssignable", true | false.

Then, I add a permission to host only, for HostOnlyAssign.

Then, in the common controller, when it builds the tree, I remove any permissions from the list that where that property is set so they don't show up in the tree.

In this way, the tenant admin can have permissions to DynamicProperties, but cannot assign that permission to another role - or even remove that permission from themselves.

If I could do this based on edition - that might be the way to go.

What I'm trying to do is hide certain permissions from being assignable by a tenant.

For example, I have several entities the Tenant manages.

Be default, I have static roles that have permissions assigned for the entities.

What I'm trying to do is allow the Tenant admin create a new role, and assign permissions for the entities.

However, when they're assigning roles, I do not want some of the permissions to be visible when the admin is assigning roles. Such as WebHooks.

I don't want the tenant admin to be able to assign them to any other role, so I do not want them visible when editing / creating roles.

I do, however, want the tenant admin to be able to see web hooks permission.

In summary, what I'm trying to do is limit the assignable permissions for the tenant.

I want the tenant admin to only allow to create roles and apply permissions for entities, but be unable to grant all the permisisons under administration, except for things like audit logs, organization units, Subscription.

In effect, what I'm thinking is the answer is to use Properties on permissions.

In the Properties for the permissions, I could assign a custom string that defines a permission I'd create in the AppPermissions (similar to Pages permission structure).

For reference - fix is here ->

https://github.com/aspnetzero/aspnet-zero-core/commit/3f46dddff97d31bf03650acc6836e4b0de4e0a34