some additional things

[croin]

Hello, have you considered the following possibilities?

1. Being able to generate the report offline, for later uploads to the server, for certain devices that are not connected to the network for some reason.
2. Being able to detect some network devices via SNMP.
3. Perhaps being able to save some metadata so that it is not lost when deleting a device for some reason. This would be useful, for example, if I need that same data in case a certain device needs to be deleted, either because it was duplicated or needs to be moved to another device. I think different needs may arise. For example, in my case, I added the owner's name, ID, equipment assignment certificate, etc.
   4)In the computer section, you can generate other filters, such as by type of equipment, among others.

[doncicuto]

Hi @croin, thanks for sharing your ideas, let's discuss them

1. The agent is now generating the report every 60 minutes by default. This report frequency can be changed globally. As soon as a machine that recovers connectivity or is booted up, it'll sent the report when the report window reaches. Have you experienced a situation where the agent is not acting like this, or are you thinking in a different way or scenario?
2. Yes, absolutely. A openuem-snmp worker will be used for that. My first SNMP integration will be with network printers. I want admins to be able to add connections with network printers so we can have information about toner usage for example, but generally I want admins to be able to discover or add network devices with SNMP v2/3. I'd need your help to check if openuem-snmp work fine using a CLI tool as a proof of concept.
3. The metadata management is pretty basic, but sure, we can think about a way to improve it. Things that could be added:

• We could have a button to copy the metadata of a computer to another
• About not deleting metadata when a device is deleted, I've to think about it as I should change database relations and look for a good place to show them in the console (maybe a history section?)

4. Filtering must be improved too. I must think a good UI for having more filters other than those in the table's columns. If you have a good UI filtering example for another app that I can use, I'll glad to try to add it.

I really like your ideas, let's keep the discussion to add more details and I'll create the issues then

[croin]

Thanks for your attention @doncicuto, I'll proceed to answer:

1. In my particular case, it's a computer that won't be connected to a network for the time being, so it won't be contacting the server for the time being, but it would be interesting to have that device listed in the inventory. That's why I mentioned whether it would be possible to "import" data OFFLINE at some point.

2. Sure, count me in to run the respective tests ;)

3. Both ideas are useful; one is more functional than the other ;)

4. I'll check it out and let you know.

Thanks again.

[wallabarizon-hue]

Suggestion for OpenUEM Improvements

One valuable feature inspired by other enterprise systems (usually paid) would be the creation of an internal app store within OpenUEM.
This internal store would allow end users to install or uninstall approved applications directly, without IT assistance.
Administrators could upload and manage company-approved software, ensuring compliance and security.
This feature could initially focus on Windows devices, with potential expansion to other platforms later.

Another great addition would be a “Wipe Data” or “Disk Cleanup” function, allowing automated or on-demand temporary file cleanup (e.g., Temp folders) on local disks.
It could also include disk usage monitoring and alerts, notifying administrators when storage is running low — whether on virtual machines or physical desktops/laptops.

[wallabarizon-hue]

Below is the complete translation into English, keeping the structure, clarity, and terminology exactly as in your original text.

💡💡💡

Understood.
You want an internal application store that appears directly in Windows for the user, where:

The user logged into the PC opens the store → sees only the IT-approved software → installs/uninstalls by themselves.

In OpenUEM, administrators approve, publish, and control which applications will appear in the internal store on user computers.

Below is the ideal architecture, followed by three different ways to deploy this internal store, all 100% compatible with OpenUEM.

---

🎯 FINAL GOAL — How it needs to work

On the user’s Windows PC

Icon: “📦 Company Application Store”

Interface similar to Microsoft Store / Company Portal

Catalog filtered by permissions

User clicks → installs/uninstalls without needing administrator rights

Execution and logs controlled by the OpenUEM agent

In OpenUEM

IT imports packages (Chocolatey/MSI/EXE)

IT approves and publishes into the catalog

IT defines which AD groups can see each app

OpenUEM generates the dynamic catalog for the Windows client

This is fully possible using open-source tools and the OpenUEM API.

---

🧩 IDEAL ARCHITECTURE (OPEN-SOURCE + WINDOWS + OPENUEM)

WINDOWS USER
↓
Internal Store (GUI)
↓
OpenUEM Agent
↓
Chocolatey / Silent Scripts
↓
Internal Repository (Nexus/Raw)
↓
OpenUEM (Approval / Catalog / Policies)

