Remotely disabling units

[Alexander Obuhovich]

Right now unit configs are automatically discovered in all installed modules.

To prevent In-Portal from discovering units we currently must add "." before unit folder name. However it's not possible with third-party modules, like "in-link".

To solve this problem I'm proposing to create a database table called SystemUnits, where all units will be added, once they are firstly discovered. Then we can create a new section, where units will be managed.

This way if we completely need to get rid of a specific unit in a module, then instead of reverting changes made from it we just disable it in first place and no changes will be made. 

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil]

is this could be a way to lighten In-Portal by disabling unused features?

Envoyé avec Sparrow

[Alexander Obuhovich]

Yes, by disabling at root of unit instead of removing it's presence after it was used.

[Dmitry A.]

Hi Alex,

Yes, this is straight forward idea. It's kind of connected to us building Units Cache and refreshing Unit Configs.

We need to outline how discover process will work since there are multiple scenarios here:

1. SystemUnits table is Empty - rescan and populate automatically - everything is enabled

2. SystemUnits table has Data, but we added new Units - need to rescan and add missing units to table and remove the ones that deleted

What else?

Lets think about what the down sides can be?

DA

[Alexander Obuhovich]

I think, that record for a unit won't be deleted once unit is disabled. This way newly added units will be added to db table as well, but units disabled previously will stay disabled forever. Like with group permissions - they are shown even if no checkboxes are checked for given user group.

[Dmitry A.]

What I wanted to say is that there might be the cases when that table is empty and needs to be updated.

Examples were:

1. SystemUnits table is Empty - rescan and populate automatically - everything is enabled

2. SystemUnits table has Data, but we added new Units - need to rescan and Add missing units to table,  and Remove the ones that deleted (if unit has been removed from the code)

Also, this should be kind of tighten with what we call Module, may be it's more effective to have this as single table or 2 tables where we have Module and Units and they relate of course. It's kind of touches the idea of breaking the Core and other Big modules into smaller ones.

What are your thoughts?

DA

[Alexander Obuhovich]

Both cases (empty table and non-empty table) both at the end result in "add missing units to db table".

We can add ModuleOwner column in SystemUnits table just for reference, like it's done with EmailEvents table.

[Dmitry A.]

Wouldn't it make sense to have single Module and Units section with grid or 2 grids (2 tabs) to manage this?

Similar way if we disable module it will disable all it's Units?

DA

[Alexander Obuhovich]

Ah, you were talking about UI, but I was talking about database.

Anyway database structure stays the same: only 1 new db table: SystemUnits which then will be a sub-table of Modules table, that we already have. And yes we can do module editing with grid proposed by you.

[Dmitry A.]

Hi Alex,

Yes, it's clean with DB stricture while not as clear with UI.

I want it to be the most easy to use and useful as possible for Developer.

So let's decide on UI and what fields (so it's useful) we store as part of new SystemUnits table:

UI

Option A. Have "Modules" and "Units" tabs so you can see/filter through all units across modules if needed.

Option A. Have "Units" tab within Module record - then you limited to see/filter units within 1 module only. 

DB structure - what do you propose to store here?

DA

[Alexander Obuhovich]

UI

I'm for 2nd "Option A" (which probably was planned as "Option B"), like it's done in "E-mail Templates" section. I like it because all units are displayed without a need to open a popup, but if you need a specific module filter, then you can easily enable it.

DB structure

I'm proposing following columns in SystemUnits table, as I've mentioned before:

1. SystemUnitId (int, auto-increment)
2. UnitPrefix - varchar(255)
3. Enabled - tinyint (yes/no)
4. ModuleOwner - varchar(255) - list of modules from Modules table

Maybe we can add "ParentUnitPrefix" column, that would tell which master unit is related to what sub-unit and can't be edited in temporary tables without it. But I'm not sure about it.

[Dmitry A.]

Hi Alex,

UI

Actually it's 1st one - Option A so we RENAME "Module" section to "Modules & Units" and have 2 grids/tabs - Modules and Units. The 2nd one will list all Units across all modules with option to filter by module of course.

Toolbar: Enable, Disable, Delete?

DB:

1. Id (int, auto-increment) - what if we call it just "Id"?
2. UnitPrefix - varchar(255)
3. Enabled - tinyint (yes/no) - may be Status (Active, Disabled and we can add more options in the future if needed) is more appropriate here?

1. ModuleOwner - varchar(255) - list of modules from Modules table

1. ParentUnitPrefix - I think it won't heart since will show the relationship especially important will disabling. It might be a good idea to show/store "dependencies" or something for this?
2. CreatedOn - int (date/time field) will show you when it first added (auto-inserted of course) to the DB/project.

Fields order can change.

Let me know what you think.

DA

[Alexander Obuhovich]

Toolbar: Enable, Disable, Delete?

Delete button won't do much good, since on next unit config cache rebuild unit will be added if it's present on disk (even for disabled module).

Only makes sense to delete units from modules we uninstall, but we don't uninstall modules because we don't have such option in module list.

Id (int, auto-increment) - what if we call it just "Id"?

Don't know about that. We have discussion somewhere about how we better name columns. What was a decision (if any) made there.

Enabled - tinyint (yes/no) - may be Status (Active, Disabled and we can add more options in the future if needed) is more appropriate here?

I thought about Status column, but since all data in this grid is managed from Admin Console, then I don't see any new statuses coming in near future.

CreatedOn - int (date/time field) will show you when it first added (auto-inserted of course) to the DB/project.

Don't see how this can be usable, but it's ok to add.

On Thu, Dec 27, 2012 at 7:14 AM, Dmitry A. <dand...@gmail.com> wrote:

Toolbar: Enable, Disable, Delete?