Prazo do Questionário Moodle 5.3: Entrega x Fechamento

O prazo do questionário Moodle ganhou uma terceira data no Moodle 5.3 LTS, lançado em 5 de outubro de 2026: além de abertura e fechamento, agora existe a data de entrega (due date). Neste guia eu explico a diferença entre entregar e fechar, como configurar, o que o professor, o aluno e o calendário passam a ver, e como aplicar isso nos cursos que você já tinha antes do upgrade.

TL;DR

• A data de entrega não bloqueia o questionário. Depois dela, o aluno ainda tenta, mas a tentativa aparece como atrasada (overdue). Quem bloqueia continua sendo a data de fechamento.
• Regra de validação: a entrega tem de ficar depois da abertura e antes ou igual ao fechamento, inclusive nas exceções por usuário e por grupo.
• Depois do upgrade, todo questionário antigo fica sem data de entrega (o campo nasce com valor 0). Nada muda no prazo do questionário Moodle antigo até alguém configurar.
• A entrega vira evento no calendário ("… is due"), aparece na Linha do tempo e na página do curso.
• Não use a entrega como prazo final de prova. Para prova, o prazo real continua sendo o fechamento.

O que mudou no prazo do questionário Moodle 5.3

Até o Moodle 5.2, o questionário tinha só duas datas na seção Tempo: Abrir o questionário e Encerrar o questionário. Quem queria "prazo com tolerância" tinha duas saídas ruins: deixar o fechamento lá na frente e avisar a turma por mensagem, ou fechar no dia certo e passar a semana criando exceções para quem pediu mais tempo.

O Moodle 5.3 resolveu isso com a melhoria MDL-82521, listada nas notas de versão oficiais. A documentação de configurações do questionário no 5.3 resume em uma frase: a data de entrega funciona do mesmo jeito que já funcionava na Tarefa. O aluno continua conseguindo tentar depois dela, mas a tentativa é marcada como atrasada em vez de bloqueada.

Eu li o código da versão estável para confirmar o que a documentação promete, porque é ele que decide o comportamento no seu servidor. O texto de ajuda do campo, no pacote de idioma do questionário, diz literalmente: "This is when the quiz is due. Attempts will still be allowed after this date." Ou seja, a data de entrega serve para sinalizar e organizar. Quem bloqueia é o fechamento.

As três datas lado a lado

Data	Campo no código	O que faz	Bloqueia o aluno?
Abrir o questionário	timeopen	Antes dela o questionário fica indisponível	Sim, antes da data
Data de entrega (novo)	duedate	Marca tentativas depois dela como atrasadas	Não
Encerrar o questionário	timeclose	Depois dela não se inicia nova tentativa	Sim, depois da data

Uma confusão comum aqui: o Moodle já usava a palavra "overdue" para a tentativa cronometrada que estourou o tempo limite (aquela que entra em período de tolerância). Isso continua existindo e é outra coisa. Uma trata do relógio da tentativa; a outra, do calendário da atividade.

Data de entrega ou fechamento: qual define o prazo do questionário Moodle

A pergunta que mais ouço de coordenador pedagógico é: "então qual é o prazo de verdade?". A resposta depende do que você quer comunicar ao aluno.

A data de entrega é o prazo combinado. No novo prazo do questionário Moodle ela é a referência pedagógica. É a data que aparece com destaque para o aluno, no calendário e na Linha do tempo. É o dia em que você espera a atividade feita.

A data de fechamento é o prazo técnico. É o limite depois do qual o sistema não deixa começar nova tentativa. A documentação lembra um detalhe que pega muita gente: respostas enviadas depois do fechamento são salvas, mas não recebem nota.

Na prática, o prazo do questionário Moodle passa a ter dois níveis, e isso abre três desenhos possíveis:

1. Só fechamento (como antes). Prova com hora marcada, simulado, avaliação que vale nota cheia. Aqui não faz sentido ter data de entrega.
2. Entrega + fechamento com folga. Exercício semanal com entrega na sexta e fechamento no domingo. Quem faz no fim de semana entra, mas fica marcado como atrasado, e o professor vê isso.
3. Entrega sem fechamento. Atividade de revisão que pode ser feita a qualquer momento, mas tem uma data recomendada. O curso fica organizado na Linha do tempo sem cortar ninguém.

Quando NÃO usar a data de entrega

• Em prova com regra de edital ou regimento. Se o regulamento diz "prova até 23h59", o que vale é o fechamento. Uma entrega que não bloqueia só confunde quem lê.
• Para dar desconto automático na nota. No código que conferi, a data de entrega do questionário sinaliza o atraso; não encontrei desconto de nota ligado a ela. Se a sua política prevê penalidade, isso continua manual ou depende de configuração separada.
• Quando você não comunica a regra. O aluno que vê "atrasado" e percebe que ainda consegue fazer vai perguntar se vale nota. Escreva a regra na descrição da atividade.

