Privacy and retention notice

Who is responsible

Data controller

Politechnika Poznańska

Controller contact

ul. Jacka Rychlewskiego 1, 61-131 Poznań, biuro.rektora@put.poznan.pl, tel. +48 61 665 36 39

Data protection contact

Piotr Otomański, iod@put.poznan.pl, tel. +48 61 665 36 31

Purposes and legal information

EUNIConnect processes account and profile data to authenticate eligible institutional users; community, workshop, chat and news data to provide collaboration features; notification and email data to communicate requested events; and security, rate-limit, audit, log and backup data to protect and operate the service.

Legal basis

art. 6 ust. 1 lit. e RODO w związku z art. 11 ust. 1 ustawy Prawo o szkolnictwie wyższym i nauce – realizacja zadań uczelni w interesie publicznym w zakresie kształcenia, działalności naukowej i współpracy akademickiej; art. 6 ust. 1 lit. f RODO – zapewnienie bezpieczeństwa usługi, zapobieganie nadużyciom oraz ustalanie, dochodzenie i obrona roszczeń

Recipients or recipient categories

upoważnieni pracownicy i współpracownicy Politechniki Poznańskiej; uprawnieni użytkownicy EUNIConnect oraz partnerzy EUNICE w zakresie wynikającym z funkcji współpracy; podmioty świadczące usługi hostingu, poczty elektronicznej, utrzymania i bezpieczeństwa IT na podstawie umów powierzenia; organy uprawnione na podstawie przepisów prawa

International transfers

Dane nie są przekazywane poza Europejski Obszar Gospodarczy (EOG). W przypadku uruchomienia dostawcy spoza EOG transfer nastąpi wyłącznie zgodnie z rozdziałem V RODO i po aktualizacji niniejszej informacji.

Data collected and its source

Most information is supplied directly by you. Membership decisions and administrative changes are supplied by supervisors or administrators. Timestamps, delivery states, security counters and access logs are generated when the service is used.

• Accounts and profiles: username, institutional email address, password hash, name, university, department, spoken languages, selected avatar colour, account and permission state, and email-verification timestamp.
• Registration is currently limited to institutional email addresses in these configured domains: b-tu.de, go.uop.gr, kau.se, put.poznan.pl, sc.ipv.pt, umons.ac.be, unican.es, unict.it, uphf.fr, uwasa.fi.
• Registration and recovery: a staged username and email address, a password-hashed one-time-code verifier, attempt and sending counters, and temporary email-delivery records. The application does not store a pending registration password.
• Communities: Community of Practice and group membership, activities, join time, optional join reason, requests, roles, supervision, descriptions, rules and activity or community proposals.
• Workshops: creator, organiser, participants, proposed dates, votes, scope, description, schedule, capacity, phase and joining or meeting information.
• Chat: message content, sender, time, selected language, any stored translation values and a request identifier used to prevent duplicate messages.
• Local news: author display value, title, text, audience, publication time, an optional related HTTPS link and the publisher's latest-day anti-abuse counter.
• Official EUNICE news: public RSS entries fetched by the server from allow-listed EUNICE feeds. The application does not send your account or profile to those feeds.
• Notifications and email outbox: recipient, category, message context, delivery state, retry state and the application event needed to produce the message.
• Feedback and bug reports: title, description, submitting account and submission time.
• Operations and security: server-side sessions, short-lived rate-limit keys based on account or IP address, administrative audit events, and access logs containing IP address, time, HTTP method, path without query parameters, response status, response size and User-Agent.

Who can see information inside EUNIConnect

• There is no public profile directory. Your own profile page is available only after sign-in.
• Approved members of the same active group can see the group's member directory, including member name, institutional email address, university, department, languages and group activities. Supervisors and application administrators can see the information needed to manage membership and proposals.
• Group and Community of Practice content is restricted to the corresponding approved audience. Items labelled public in the application are visible to authenticated EUNIConnect users, not published on the anonymous welcome page.
• Workshop joining information is limited to authorised participants, organisers and administrators according to the workshop state and audience.
• The current deployment does not broadcast public workshop announcements by email to every EUNIConnect account.
• Email is delivered through the configured institutional mail service. Opening a meeting link, local-news link or official EUNICE article takes you to an external service, which receives the normal technical data associated with a browser request and applies its own privacy information.

Cookies, live connections and cache data

• EUNIConnect uses an essential, server-side session cookie. A session ends when the browser closes and is valid for no longer than 12 hours. Expired server-side session records are removed daily.
• An essential CSRF cookie protects forms against cross-site request forgery, and a short-lived signed cookie may carry confirmation messages between pages. Your light or dark theme choice is stored only in your browser's local storage. The application does not configure advertising, analytics or social-media tracking cookies.
• Authenticated WebSocket connections used by chat and workshop updates are bound to the same live server-side session and access checks.
• Official EUNICE RSS results use a shared fresh cache for 15 minutes. If an upstream source fails, its last successful copy may be used for up to 48 hours.
• Rate-limit cache entries are temporary operational counters. They are used to prevent abusive login, password, publication, chat and WebSocket activity and expire with their configured rate window.

Retention implemented by the application

• Feedback and bug reports are deleted after 365 days.
• In-application notifications and their per-recipient read state are deleted after one calendar year.
• Sent or permanently failed email outbox records are deleted after 30 days. Pending or actively retried records remain until delivery reaches a terminal state; superseded security codes are removed from their message context.
• Email-verification and password-reset codes expire after 15 minutes and lock after five failed attempts. Code and unfinished-registration records are periodically removed after both code validity and the 24-hour anti-abuse sending window have ended.
• Cancelling a group join request leaves only retry-cooldown metadata for 15 minutes. A daily cleanup removes it after the cooldown has ended.
• The COP news publication quota retains one latest-day counter per publisher. The same row is reset on the next publication day, so it does not create a daily history.
• Workshop, participation, vote, membership and local-news records remain while their related collaboration records exist. Completed workshops remain available in the organiser's archive. Removing a parent group, Community of Practice, workshop or news item can remove its dependent records.
• Chat history has no automatic time-based deletion. This is an explicit product decision so the collaboration history remains available. A sender can delete an individual message, and access ends when the relevant approved membership ends.
• Administrative audit records have no automatic application-level expiry. They are immutable in normal application use and may retain bounded username or target snapshots needed to explain security-sensitive changes.
• Routine compressed database backups are configured for 30 days and exclude live Django session contents. A safety backup made immediately before a database restore is deliberately excluded from automatic deletion and requires an operator-reviewed removal after the restored service is accepted.
• Container and proxy logs use bounded size-and-file-count rotation rather than a fixed number of days. Proxy access logs deliberately omit query strings and Referer values.

Account anonymisation

Application account removal is implemented as irreversible access revocation and anonymisation rather than deletion of every related database row. The username, email address, password capability and profile fields are removed or replaced; active sessions, verification codes, permissions, pending proposals and private delivery data are revoked or cleared.

Collaboration history that other users rely on, such as approved membership, workshops, votes, chat and published news, may remain under a deleted-user identity. Attributable notification and email display-name snapshots are redacted where the application stores a reliable actor reference. Administrative audit evidence and backups can retain limited historical identifiers for the periods described above.

Automated processing

Activity matching can recommend groups from activities you select. Eligibility checks, duplicate prevention and anti-abuse limits can automatically accept or reject a technical request. Community proposals, membership decisions and administrative actions remain subject to human decisions; the application does not make solely automated decisions intended to produce legal or similarly significant effects.