---

⭐ THREE WAYS TO IMPLEMENT THE INTERNAL STORE
(from simplest to most advanced)

---

🔵 OPTION 1 — Simple and Fast

✔️ “Chocolatey GUI + Internal Repository + OpenUEM as orchestrator”

How it works

The user opens Chocolatey GUI (visual store, open-source).

They see only the packages that OpenUEM allows.

When clicking install/remove → Chocolatey executes the silent installer.

OpenUEM records everything.

How administrators approve software in OpenUEM

1. IT creates a .nupkg package

2. Uploads it to Nexus/Artifactory

3. In OpenUEM:

“Add Software”

Provide package → create metadata

Mark as Approved

Publish to AD groups

How the store appears in Windows

Create a shortcut named “Company Internal Store”

Chocolatey GUI lists only the internal repository

User clicks and installs

Pros

Very quick to implement

Ready-to-use interface

Pure open-source

Zero development required

Cons

Limited interface (not fully customizable)

Does not display polished icons by default (can be customized)

---

🟣 OPTION 2 — Internal Store inside OpenUEM

✔️ “OpenUEM Web Portal → Windows Agent → Chocolatey/Script”

How it works

User opens the OpenUEM Portal → “Internal Store”

Modern interface (React/Bootstrap)

App list based on group/permission

Buttons: Install, Uninstall, Update

Commands are sent to the PC via the OpenUEM agent

On Windows

The logged-in user gets:

Desktop icon “Company Applications”

Opens a web browser → internal OpenUEM store

Fully authenticated through AD/SSO

How administrators approve

In the OpenUEM panel:

1. IT uploads or links a package from the repository

2. Adds description, icons, category

3. Defines AD group visibility

4. Marks: “Show in Internal Store”

5. Publishes

Pros

Full corporate experience

No external interfaces needed

Completely controlled by IT

Catalog filtered by policy

Cons

Requires installing an add-on or module in OpenUEM

More configuration needed

---

🟢 OPTION 3 — Native Windows Application Store

✔️ “Windows UWP/WinUI/React Native App + OpenUEM API”

How it works

A dedicated Windows application, with a Store-like interface:

Shows approved apps via the OpenUEM API

User clicks → app triggers the OpenUEM agent → installs/uninstalls

IT controls everything via OpenUEM

Recommended stack

UX: WinUI 3 or Electron (open-source)

Backend: OpenUEM API + Nexus repository

Installation engine: Chocolatey/Silent scripts

Pros

Best user experience

Fully customizable

Icons, screenshots, categories, search

Cons

Requires development

More maintenance

---

📦 COMPLETE SOFTWARE LIFECYCLE IN THE INTERNAL STORE

---

1. Import (IT)

IT downloads the original installer

Packages it as .nupkg or silent .msi

Uploads to Nexus / Artifactory

---

2. Approval (IT in OpenUEM)

Tests the software in a staging environment

Validates silent install and uninstall

Registers in OpenUEM: name, version, icon, category

Marks “Approved for Internal Store”

---

3. Publication (IT in OpenUEM)

Defines AD groups

Example: “Finance can install Office”

Defines permissions:

Install

Uninstall

Update

Enables: “Show in Windows Internal Store”

---

4. User Availability (Windows)

Depending on the chosen model:

Option 1 (Chocolatey GUI)

User opens “Application Store”

Sees allowed apps

Clicks → installs

Option 2 (OpenUEM Portal)

Desktop icon

Opens web portal

Sees allowed apps

Clicks → installs

Option 3 (Windows App)

Native app with Store-like layout

Executes via API

---

5. Audit and Logs (OpenUEM)

OpenUEM shows:

Who installed

When installed

Installed version

Failures

Uninstall history

Per-machine history

Everything is visible in the OpenUEM dashboard.

---

🧱 REQUIRED COMPONENTS (LICENSE-FREE)

Component Function Open-source?

Nexus OSS Package repository ✔️
Chocolatey (community) Windows installer ✔️
Chocolatey GUI User interface ✔️
OpenUEM Management and approval ✔️
WinUI/Electron (optional) Native store UI ✔️

---

If you want, I can also:
✅ Generate full documentation
✅ Create architecture diagrams
✅ Provide a step-by-step deployment guide
✅ Prepare a ready-to-run Docker/VM lab for testing