Como configurar a data de entrega passo a passo

Configurar o prazo do questionário Moodle leva menos de um minuto por atividade. O caminho é o mesmo das outras datas: Questionário > Configurações > Tempo. A data de entrega aparece entre a abertura e o fechamento.

1. Abra o questionário e entre em Configurações.
2. Expanda a seção Tempo.
3. Marque Habilitar em Data de entrega (Due date) e escolha dia e hora.
4. Confira a abertura e o fechamento. A entrega tem de ficar depois da abertura e no máximo igual ao fechamento.
5. Salve. Se a data estiver fora da faixa, o Moodle recusa com uma mensagem de validação ("The due date must be after the open date" ou "The due date must be before the close date").

Repare numa assimetria da regra, que está no próprio formulário: entrega igual ao fechamento é aceita; entrega igual à abertura, não. A comparação com a abertura é estrita.

Exceções por usuário e por grupo

Aqui mora o ganho maior para quem cuida do prazo do questionário Moodle de turmas grandes. As substituições (overrides) de usuário e de grupo agora aceitam data de entrega própria, com a mesma validação. Dois comportamentos que vale saber antes de mexer:

• Exceção de usuário vence a de grupo. Se o aluno tem exceção individual, as de grupo não valem para ele naquela configuração.
• Aluno em vários grupos fica com a entrega mais tardia. O código pega a maior data entre os grupos. E se algum dos grupos estiver configurado "sem data de entrega", o aluno fica sem data de entrega.

Esse segundo ponto muda o prazo do questionário Moodle de alunos que você nem lembrava que estavam em dois grupos, e gera relatório estranho em curso com muitos grupos sobrepostos. Antes de criar exceções em massa, eu reviso quem está em mais de um grupo.

O que muda para professor, aluno e calendário

Para o aluno

O aluno passa a ver "Due:" junto das datas na página da atividade e no curso. Quando a data passa, aparece a sinalização de questionário atrasado (Quiz is overdue), que também chega à Linha do tempo. No 5.3, a Linha do tempo foi o primeiro componente a migrar para o novo framework em React, segundo a página de novidades do Moodle 5.3. Vale olhar como ela ficou no seu tema antes de soltar a novidade para a turma.

Para o professor

O professor ganha uma terceira data para planejar e a sinalização de atraso na página da atividade. A documentação também cita que as datas de entrega aparecem nas notificações de questionário que abre em breve. O que não muda: a correção, os relatórios de notas e o comportamento do tempo limite continuam iguais.

Para o calendário

É no calendário que o prazo do questionário Moodle fica visível para quem não entra no curso todo dia. Cada questionário com data de entrega gera um evento próprio no calendário, com o nome "[questionário] is due" (traduzido no pacote de idioma do seu site). As exceções criam eventos separados só quando a data difere da padrão do questionário, e com prioridade para a exceção de grupo mais tardia. Quem exporta calendário para Google Agenda ou Outlook via iCal vai começar a receber mais um evento por atividade. Avise antes, para ninguém achar que é erro.

Se a sua coordenação também está reorganizando correção e feedback depois do upgrade, o post sobre o fluxo de avaliação do Moodle 5.3 com corretores cobre a parte da Tarefa, que complementa esta.

Como aplicar o prazo do questionário Moodle em cursos existentes

Este é o ponto que quase ninguém comenta. O script de upgrade do 5.3 adiciona a coluna duedate na tabela de questionários com valor padrão 0, que significa "sem data de entrega". Nas exceções, o campo nasce vazio e herda a data do questionário.

Consequência prática: depois do upgrade, nada muda nos cursos antigos. Nenhum aluno vê atraso, nenhum evento novo aparece. Para usar o recurso, alguém precisa preencher a data, questionário por questionário ou em lote.

Três caminhos, do mais seguro ao mais arriscado

1. Manual, pela interface. Para um curso com poucos questionários, é o caminho certo. Você vê a validação acontecer e os eventos de calendário nascem corretos.

2. Reinício do curso (course reset) e restauração de backup. Quem reaproveita a mesma sala a cada semestre já usa isso. No 5.3, o reinício desloca a data de entrega junto com abertura e fechamento, inclusive nas exceções. Backups feitos no 5.3 levam a data; backups antigos restauram sem data de entrega. Então: configure a entrega em um curso modelo uma vez, e os próximos semestres herdam.

3. Atualização em lote no banco. Para centenas de cursos, dá para preencher duedate direto no banco. Eu não recomendo fazer isso sem ambiente de homologação. Dois cuidados obrigatórios:

• respeitar a regra de faixa (depois de timeopen, até timeclose), porque o banco não valida o que o formulário valida;
• regerar os eventos de calendário depois. Escrever direto na tabela não cria os eventos. O Moodle tem uma tarefa própria para isso, a core\task\refresh_mod_calendar_events_task, que pode ser enfileirada só para o plugin quiz e executada pelo CLI de tarefas ad hoc.

Armadilhas que já vimos em upgrade

• Fuso horário. A data é gravada como timestamp. Script que calcula "sexta às 23h59" no fuso errado entrega uma data que fica três horas antes do que o professor espera.
• Plugins antigos que gravam questionário. O código do 5.3 preserva a data existente quando um plugin antigo não envia o campo. Mesmo assim, teste integrações que criam questionários via web service.
• Ferramentas de edição de datas em massa de terceiros. Se você usa plugin para editar datas de várias atividades de uma vez, confira se a versão dele já conhece a nova data antes de confiar nele.

Antes do recurso: o upgrade para o Moodle 5.3

Nada disso existe se o AVA não estiver no 5.3. E esse upgrade tem requisitos que mudaram, segundo as notas da versão:

Requisito	Moodle 5.3 LTS
Versão de origem	Moodle 4.4 ou posterior
PHP	8.3 mínimo (8.4 suportado), só 64 bits, extensão sodium, max_input_vars ≥ 5000
PostgreSQL	17 ou superior
MariaDB	11.4 ou superior
MySQL	8.4 ou superior
SQL Server	2019 ou superior
Suporte geral até	4 de outubro de 2027
Suporte de segurança até	1º de outubro de 2029

As datas de suporte vêm da tabela de versões do Moodle. Quem está no 5.1 já perdeu o suporte geral em 5 de outubro de 2026; o caminho está no post sobre o fim do suporte do Moodle 5.1. Se o servidor ainda roda PHP antigo, o upgrade de banco e PHP vem antes de qualquer recurso novo, e o post sobre Moodle em PHP legado mostra por que não dá para empurrar isso.

Ou seja: o prazo do questionário Moodle 5.3 pode ser o argumento que convence a coordenação a aprovar o upgrade, mas o trabalho de verdade está no servidor.

Checklist para liberar a novidade sem susto

Antes de anunciar o novo prazo do questionário Moodle para os professores, eu passo por esta lista:

• Site no 5.3 e cron rodando sem erro (eventos de calendário e notificações dependem dele)
• Teste em um curso de homologação: abertura, entrega, fechamento e uma exceção de grupo
• Linha do tempo conferida no tema do site, no desktop e no celular
• Texto padrão para a descrição das atividades explicando "atrasado ainda vale nota?"
• Decisão da coordenação sobre quais tipos de questionário usam entrega (exercício sim, prova não)
• Curso modelo atualizado, para que o próximo reinício de semestre já leve as datas
• Aviso a quem sincroniza o calendário por iCal

Essa lista leva meia hora em um curso de teste e evita uma semana de chamado de aluno.

Como a Agathas Web resolve isso

A gente administra ambientes Moodle de instituições de ensino e cuida do ciclo todo: servidor, upgrade, teste e suporte ao time pedagógico. Para quem quer usar o prazo do questionário Moodle 5.3 sem parar o AVA, o trabalho do nosso serviço de Moodle costuma incluir:

• Diagnóstico de versão e servidor: versão de origem, PHP, banco de dados e plugins instalados contra os requisitos do 5.3.
• Upgrade em homologação primeiro: cópia do ambiente, upgrade, testes de questionário, Tarefa, calendário e Linha do tempo, e só depois a janela em produção.
• Aplicação das datas em lote, quando faz sentido: preenchimento da data de entrega nos cursos que a coordenação escolher, com validação de faixa e regeração dos eventos de calendário.
• Revisão de plugins e integrações que criam ou editam questionários.
• Orientação para professores: quando usar entrega, quando usar só fechamento, e o texto padrão para as atividades.
• Hospedagem e sustentação, com backups e monitoramento, se o AVA estiver na nossa infraestrutura.

Como contratar: você pede um orçamento pela página de gestão e desenvolvimento Moodle, conta a versão atual e o tamanho do ambiente, e a gente devolve o escopo com prazo antes de tocar em produção.

Conclusão

Com o 5.3, o prazo do questionário Moodle deixa de ser uma data só. É uma mudança pequena no formulário e grande na rotina. Ela separa o prazo combinado do prazo técnico, tira do professor a obrigação de criar exceção para cada pedido de mais tempo e deixa a Linha do tempo do aluno mais honesta.

Três coisas para levar daqui: a entrega não bloqueia (o fechamento sim); cursos antigos ficam sem entrega até alguém configurar; e atualização em lote exige regerar o calendário. Se o seu AVA ainda não está no 5.3, ou se você quer aplicar a novidade em centenas de cursos sem risco, fale com a gente pelo serviço de Moodle da Agathas Web.